25539 2014-05-03 02:32:00 +0000 Broken links and other correct 2014-05-09 18:55:59 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 crimsteam travil mike www-dom public-webapps-bugzilla oldest_to_newest 105014 0 crimsteam 2014-05-03 02:32:00 +0000 I located some broken links and few new fixes. === 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) === 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). === 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). === 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 === 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). === 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". === And the last, please write something about the future of UI Events spec.: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25494 105017 1 crimsteam 2014-05-03 08:42:22 +0000 1.2 Conformance [RFC2119] << not work:) 105380 2 travil 2014-05-08 00:14:29 +0000 (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). 105561 3 travil 2014-05-09 18:55:59 +0000 Big update to address these problems: https://dvcs.w3.org/hg/dom3events/rev/a2c0d8dc96f5