RE: CFC: Republish Pointer Lock as CR

2016-06-17 Thread Léonie Watson
 

 

From: Vincent Scheib [mailto:sch...@google.com] 
Sent: 16 June 2016 12:34
“An accessibility review and handling of this [accessibility issue #1] are 
still needed and will likely cause a CR cycle. To avoid unnecessary work I 
propose CR to be deferred until that work is complete.”

 

I think the issue can be resolved with an informative note in the spec. It’s a 
question of what the browser does in accessibility terms once a 
pointerlockchange event has been fired.

 

Will post this to the GH issue in a moment… but don’t believe this should hold 
up the CFC.

 

Léonie.

 

 

 

 

[accessibility issue #1] https://github.com/w3c/pointerlock/issues/1

 

On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell  > wrote:

abstain

 

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl  > wrote:

Looks good, +1


—Michiel

 

On 13 Jun 2016, at 18:12, Léonie Watson  > 
wrote:

 

Hello WP,

This is a Call For Consensus (CFC) to request that W3C republish Pointer
Lock as a Candidate Recommendation (CR). Extensions to the MouseEventInit
Dictionary [1] constitute substantive changes to the specification that were
made after the current CR was published in 2013 [2].

Please reply to this CFC no later than 21st June 2016. Positive responses
are preferred and supporting comments (beyond just +1) are encouraged, but
silence will be considered as consent.

Thank you.

Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
[1]
https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
ry 
[2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/ 
-- 
@LeonieWatson tink.uk   Carpe diem




 





 

-- 

Download the aXe browser extension for free:

 

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools

Chrome: 
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

 

Life is ten percent what happens to you and ninety percent how you respond to 
it. - Lou Holtz

 

 



Re: Request to move HTML5.1 to Candidate Recommendation (CR)

2016-06-17 Thread Michiel Bijl
Woohoo!

—Michiel

> On 13 Jun 2016, at 18:11, Léonie Watson  wrote:
> 
> Hello WP,
> 
> This CFC passed with many expressions of support. Thank you to everyone who
> responded and gave feedback.
> 
> Léonie on behalf of the WP chairs and team, and HTML editors
> 
> 
>> -Original Message-
>> From: Léonie Watson [mailto:t...@tink.uk]
>> Sent: 02 June 2016 13:48
>> To: 'public-webapps WG' 
>> Subject: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)
>> 
>> Hello WP,
>> 
>> This is a call for consensus to request that W3C publish the current HTML
>> Working Draft (WD) as a Candidate Recommendation (CR). It has been
>> posted to public-webapps@w3.org as the official email for this WG.
>> 
>> Please reply to this thread on public-webapps@w3.org  no later than end of
>> day on 10 June. Positive responses are preferred and encouraged, silence
>> will be considered as assent.
>> 
>> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
>> make it more reliable, more readable and understandable, and a better
>> match for reality. Substantial changes between HTML5 and HTML5.1 can be
>> found in the spec [2].
>> 
>> When a specification moves to CR it triggers a Call For Exclusions, per
> section
>> 4 of the W3C Patent Policy [3]. No substantive additions can be made to a
>> specification in CR without starting a new Call for Exclusions, so we will
> put
>> HTML5.1 into "feature freeze". It is possible to make editorial updates as
>> necessary, and features marked "At Risk" may be removed if found not to be
>> interoperable.
>> 
>> The following features are considered "at risk". If we cannot identify at
> least
>> two shipping implementations, they will be marked "at risk" in the CR and
>> may be removed from the Proposed Recommendation.
>> 
>> keygen element. [issue 43]
>> label as a reassociatable element [issue 109] Fixing requestAnimationFrame
>> to 60Hz, not implementation-defined [issues 159/375/422]
>> registerContentHandler [Issue 233] inputmode attribute of the input
>> element [issue 269] autofill of form elements [issue 372] menu, menuitem
>> and context menus. [issue 373] dialog element [issue 427] Text tracks
>> exposing in-band metadata best practices [Issue 461] datetime and
>> datatime-local states of the input element [Issue 462]
>> 
>> Please share implementation details for any of these features on Github.
> To
>> mark other features "at risk", please identify them by 10th June (ideally
> by
>> filing an issue and providing a test case).
>> 
>> At the same time we move HTML5.1 into CR, we plan to continue updating
>> the Editor's Draft, and in the next few weeks we expect to post a Call for
>> Consensus to publish it as the First Public Working Draft of HTML5.2, so
>> improving HTML will continue without a pause. It also means that changes
>> that didn't make it into
>> HTML5.1 will not have long to wait before being incorporated into the
>> specification.
>> 
>> Léonie on behalf of the WP chairs and team, and HTML editors.
>> [1] https://www.w3.org/TR/html51/
>> [2] https://www.w3.org/TR/html51/changes.html#changes
>> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>> 
>> [issue 43] https://github.com/w3c/html/issues/43
>> [issue 109] https://github.com/w3c/html/issues/109
>> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
>> [issue 233] https://github.com/w3c/html/issues/233
>> [issue 269] https://github.com/w3c/html/issues/269
>> [issue 372] https://github.com/w3c/html/issues/372
>> [issue 373] https://github.com/w3c/html/issues/373
>> [issue 427] https://github.com/w3c/html/issues/427
>> [Issue 461] https://github.com/w3c/html/issues/461
>> [Issue 462] https://github.com/w3c/html/issues/462
>> 
>> 
>> --
>> @LeonieWatson tink.uk Carpe diem
>> 
>> 
>> 
> 
> 
>