W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2014

Re: Splitting key/code tables out of DOM3Event spec

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 14 Mar 2014 07:15:41 -0400
Message-ID: <5322E4DD.10002@nokia.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:22 UTC