Re: Splitting key/code tables out of DOM3Event spec

On Fri, 14 Mar 2014, Arthur Barstow wrote:

> 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?

F@R is here to set expectations, using this for LC is a good way to ask 
for specific feedback on those features, so it's actually good practice to 
document what is considered as stable, at risk of being removed, or just 
not stable yet.


>> 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>
>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Friday, 14 March 2014 12:28:22 UTC