1.2 Conformance
[RFC2119] << not work:)

(In reply to spiritRKS1910 from comment #0)
> I located some broken links and few new fixes.

Thanks for reviewing. The W3C Link Checker usually helps us catch these before publication, but it's nice to have these updated early.

> ===
> 
> After moving key and code into separate documents, some reference to the
> keys are broken. This applies mainly to modifiers (like 'Alt', 'Control',
> 'Shift', 'Meta', etc.). But first it should be determined if you want use
> reference or not for keys, now we have mess (in most case don't use ref for
> any keys).
> 
> In Glossary:
> "event order"
> "key mapping"
> "key value"
> "modifier key"
> 
> In 
> 3.5 Activation triggers and behavior
> 3.5.1 Activation event synthesis
> 3.5.2 Activation event order
> 
> In all event tables [Context (trusted events)] for:
> MouseEvent
> WheelEvent
> KeyboardEvent (including keypress and some descriptions below table like for
> keydown)
> 
> In 5.2.6.1.1 Attributes 
> altKey, ctrlKey and key
> 
> In
> 6.3.4 Input Method Editors (first 'Accept')
> Example 35 ('Cancel')
> 5.2.6.1.2 Methods (link 'Modifier Keys' in table)
> 5.2.6.2 Keyboard Event Order (last green box 'Tab')
> 
> 6.1 Keyboard Input (... but briefly describes keyboard layout and... << 
> 'keyboard layout' not work)
> 
> 6.2.1 Motivation for Adding the code Attribute (...refer to as writing
> system keys... << 'writing system keys' not work)
> 
> 6.3 Keyboard Event key Values (...depicted in Figure 4 illustrates one
> possible... << 'Figuer 4' not work)
 
Yes, this was a mess. It seems we were hyperlinking these keys early on, but that practice was not persistent. I think my solution will be to un-hyperlink all the keys for consistency's sake. I don't think this is a real loss, since there's a whole document now for reviewing the key values in one place.

> ===
> 
> You should also labeled keys using title = "". Now you use some background
> color for individual cases, but it's difficult to remember what each color
> means. With JS it would be very easy, just retrieve elements with specific
> classes and set title with a clear description (key value, key code,
> character value, glyph).

Excellent idea. I can script this in.

 
> ===
> 
> From 5.2.7.4 to 5.2.7.6 not all of the event names are references (keydown,
> compositionstart, compositionend, etc.) but they may be. 
> 
> Te same in Example 24 (two tables).

Sounds good; I'll link those up.


> ===
> 
> 5.2.6.1.3 Constants
> ...Note that the 'NumLock'key should... << missing space 'NumLock'key
> ...and (other than the 'NumLock'key) did... << missing space 'NumLock'key

Whoops. Good find.

 
> ===
> 
> 6.3.2 Modifier keys
> 
> For all sequence tables in this section please add headers with
> descriptions, something what we have in example 37/38 (including
> KeyboardEvent.key and InputEvent.data).
> 
> After this every Modifiers can be linked (like in example 37/38).

Makes sense.

 
> ===
> 
> Example 23 and Example 24 << why 'shiftKey' is marked by
> class="constant-name"? A little bellow you use class="attribute-name".
> 
> And similar, Example 21-24 for key header you used class="key-code", but
> should be class="key".

Fun with inconsistencies between multiple editors ;-) I'll clean that up.

> ===
> 
> And the last, please write something about the future of UI Events spec.:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25494

We love UI Events! We're just focusing our efforts on finishing this spec (we also brought a few concepts from UI Events into DOM L3 Events (i.e., the 'code' property).

Big update to address these problems:
https://dvcs.w3.org/hg/dom3events/rev/a2c0d8dc96f5