RE: Splitting key/code tables out of DOM3Event spec

From: Arthur Barstow [mailto:art.barstow@nokia.com] 
> I support your proposal but would like to hear from others that are 
> actively participating in this work or consider themselves "stakeholders".
>
> Travis - what are your thoughts on this proposal?

Given the fairly consistent trickle of bugs related to the presence/absence of key names/values, I think this move [forking out the key/code tables and values] *could* help the core DOM L3 Spec move to Recommendation faster.

However, it's not clear to me that we haven't already reached the end of the trickle of interest groups petitioning new key values. Given the 4 previous Last Calls of this spec, you'd think the whole W3C-world knows about this document and has cracked it open at least once. The real truth will come at CR stage. Perhaps instead of pre-emptively splitting this stuff out of the spec, we keep it in, mark it at risk (to [potentially] move into another doc as feedback arrives at CR) and fix the known bugs that we have:
1. 23167 Define key name for TV
2. 24739 Define code values for the special keys on Sun keyboard
3. 24740 Define code values for the special keys on Mac keyboard
4. 23750 ScrollLock key should be defined in 6.3.2 Modifier Keys
5. 23751 "Select" key is not defined in the latest ED

These all seem necessary for implementers, so I think it might be a disservice not to address them now.

> Assuming we have consensus to move forward with the split, given the key 
> values and code values are likely to change over time, I'm wondering 
> about the tradeoffs of putting that information in a normative spec we 
> push along the Recommendation track versus using a "living" document 
> process that would facilitate some group (f.ex. the mobile IG, web and 
> TV IG, etc.) submitting a PR to add and/or modify the data. Does some 
> "interested party" actually need a Recommendation track spec for this 
> data (f.ex. to normatively reference)?

Received on Wednesday, 12 March 2014 21:32:44 UTC