About "root element" I see this term is defined in Glossary (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#glossary-root-element).

But in description you never refer to this term.

I will take a look at these...

(In reply to spiritRKS1910 from comment #0)
> Keyboard event tables
> (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-
> type-keydown) missing some context info:
> KeyboardEvent.code
> KeyboardEvent.isComposing

I will add these.


> =====
> 
> Target: Document, Element in above tables and in "5.1.1 List of DOM3 Event
> Types" is correct? Any case when Document fits (of course excluding the
> untrusted events)? We have this in description for keyboard event:
> "... If no suitable element is in focus, the event target will be the root
> element."
> 
> Writing "root element" you have means "document element"
> (http://dom.spec.whatwg.org/#document-element)? 

I tested IE11, Firefox and Chrome by adding a keyup event listener on the document, and then removing the document's documentElement. Then I click on the page to [maybe?] set focus on it, and then hit a key.
IE11: Responds with a keyup event targeted at the document object.
Firefox: No event is generated (the document can't have focus by itself)
Chrome: No event is generated (the document can't have focus by itself)

I filed the product bug on IE to correct this. :-)

In the spec, I removed "Document" as a trusted event target, and made references to the root element. I also extended this to the keypress event.


> =====
> 
> I noticed that for some keys not all keyboard events are dispatched. Example
> (all in Win7):
> 
> - F1 firing only keydown event (in Chrome, IE)
> - F3 firing only keydown event (in Firefox, IE)
> - F6 firing only keydown event (in Chrome, IE)
> - F10 firing only keydown event (in Firefox, Chrome)
> - F12 firing only keydown event (in IE)
> - PrintScreen firing only keyup event (in Firefox, Chrome, IE)
> 
> This behavior is to much dependent on the implementation/system/device and
> will not be standardized? Information for such cases would be helpful. Now
> we have different behaviors, even if the browser do similar actions (like
> when press F3 or F6 key).

This is a known issue with "reserved" (or protected) browser application accelerators. For example, on Windows if the browser app has a "Launch help" feature setup and plugged into the F1 key (on keydown), then the browser traps that keystroke and executes it's default action as a result. In the F1 scenario (and probably all of the above mentioned cases) the default action moves keyboard focus from the current web application to something else (thus the matching keyup event is not received by the web application). It is unlikely that browser implementations will change this behavior--and certain keystrokes (e.g., Ctrl+L or Alt+D) may always be protected to ensure that users with accessibility needs can always get to the address bar (for example), and not have the web application prevent that from happening.

The advice (already in the spec) to get better consistency here is to call preventDefault in the keydown event handler, which stops the browser from executing it's default action (when possible). This allows these keys to behave in more expected manner.

Now fixed in editor's draft.