Re: Splitting key/code tables out of DOM3Event spec

On 3/12/14 5:32 PM, ext Travis Leithead wrote:
> From: Arthur Barstow [mailto:[email protected]]
>> 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>