- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 14 Mar 2014 07:15:41 -0400
- To: Travis Leithead <travis.leithead@microsoft.com>, "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>, "www-dom@w3.org" <www-dom@w3.org>, Philippe Le Hégaret <plh@w3.org>, Yves Lafon <ylafon@w3.org>
On 3/12/14 5:32 PM, ext Travis Leithead wrote: > 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) I'm not that familiar with using the Feature @ Risk process [F@R] but my understanding is that it could be used to prevent a Candidate Recommendation from going back to Last Call if/when there is agreement to add YA code value and/or key value. However, it's not clear to me if F@R can be used for Last Call docs and if it cannot be used, then if there is agreement to add YA code value and/or key value, I think that would mean all of D3E would require YA Last Call. Yves, PLH - would you please clarify if we may use the F@R process for a LC? > 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. OK, although it seems -Thanks, AB [F@R] <http://www.w3.org/2005/10/Process-20051014/tr.html#cfi>
Received on Friday, 14 March 2014 11:16:36 UTC