Re: CfC: FPWD for Input Events

[chaals]

With expressions of support, and no objections, this Call for Consensus passes.

Thanks - I'll work with Johannes and the Team Contacts to get this published as 
soon as we can...

cheers

14.08.2016, 14:31, "cha...@yandex-team.ru" :
> Hi,
>
> This is a Call for Consensus on the proposition "Publish the Input Events 
> specification at https://w3c.github.io/input-events/ as a First Public 
> Working Draft".
>
> Please reply before the end of the day on 22 August, either in this email 
> thread or by adding a +1 or -1 to the proposal which is the first comment in 
> https://github.com/w3c/input-events/issues/1
>
> For the chairs, with thanks to Johannes and the people working on editing
>
> chaals
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CFC to publish WebIDL-1 as a Proposed Recommendation

[Léonie Watson]

On 16/08/2016 07:46, Léonie Watson wrote:

This is a Call For Consensus (CFC) to publish WebIDL-1 as a Proposed
Recommendation (PR) [1].


This CFC received positive messages of support and no objections, and so 
it passes.



Thank you to Yves and Travis for their work on this specification.

Léonie.

--
@LeonieWatson tink.uk Carpe diem

Re: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Léonie Watson]

On 14/08/2016 00:01, Xiaoqian Wu wrote:

This is a Call for Consensus to publish a Proposed Recommendation of
Pointer Lock using the [PR] as the basis. Agreement with this CfC means
you consider the test results shows interoperability and the changes
since CR are not substantive.


This CFC received no objections, and so it passes.

Thanks to Vincent and Xiaoqian for their work on the Pointer Lock spec.

Léonie.


--
@LeonieWatson tink.uk Carpe diem

Re: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Léonie Watson]

Quick reminder that this CFC closes tomorrow, Saturday 20th August. Thanks.

Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 14/08/2016 00:01, Xiaoqian Wu wrote:

Hello, Web Platform WG,

This is a Call for Consensus to publish a Proposed Recommendation of
Pointer Lock using the [PR] as the basis. Agreement with this CfC means
you consider the test results shows interoperability and the changes
since CR are not substantive.

The test results for Pointer Lock [All] indicate significant
interoperability, with only one test that have less than two passes [<2].
<http://www.w3c-test.org/pointerlock/idlharness.html>; this test failure
can be considered more of a Web IDL implementation issue. The group
believes it will get better over time as WebIDL compliance progresses.

The current [OPEN ISSUES], #5 is about adding pointerlock to the
permissions enum, will be fixed the next version. Another issue is
about pointerlockchange and the accessibility tree (#1), which is
resolved by a magnification software note added to pointerlockchange and
pointerlockerror Events.

Changes since the CR publication includes:
* Specify movementX/Y to be 0 after gaps in mouse input.

We consider the change since the CR as non-substantive. See [Diff] for
all of changes between the CR and the draft PR.

If you have any comments or concerns about this CfC, please reply to
this e-mail by August 20 at the latest. Positive response is preferred
and encouraged, and silence will be considered as agreement with the
proposal. If there are no non-resolvable objections to this proposal,
the motion will carry and we will request the PR be published on August
25 2016.

Thanks.

-xiaoqian

[PR] http://w3c.github.io/pointerlock/publish/index-2016-PR.html
[All] http://w3c.github.io/test-results/pointerlock/all.html
[<2] http://w3c.github.io/test-results/pointerlock/less-than-2.html
[OPEN ISSUES] https://github.com/w3c/pointerlock/issues
[Diff]
https://github.com/w3c/pointerlock/commits/gh-pages/index.html
http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2016%2FCR-pointerlock-20160705%2F=http%3A%2F%2Fw3c.github.io%2Fpointerlock%2Fpublish%2Findex-2016-PR.html
<http://services.w3.org/htmldiff?doc1=https://www.w3.org/TR/2016/CR-pointerlock-20160705/=http://w3c.github.io/pointerlock/publish/index-2016-PR.html>

Re: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Léonie Watson]

+1

Great for this to be progressing.

Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 14/08/2016 00:01, Xiaoqian Wu wrote:

Hello, Web Platform WG,

This is a Call for Consensus to publish a Proposed Recommendation of
Pointer Lock using the [PR] as the basis. Agreement with this CfC means
you consider the test results shows interoperability and the changes
since CR are not substantive.

The test results for Pointer Lock [All] indicate significant
interoperability, with only one test that have less than two passes [<2].
<http://www.w3c-test.org/pointerlock/idlharness.html>; this test failure
can be considered more of a Web IDL implementation issue. The group
believes it will get better over time as WebIDL compliance progresses.

The current [OPEN ISSUES], #5 is about adding pointerlock to the
permissions enum, will be fixed the next version. Another issue is
about pointerlockchange and the accessibility tree (#1), which is
resolved by a magnification software note added to pointerlockchange and
pointerlockerror Events.

Changes since the CR publication includes:
* Specify movementX/Y to be 0 after gaps in mouse input.

We consider the change since the CR as non-substantive. See [Diff] for
all of changes between the CR and the draft PR.

If you have any comments or concerns about this CfC, please reply to
this e-mail by August 20 at the latest. Positive response is preferred
and encouraged, and silence will be considered as agreement with the
proposal. If there are no non-resolvable objections to this proposal,
the motion will carry and we will request the PR be published on August
25 2016.

Thanks.

-xiaoqian

[PR] http://w3c.github.io/pointerlock/publish/index-2016-PR.html
[All] http://w3c.github.io/test-results/pointerlock/all.html
[<2] http://w3c.github.io/test-results/pointerlock/less-than-2.html
[OPEN ISSUES] https://github.com/w3c/pointerlock/issues
[Diff]
https://github.com/w3c/pointerlock/commits/gh-pages/index.html
http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2016%2FCR-pointerlock-20160705%2F=http%3A%2F%2Fw3c.github.io%2Fpointerlock%2Fpublish%2Findex-2016-PR.html
<http://services.w3.org/htmldiff?doc1=https://www.w3.org/TR/2016/CR-pointerlock-20160705/=http://w3c.github.io/pointerlock/publish/index-2016-PR.html>

CFC to publish WebIDL-1 as a Proposed Recommendation

[Léonie Watson]

Hello WP,

This is a Call For Consensus (CFC) to publish WebIDL-1 as a Proposed 
Recommendation (PR) [1].


Some editorial changes were made to the specification during the 
Candidate Recommendation (CR) period, but none that affects conformance. 
The CR implementation

report is available [2].

We are still exploring different ways of responding to a CFC. Please 
choose one of the following methods:


1. Reply by email to this thread (on public-webapps@w3.org).
2. Reply or +1 on Github [3].

There is no need to use more than one method. The WP chairs will collate 
the results across all channels.


Please respond by end of day on Monday 22nd August. Positive responses 
are encouraged, but silence will be taken as consent with the proposal.


Thanks
Léonie on behalf of the WP chairs and team
[1]
https://ylafon.github.io/webidl/publications/pr-20160809.html
[2]
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/report/all.html
[3] https://github.com/w3c/WebPlatformWG/issues/61
--
@LeonieWatson tink.uk Carpe diem

CfC: FPWD for Input Events

[chaals]

Hi,

This is a Call for Consensus on the proposition "Publish the Input Events 
specification at https://w3c.github.io/input-events/ as a First Public Working 
Draft".

Please reply before the end of the day on 22 August, either in this email 
thread or by adding a +1 or -1 to the proposal which is the first comment in 
https://github.com/w3c/input-events/issues/1

For the chairs, with thanks to Johannes and the people working on editing

chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Xiaoqian Wu]

Hello, Web Platform WG,

This is a Call for Consensus to publish a Proposed Recommendation of Pointer 
Lock using the [PR] as the basis. Agreement with this CfC means you consider 
the test results shows interoperability and the changes since CR are not 
substantive.

The test results for Pointer Lock [All] indicate significant interoperability, 
with only one test that have less than two passes [<2].
<http://www.w3c-test.org/pointerlock/idlharness.html>; this test failure can be 
considered more of a Web IDL implementation issue. The group believes it will 
get better over time as WebIDL compliance progresses.

The current [OPEN ISSUES], #5 is about adding pointerlock to the permissions 
enum, will be fixed the next version. Another issue is about pointerlockchange 
and the accessibility tree (#1), which is resolved by a magnification software 
note added to pointerlockchange and pointerlockerror Events.

Changes since the CR publication includes:
* Specify movementX/Y to be 0 after gaps in mouse input.

We consider the change since the CR as non-substantive. See [Diff] for all of 
changes between the CR and the draft PR.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by August 20 at the latest. Positive response is preferred and 
encouraged, and silence will be considered as agreement with the proposal. If 
there are no non-resolvable objections to this proposal, the motion will carry 
and we will request the PR be published on August 25 2016.

Thanks.

-xiaoqian

[PR] http://w3c.github.io/pointerlock/publish/index-2016-PR.html
[All] http://w3c.github.io/test-results/pointerlock/all.html
[<2] http://w3c.github.io/test-results/pointerlock/less-than-2.html 
<http://w3c.github.io/test-results/pointerlock/less-than-2.html>
[OPEN ISSUES] https://github.com/w3c/pointerlock/issues
[Diff]
https://github.com/w3c/pointerlock/commits/gh-pages/index.html
http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2016%2FCR-pointerlock-20160705%2F=http%3A%2F%2Fw3c.github.io%2Fpointerlock%2Fpublish%2Findex-2016-PR.html
 
<http://services.w3.org/htmldiff?doc1=https://www.w3.org/TR/2016/CR-pointerlock-20160705/=http://w3c.github.io/pointerlock/publish/index-2016-PR.html>

Re: CFC: Publish a FPWD of IndexedDB 2.0

[Léonie Watson]

With thanks to everyone who responded. This CFC received only positive 
responses, and so passes without objection.


Léonie.


--
@LeonieWatson tink.uk Carpe diem

On 03/08/2016 15:46, Léonie Watson wrote:

Hello WP,

This is a Call For Consensus (CFC) to publish a First Public Working
Draft (FPWD) of IndexedDB 2.0 [1].

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread (on
public-webapps@w3.org).

2. Reply or +1 on Github:
https://github.com/w3c/IndexedDB/issues/84

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Wednesday 10th August. Positive
responses are encouraged, but silence will be taken as consent with the
proposal.

Thanks
Léonie on behalf of the WP chairs and team
[1]
http://w3c.github.io/IndexedDB/

Re: CFC on referencing the Image Description (longdesc) extension

[Léonie Watson]

A quick reminder that this CFC closes at the end of day tomorrow (Friday 
12th August).


Thanks.
Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 05/08/2016 18:17, Léonie Watson wrote:

Hello WP,

This is a Call For Consensus (CFC) on the following proposal for
referencing the Image Description (longdesc) extension specification
[1]. The CFC is posted to public-webapps@w3.org because this is the
official WP email list, and copied to public-h...@w3.org.

The proposal:

1. Remove the longdesc attribute from the table of attributes in HTML core.
2. Remove the IDL information for the longdesc attribute from HTML core.
3. Keep the longdesc examples in HTML core **.
4. Create a WG Note listing known extension specifications ***.
5. Include a link to the HTML Extension Specifications Note from HTML
core (probably in the index).

** Examples throughout the HTML specification are informative, and we
include informative examples and information for other specifications
and extensions
elsewhere in HTML core.

*** We anticipate that the Note will be updated as we identify new/other
extension specifications.

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread.
2. Reply or +1 to the original proposal comment on Github [2].

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Friday 12th August. Positive responses
are encouraged, but silence will be taken as consent with the proposal.

Thanks
Léonie on behalf of the WP chairs and team
[1]  https://www.w3.org/TR/html-longdesc/
[2] https://github.com/w3c/html/issues/507#issuecomment-237068400

RE: CFC: Publish a FPWD of IndexedDB 2.0

[Ali Alabbas]

+1

> On Tue, Aug 09, 2016 at 08:07:10, Alexander Schmitz wrote:
> 
> +1
> 
> Alexander Schmitz
> jQuery Foundation
> 
> On Tue, Aug 9, 2016 at 8:45 AM, Dylan Barrell <dylan.barr...@deque.com
> <mailto:dylan.barr...@deque.com> > wrote:
> 
> 
>   +1
> 
>   On Tue, Aug 9, 2016 at 5:06 AM, Léonie Watson <t...@tink.uk
> <mailto:t...@tink.uk> > wrote:
> 
> 
>   Quick reminder that this CFC closes at the end of day
> tomorrow (Wednesday 10th August). Thanks.
> 
>   Léonie.
> 
>   --
>   @LeonieWatson tink.uk <http://tink.uk>  Carpe diem
> 
> 
>   On 03/08/2016 15:46, Léonie Watson wrote:
> 
> 
>   Hello WP,
> 
>   This is a Call For Consensus (CFC) to publish a First
> Public Working
>   Draft (FPWD) of IndexedDB 2.0 [1].
> 
>   We are still exploring different ways of responding to
> a CFC. Please
>   choose one of the following methods:
> 
>   1. Reply by email to this thread (on
>   public-webapps@w3.org
> <mailto:public-webapps@w3.org> ).
> 
>   2. Reply or +1 on Github:
>   https://github.com/w3c/IndexedDB/issues/84
> <https://github.com/w3c/IndexedDB/issues/84>
> 
>   There is no need to use more than one method.
> The WP chairs will collate
>   the results across all channels.
> 
>   Please respond by end of day on Wednesday 10th
> August. Positive
>   responses are encouraged, but silence will be taken
> as consent with the
>   proposal.
> 
>   Thanks
>   Léonie on behalf of the WP chairs and team
>   [1]
>   http://w3c.github.io/IndexedDB/
> <http://w3c.github.io/IndexedDB/>
> 
> 
> 
> 
> 
> 
>   --
> 
>   Download the aXe browser extension for free:
> 
> 
>   Firefox:
> https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
> <https://addons.mozilla.org/en-US/firefox/addon/axe-devtools>
>   Chrome:
> https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindne
> jefpo
> kejbdd?hl=en-US
> <https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindn
> ejefp
> okejbdd?hl=en-US>
> 
> 
>   Life is ten percent what happens to you and ninety percent how you
> respond to it. - Lou Holtz
> 
> 
> 

Re: CFC: Publish a FPWD of IndexedDB 2.0

[Dylan Barrell]

+1

On Tue, Aug 9, 2016 at 5:06 AM, Léonie Watson <t...@tink.uk> wrote:

> Quick reminder that this CFC closes at the end of day tomorrow (Wednesday
> 10th August). Thanks.
>
> Léonie.
>
> --
> @LeonieWatson tink.uk Carpe diem
>
> On 03/08/2016 15:46, Léonie Watson wrote:
>
>> Hello WP,
>>
>> This is a Call For Consensus (CFC) to publish a First Public Working
>> Draft (FPWD) of IndexedDB 2.0 [1].
>>
>> We are still exploring different ways of responding to a CFC. Please
>> choose one of the following methods:
>>
>> 1. Reply by email to this thread (on
>> public-webapps@w3.org).
>>
>> 2. Reply or +1 on Github:
>> https://github.com/w3c/IndexedDB/issues/84
>>
>> There is no need to use more than one method. The WP chairs will collate
>> the results across all channels.
>>
>> Please respond by end of day on Wednesday 10th August. Positive
>> responses are encouraged, but silence will be taken as consent with the
>> proposal.
>>
>> Thanks
>> Léonie on behalf of the WP chairs and team
>> [1]
>> http://w3c.github.io/IndexedDB/
>>
>
>


-- 
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: CFC: Publish a FPWD of IndexedDB 2.0

[Léonie Watson]

Quick reminder that this CFC closes at the end of day tomorrow 
(Wednesday 10th August). Thanks.


Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 03/08/2016 15:46, Léonie Watson wrote:

Hello WP,

This is a Call For Consensus (CFC) to publish a First Public Working
Draft (FPWD) of IndexedDB 2.0 [1].

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread (on
public-webapps@w3.org).

2. Reply or +1 on Github:
https://github.com/w3c/IndexedDB/issues/84

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Wednesday 10th August. Positive
responses are encouraged, but silence will be taken as consent with the
proposal.

Thanks
Léonie on behalf of the WP chairs and team
[1]
http://w3c.github.io/IndexedDB/

Re: CFC on referencing the Image Description (longdesc) extension

[Mona Rekhi]

+1

via CloudMagic 
Email<https://cloudmagic.com/k/d/mailapp?ct=pa=8.6.36=6.0.1=email_footer_2>
On Fri, Aug 05, 2016 at 1:21 PM, L?onie Watson 
<t...@tink.uk<mailto:t...@tink.uk>> wrote:


Hello WP,

This is a Call For Consensus (CFC) on the following proposal for
referencing the Image Description (longdesc) extension specification
[1]. The CFC is posted to public-webapps@w3.org because this is the
official WP email list, and copied to public-h...@w3.org.

The proposal:

1. Remove the longdesc attribute from the table of attributes in HTML core.
2. Remove the IDL information for the longdesc attribute from HTML core.
3. Keep the longdesc examples in HTML core **.
4. Create a WG Note listing known extension specifications ***.
5. Include a link to the HTML Extension Specifications Note from HTML
core (probably in the index).

** Examples throughout the HTML specification are informative, and we
include informative examples and information for other specifications
and extensions
elsewhere in HTML core.

*** We anticipate that the Note will be updated as we identify new/other
extension specifications.

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread.
2. Reply or +1 to the original proposal comment on Github [2].

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Friday 12th August. Positive responses
are encouraged, but silence will be taken as consent with the proposal.

Thanks
L?onie on behalf of the WP chairs and team
[1]  https://www.w3.org/TR/html-longdesc/
[2] https://github.com/w3c/html/issues/507#issuecomment-237068400
--
@LeonieWatson tink.uk Carpe diem

Re: CFC on referencing the Image Description (longdesc) extension

[John Foliot]

Despite lingering concerns about removing a valid attribute from the table
of attributes in the document, in the interest of cooperation and
collaborative consensus building I will agree with this CfC.

JF

On Fri, Aug 5, 2016 at 12:17 PM, Léonie Watson <t...@tink.uk> wrote:

> Hello WP,
>
> This is a Call For Consensus (CFC) on the following proposal for
> referencing the Image Description (longdesc) extension specification [1].
> The CFC is posted to public-webapps@w3.org because this is the official
> WP email list, and copied to public-h...@w3.org.
>
> The proposal:
>
> 1. Remove the longdesc attribute from the table of attributes in HTML core.
> 2. Remove the IDL information for the longdesc attribute from HTML core.
> 3. Keep the longdesc examples in HTML core **.
> 4. Create a WG Note listing known extension specifications ***.
> 5. Include a link to the HTML Extension Specifications Note from HTML core
> (probably in the index).
>
> ** Examples throughout the HTML specification are informative, and we
> include informative examples and information for other specifications and
> extensions
> elsewhere in HTML core.
>
> *** We anticipate that the Note will be updated as we identify new/other
> extension specifications.
>
> We are still exploring different ways of responding to a CFC. Please
> choose one of the following methods:
>
> 1. Reply by email to this thread.
> 2. Reply or +1 to the original proposal comment on Github [2].
>
> There is no need to use more than one method. The WP chairs will collate
> the results across all channels.
>
> Please respond by end of day on Friday 12th August. Positive responses are
> encouraged, but silence will be taken as consent with the proposal.
>
> Thanks
> Léonie on behalf of the WP chairs and team
> [1]  https://www.w3.org/TR/html-longdesc/
> [2] https://github.com/w3c/html/issues/507#issuecomment-237068400
> --
> @LeonieWatson tink.uk Carpe diem
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.fol...@deque.com

Advancing the mission of digital accessibility and inclusion

CFC on referencing the Image Description (longdesc) extension

[Léonie Watson]

Hello WP,

This is a Call For Consensus (CFC) on the following proposal for 
referencing the Image Description (longdesc) extension specification 
[1]. The CFC is posted to public-webapps@w3.org because this is the 
official WP email list, and copied to public-h...@w3.org.


The proposal:

1. Remove the longdesc attribute from the table of attributes in HTML core.
2. Remove the IDL information for the longdesc attribute from HTML core.
3. Keep the longdesc examples in HTML core **.
4. Create a WG Note listing known extension specifications ***.
5. Include a link to the HTML Extension Specifications Note from HTML 
core (probably in the index).


** Examples throughout the HTML specification are informative, and we 
include informative examples and information for other specifications 
and extensions

elsewhere in HTML core.

*** We anticipate that the Note will be updated as we identify new/other 
extension specifications.


We are still exploring different ways of responding to a CFC. Please 
choose one of the following methods:


1. Reply by email to this thread.
2. Reply or +1 to the original proposal comment on Github [2].

There is no need to use more than one method. The WP chairs will collate 
the results across all channels.


Please respond by end of day on Friday 12th August. Positive responses 
are encouraged, but silence will be taken as consent with the proposal.


Thanks
Léonie on behalf of the WP chairs and team
[1]  https://www.w3.org/TR/html-longdesc/
[2] https://github.com/w3c/html/issues/507#issuecomment-237068400
--
@LeonieWatson tink.uk Carpe diem

CFC: Publish a FPWD of IndexedDB 2.0

[Léonie Watson]

Hello WP,

This is a Call For Consensus (CFC) to publish a First Public Working 
Draft (FPWD) of IndexedDB 2.0 [1].


We are still exploring different ways of responding to a CFC. Please 
choose one of the following methods:


1. Reply by email to this thread (on
public-webapps@w3.org).

2. Reply or +1 on Github:
https://github.com/w3c/IndexedDB/issues/84

There is no need to use more than one method. The WP chairs will collate 
the results across all channels.


Please respond by end of day on Wednesday 10th August. Positive 
responses are encouraged, but silence will be taken as consent with the 
proposal.


Thanks
Léonie on behalf of the WP chairs and team
[1]
http://w3c.github.io/IndexedDB/
--
@LeonieWatson tink.uk Carpe diem

Re: CFC: Republish Pointer Lock as CR

[Léonie Watson]

On 21/06/2016 13:14, Léonie Watson wrote:

Important: This CFC is extended for 48 hours. Please provide comments by
end of day on Thursday 23^rd June 2016.


With thanks to those who responded, this CFC passes. We will begin the 
process of transitioning Pointer Lock to CR.


Léonie.

--
@LeonieWatson tink.uk Carpe diem

RE: CFC: Republish Pointer Lock as CR

[Léonie Watson]

From: Léonie Watson [mailto:t...@tink.uk] 
Sent: 21 June 2016 11:18

Yes, CR requires at least two implementations in shipping browsers. Once 
Pointer Lock is at Recc, hopefully the Shadow DOM content will be stable enough 
to include in Pointer Lock next.

 

Correction: A CR doesn’t require 2+ implementations, but we do have to 
demonstrate that the spec has received wide review. The implementations are 
needed to exit CR as we move to PR though. Sorry, my fault for not paying 
attention!

 

We plan to move Pointer Lock to CR, then to Recc within a few weeks. It seems 
like the most painless way to do things.

 

The alternative was to include the Shadow DOM features but mark them as “at 
risk” during the CR. Given that Shadow DOM is still not stable, it’s likely 
we’d have to take those features out again for PR – which seems like extra work 
for the editor.

 

Instead we encourage the editors to publish a WD of Pointer Lock 2 as soon as 
there is concensus on the Shadow DOM content.

 

 

 

HTH

Léonie.

RE: CFC: Republish Pointer Lock as CR

[Léonie Watson]

 

 

From: Takayoshi Kochi [mailto:ko...@google.com] 
“I'm fine without Shadow DOM changes, because no one yet implemented the 
intended change to the spec yet,

and so it could be immature to include in a "CR".   (Does CR require at least 2 
implementors exist?)”

 

Yes, CR requires at least two implementations in shipping browsers. Once 
Pointer Lock is at Recc, hopefully the Shadow DOM content will be stable enough 
to include in Pointer Lock next.

 

 

Thanks for your help with this.

 

 

 

-- 

@LeonieWatson tink.uk Carpe diem

 

Léonie.

RE: CFC: Republish Pointer Lock as CR

[Léonie Watson]

Important: This CFC is extended for 48 hours. Please provide comments by end of 
day on Thursday 23rd June 2016.

 

From: Vincent Scheib [mailto:sch...@google.com] 
Sent: 21 June 2016 05:09
“I've discussed more with Xiaoqian and Léonie and support a CR now with this 
proposal:

 

Move to a CR for the v1 Pointer Lock specification without Shadow DOM changes, 
and a note on accessibility. Implementations are nearly consistent for v1 and 
it can move to a published status sooner. We can follow up with a v2 requiring 
more implementation work afterwards.”

 

Thanks Vincent.

 

Per the note above, this CFC [1] is extended for 48 hours to give WG members 
more time to respond now we have clarified the path.

 

Léonie.

[1] https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/0127.html 

 

 

 

-- 

@LeonieWatson tink.uk Carpe diem

 

 

Re: CFC: Republish Pointer Lock as CR

[Takayoshi Kochi]

I'm fine without Shadow DOM changes, because no one yet implemented the
intended change to the spec yet,
and so it could be immature to include in a "CR".   (Does CR require at
least 2 implementors exist?)

On Tue, Jun 21, 2016 at 1:09 PM, Vincent Scheib  wrote:

> I've discussed more with Xiaoqian and Léonie and support a CR now with
> this proposal:
>
> Move to a CR for the v1 Pointer Lock specification without Shadow DOM
> changes, and a note on accessibility. Implementations are nearly consistent
> for v1 and it can move to a published status sooner. We can follow up with
> a v2 requiring more implementation work afterwards.
>
>


-- 
Takayoshi Kochi

Re: CFC: Republish Pointer Lock as CR

[Vincent Scheib]

I've discussed more with Xiaoqian and Léonie and support a CR now with this
proposal:

Move to a CR for the v1 Pointer Lock specification without Shadow DOM
changes, and a note on accessibility. Implementations are nearly consistent
for v1 and it can move to a published status sooner. We can follow up with
a v2 requiring more implementation work afterwards.

RE: CFC: Republish Pointer Lock as CR

[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 <dylan.barr...@deque.com 
<mailto:dylan.barr...@deque.com> > wrote:

abstain

 

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl 
<mailto:mich...@agosto.nl> > wrote:

Looks good, +1


—Michiel

 

On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk <mailto:t...@tink.uk> > 
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 <http://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: CFC: Republish Pointer Lock as CR

[Takayoshi Kochi]

I'm working on updating text to incorporate Shadow DOM in pointer lock
spec.
https://github.com/w3c/webcomponents/issues/192

On Thu, Jun 16, 2016 at 2:06 PM, Vincent Scheib <sch...@google.com> wrote:

> Shadow dom concepts will also be incorporated.
>
> On Thu, Jun 16, 2016 at 1:43 PM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
>
>> On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib <sch...@google.com>
>> wrote:
>>
>> 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.
>>>
>>> [accessibility issue #1] https://github.com/w3c/pointerlock/issues/1
>>>
>>
>> Agreed, that makes good sense. I'll try to help that get done as fast as
>> we can.
>>
>> cheers
>>
>>
>> On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell <dylan.barr...@deque.com>
>>> wrote:
>>>
>>> abstain
>>>>
>>>> On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl>
>>>> wrote:
>>>>
>>>> Looks good, +1
>>>>>
>>>>> —Michiel
>>>>>
>>>>> On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> 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
>>>>
>>>>
>>>>
>>
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>>  cha...@yandex-team.ru - - - Find more at http://yandex.com
>>
>>
>


-- 
Takayoshi Kochi

Re: CFC: Republish Pointer Lock as CR

[Vincent Scheib]

Shadow dom concepts will also be incorporated.

On Thu, Jun 16, 2016 at 1:43 PM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:

> On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib <sch...@google.com>
> wrote:
>
> 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.
>>
>> [accessibility issue #1] https://github.com/w3c/pointerlock/issues/1
>>
>
> Agreed, that makes good sense. I'll try to help that get done as fast as
> we can.
>
> cheers
>
>
> On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell <dylan.barr...@deque.com>
>> wrote:
>>
>> abstain
>>>
>>> On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl> wrote:
>>>
>>> Looks good, +1
>>>>
>>>> —Michiel
>>>>
>>>> On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> 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
>>>
>>>
>>>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  cha...@yandex-team.ru - - - Find more at http://yandex.com
>
>

Re: CFC: Republish Pointer Lock as CR

[Chaals McCathie Nevile]

On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib <sch...@google.com>  
wrote:



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.


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


Agreed, that makes good sense. I'll try to help that get done as fast as  
we can.


cheers


On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell <dylan.barr...@deque.com>
wrote:


abstain

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl> wrote:


Looks good, +1

—Michiel

On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> 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





--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CFC: Republish Pointer Lock as CR

[Vincent Scheib]

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.

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

On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell <dylan.barr...@deque.com>
wrote:

> abstain
>
> On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl> wrote:
>
>> Looks good, +1
>>
>> —Michiel
>>
>> On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> 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: CFC: Republish Pointer Lock as CR

[Dylan Barrell]

abstain

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl> wrote:

> Looks good, +1
>
> —Michiel
>
> On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> 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: CFC: Republish Pointer Lock as CR

[Michiel Bijl]

Looks good, +1

—Michiel

> On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> 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
> 
> 
> 

CFC: Republish Pointer Lock as CR

[Léonie Watson]

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

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

[Alexander Schmitz]

+1
Alexander Schmitz
jQuery Foundation


On Mon, Jun 6, 2016 at 8:31 AM, Ian Pouncey  wrote:
> +1
>
> On 2 June 2016 at 13:48, Léonie Watson  wrote:
>>
>> 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
>>
>>
>>
>>
>

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

[Ian Pouncey]

+1

On 2 June 2016 at 13:48, Léonie Watson  wrote:

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

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

[Adrian Roselli]

+1

On Fri, Jun 3, 2016 at 12:10 PM, Dylan Barrell 
wrote:

> +1
>
> On Fri, Jun 3, 2016 at 9:57 AM, Joanmarie Diggs  wrote:
>
>> +1
>>
>> --joanie
>>
>> On 06/02/2016 08:48 AM, Léonie Watson wrote:
>> > 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
>> >
>> >
>>
>>
>>
>
>
> --
> 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: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

[Dylan Barrell]

+1

On Fri, Jun 3, 2016 at 9:57 AM, Joanmarie Diggs  wrote:

> +1
>
> --joanie
>
> On 06/02/2016 08:48 AM, Léonie Watson wrote:
> > 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
> >
> >
>
>
>


-- 
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: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

[Joanmarie Diggs]

+1

--joanie

On 06/02/2016 08:48 AM, Léonie Watson wrote:
> 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 
> 
> 

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

[Alex Danilo]

+1 for moving HTML5.1 to CR.

Alex

On 3 June 2016 at 05:30, Gez Lemon  wrote:

> +1
>
> On 2 June 2016 at 13:48, Léonie Watson  wrote:
>
>> 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
>>
>>
>>
>>
>>
>
>
> --
> _
> Senior Accessibility Engineer
> The Paciello Group
>
> This message is intended to be confidential and may be legally privileged.
> It is intended solely for the addressee. If you are not the intended
> recipient, please delete this message from your system and notify us
> immediately. Any disclosure, copying, distribution or action taken or
> omitted to be taken by an unintended recipient in reliance on this message
> is prohibited and may be unlawful.
>

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

[Gez Lemon]

+1

On 2 June 2016 at 13:48, Léonie Watson  wrote:

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


-- 
_
Senior Accessibility Engineer
The Paciello Group

This message is intended to be confidential and may be legally privileged.
It is intended solely for the addressee. If you are not the intended
recipient, please delete this message from your system and notify us
immediately. Any disclosure, copying, distribution or action taken or
omitted to be taken by an unintended recipient in reliance on this message
is prohibited and may be unlawful.

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

[wayne carr]

+1 for moving HTML5.1 to CR

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

[Steve Faulkner]

aye - (as TPG WG person)

--

Regards

SteveF
Current Standards Work @W3C


On 2 June 2016 at 13:48, Léonie Watson  wrote:

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

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

[Chaals McCathie Nevile]

On Thu, 02 Jun 2016 14:48:10 +0200, Léonie Watson  wrote:


Hello WP,

This is a call for consensus to request that W3C publish the current HTML
Working Draft (WD) as a Candidate Recommendation (CR).


+1 Please do.

chaals - Yandex hat on, chair hat off

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

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

[Léonie Watson]

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

About the packaging spec Re: CFC

[Chaals McCathie Nevile]

Hi Marcos,

On Wed, 25 May 2016 00:52:07 +0100, <mar...@marcosc.com> wrote:


On 25 May 2016, at 3:54 AM, Léonie Watson <t...@tink.uk> wrote:



At the AC meeting in March 2016 the WP co-chairs indicated that the
Packaging on the Web specification [1] would benefit from further  
incubation before continuing along the Recommendation track.


This is a CFC to publish Packaging on the Web as a W3C note.


We generally "gut" Notes to avoid confusion and prevent implementation.  
It might be fine to gut it if there is no implementer interest  
(particularly give Service Workers and HTTP2).


But then, we should not use "incubation" as a euphemism for "no one is  
going to implement this and we don't want it" as it demeans the work of  
groups like the WIGC - that actually do incubation.


I agree that "We're trying to kill this work" should not be expressed as
"needs incubation". That's not the situation.


At least, I will strongly object to the use of that word if your
intention is to kill the spec.


It is not our intention to kill the spec, however we think that the
current approach should be sidelined - and if people are interested,
incubated - to make way for a shorter-term approach we believe will get
more traction as an interim solution.


So, what then is the real reason for WP terminating work on the spec?


You're right that we do not think the spec is going to go forward in a
hurry. It has several nice features, and we presume the TAG wasn't just
whistling in the wind, so incubating it seems a reasonable thing to do.

There is a lot of implementation of packaging mechanisms that are
basically "zip and a manifest". We expect that someone will propose
something based on that and that it can get traction - much like the
previous Recommendation along those lines, in which you were heavily
involved.

In the meantime, moving the current draft specification aside allows us to
start a new one, which clarifies the IPR situation - something we
understand is a concern for some members, even if only so they don't have
to get a legal clearance because we're basically rehashing old technology
with an established recommendation behind it, in a new syntax.


Can we see the minutes from the rationale given to the AC?


I doubt it. They are confidential and the work to get them approved for
release - asking everyone involved, given that they spoke in the
expectation of confidentiality - seems excessive for the relative value.
Since you personally have access, you're welcome to look and see if you
think it's worth the effort.


If the CFC passes, the transition of the specification to note status
will be done within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to
public-webapps@w3.org no later than 2nd June 2016. Positive responses  
are preferred and encouraged, but silence will be considered as

agreement with the proposal.


Is the plan then to transition it to the WICG for incubation? If so, we  
can just take it and there is no need for process - but we only take it  
if there is actual implementer interest and not if it's not going  
anywhere.


That's a judgement call. *I* do not know of implementor interest.

cheers


Léonie on behalf of the WP chairs and team.
[1] http://w3ctag.github.io/packaging-on-the-web/

--
@LeonieWatson tink.uk Carpe diem









--
Charles McCathie Nevile - web standards - CTO Office, Yandex
   cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CFC

[marcos]

> On 25 May 2016, at 3:54 AM, Léonie Watson <t...@tink.uk> wrote:
> 
> Hello WP,
> 
> At the AC meeting in March 2016 the WP co-chairs indicated that the
> Packaging on the Web specification [1] would benefit from further incubation
> before continuing along the Recommendation track.
> 
> This is a CFC to publish Packaging on the Web as a W3C note.

We generally "gut" Notes to avoid confusion and prevent implementation. It 
might be fine to gut it if there is no implementer interest (particularly give 
Service Workers and HTTP2). 

But then, we should not use "incubation" as a euphemism for "no one is going to 
implement this and we don't want it" as it demeans the work of groups like the 
WIGC - that actually do incubation. At least, I will strongly object to the use 
of that word if your intention is to kill the spec. 

So, what then is the real reason for WP terminating work on the spec? Can we 
see the minutes from the rationale given to the AC? 

> If the CFC
> passes, the transition of the specification to note status will be done
> within the current WP WG charter.
> 
> If you have comments or concerns about this CFC, please send them to
> public-webapps@w3.org no later than 2nd June 2016. Positive responses are
> preferred and encouraged, but silence will be considered as agreement with
> the proposal.

Is the plan then to transition it to the WICG for incubation? If so, we can 
just take it and there is no need for process - but we only take it if there is 
actual implementer interest and not if it's not going anywhere. 

> 
> Léonie on behalf of the WP chairs and team.
> [1] http://w3ctag.github.io/packaging-on-the-web/ 
> 
> -- 
> @LeonieWatson tink.uk Carpe diem
> 
> 
> 
> 

RE: CFC: Convert Packaging on the Web to a W3C note

[Léonie Watson]

With the subject line repaired this time...


> -Original Message-
> From: Léonie Watson [mailto:t...@tink.uk]
> Sent: 24 May 2016 18:54
> To: public-webapps@w3.org
> Subject: CFC
> 
> Hello WP,
> 
> At the AC meeting in March 2016 the WP co-chairs indicated that the
> Packaging on the Web specification [1] would benefit from further
incubation
> before continuing along the Recommendation track.
> 
> This is a CFC to publish Packaging on the Web as a W3C note. If the CFC
> passes, the transition of the specification to note status will be done
within
> the current WP WG charter.
> 
> If you have comments or concerns about this CFC, please send them to
> public-webapps@w3.org no later than 2nd June 2016. Positive responses are
> preferred and encouraged, but silence will be considered as agreement with
> the proposal.
> 
> Léonie on behalf of the WP chairs and team.
> [1] http://w3ctag.github.io/packaging-on-the-web/
> 
> --
> @LeonieWatson tink.uk Carpe diem
> 
> 
> 

CFC

[Léonie Watson]

Hello WP,

At the AC meeting in March 2016 the WP co-chairs indicated that the
Packaging on the Web specification [1] would benefit from further incubation
before continuing along the Recommendation track.

This is a CFC to publish Packaging on the Web as a W3C note. If the CFC
passes, the transition of the specification to note status will be done
within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to
public-webapps@w3.org no later than 2nd June 2016. Positive responses are
preferred and encouraged, but silence will be considered as agreement with
the proposal.

Léonie on behalf of the WP chairs and team.
[1] http://w3ctag.github.io/packaging-on-the-web/ 

-- 
@LeonieWatson tink.uk Carpe diem

Re: CFC: Publish as W3C Notes

[Chaals McCathie Nevile]

On Tue, 26 Apr 2016 19:05:52 +0100, Léonie Watson <t...@tink.uk> wrote:


At the AC meeting in March 2016 the WP co-chairs indicated that the
following two specifications would benefit from further incubation before
continuing along the Recommendation track:

Quota Management API [1]
Input Method Editor API [2]

This is a CFC to publish each of these specifications as a W3C note,  
under the Software and Document License. Anyone wishing to take these

ideas further is then welcome to use the notes to seed incubation within
WICG or elsewhere.


With positive support and no dissent, the chairs have resolved that these  
two specifications will be published as Notes.


For now, they are unlikely to be further developed within the Working  
Group, but the license means anyone can take them and develop them further  
to try and get enough support to bring them back as active deliverables.


for the chairs

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

CFC: Publish as W3C Notes

[Léonie Watson]

Hello,

At the AC meeting in March 2016 the WP co-chairs indicated that the
following two specifications would benefit from further incubation before
continuing along the Recommendation track:

Quota Management API [1]
Input Method Editor API [2]

This is a CFC to publish each of these specifications as a W3C note, under
the Software and Document License. Anyone wishing to take these ideas
further is then welcome to use the notes to seed incubation within WICG or
elsewhere.

If the CFC passes, the transition of each specification to note status will
be done within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to
public-webapps@w3.org no later than Wednesday 4th May 2016. Positive
responses are preferred and encouraged, and silence will be considered as
agreement with the proposal.

Léonie on behalf of the WP chairs and team.
[1] https://w3c.github.io/quota-api/
[2] https://w3c.github.io/ime-api/
-- 
@LeonieWatson tink.uk Carpe diem

Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Art,

On 12/02/2015 02:23 PM, Arthur Barstow wrote:
> Yves and Travis would like to publish a Candidate Recommendation
> of WebIDL Level 1 and this is a Call for Consensus to do so. The
> draft CR is:
> 
> <https://ylafon.github.io/webidl/publications/cr-20151124.html>
> 
> If anyone has comments or concerns about this CfC, please reply by 
> December 9 at the latest. Silence will be considered as agreeing
> with the proposal and explicit responses are preferred. If no
> non-resolvable blocking issues are raised, this CfC will be
> considered as passing and we will proceed with a CR publication.
> 

I'd like to see the difference between this proposed CR and the latest
editor's draft.

Thanks
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWXwo9AAoJEOXgvIL+s8n284QH/1Q1qBZW6Cg+HacdgWbCNhBj
tZJ4uRm+m3mTeTr21cXmh2J79lhqFHv8lkX/T+mpe9/B5Z8VHFbA/ZAxDRoQKV25
J4Wtx0lZtt90m0hP1gPG1jMYSIpy94RY+PGBnZ/tAa4IPjCGtuOhDRCdXL4VQ9gn
DzdV5wOkVCWmAZCbq39x3D+y8PfDMyd8p3qkB304y+wHkVhhNkn5/47mk18HP6C5
ry5ljb7iZz+d2QeJBeJd96S7QqbOJEOt7FaQR7oqkj/tScLs6atSZlKn2l3s0B1Q
GmoyKsZTSRU2NWwKDfDZ775fCBwGLqGYBpSzgrInuGYTZmDgu4GHsD9OxmPwXXM=
=rY+n
-END PGP SIGNATURE-

Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Yves Lafon]

> On 02 Dec 2015, at 16:11, Ms2ger <ms2...@gmail.com> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Art,
> 
> On 12/02/2015 02:23 PM, Arthur Barstow wrote:
>> Yves and Travis would like to publish a Candidate Recommendation
>> of WebIDL Level 1 and this is a Call for Consensus to do so. The
>> draft CR is:
>> 
>> <https://ylafon.github.io/webidl/publications/cr-20151124.html>
>> 
>> If anyone has comments or concerns about this CfC, please reply by 
>> December 9 at the latest. Silence will be considered as agreeing
>> with the proposal and explicit responses are preferred. If no
>> non-resolvable blocking issues are raised, this CfC will be
>> considered as passing and we will proceed with a CR publication.
>> 
> 
> I'd like to see the difference between this proposed CR and the latest
> editor's draft.

(Sorry, some messages went to one ML only, reposting here the information about 
the difference).

This is the same as the previous Level 1 WD (well, same differences, as the 
proposed CR doc is with the latest modifications to the edcopy, like with Date 
removed.
So same as http://heycam.github.io/webidl/ with maplike, setlike, 
[ImplicitThis], [Unscopeable], RegExp, FrozenArray and LegacyArrayClass removed.
Thanks,

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

~~Yves

CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Arthur Barstow]

Yves and Travis would like to publish a Candidate Recommendation of 
WebIDL Level 1 and this is a Call for Consensus to do so. The draft CR is:


<https://ylafon.github.io/webidl/publications/cr-20151124.html>

If anyone has comments or concerns about this CfC, please reply by 
December 9 at the latest. Silence will be considered as agreeing with 
the proposal and explicit responses are preferred. If no non-resolvable 
blocking issues are raised, this CfC will be considered as passing and 
we will proceed with a CR publication.


-Thanks, ArtB

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Boris Zbarsky]

On 11/30/15 8:31 AM, Xiaoqian Wu wrote:

The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have 
been widely implemented by the major browser vendors.


Compatibly?  Last I checked, for example, Blink doesn't support 
Dedicated Workers inside workers, only inside Window.  I agree that 
there is some subset of dedicated worker support that is widely 
implemented; I'm just not sure what that subset is.


-Boris

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Xiaoqian Wu]

> On 30 Nov 2015, at 10:02 PM, Boris Zbarsky  wrote:
> 
> On 11/30/15 8:31 AM, Xiaoqian Wu wrote:
>> The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers 
>> have been widely implemented by the major browser vendors.
> 
> Compatibly?  Last I checked, for example, Blink doesn't support Dedicated 
> Workers inside workers, only inside Window.  I agree that there is some 
> subset of dedicated worker support that is widely implemented; I'm just not 
> sure what that subset is.

Right, nested workers are at-risk[1] as well as shared-workers.

--
xiaoqian

[1] 
https://w3c.github.io/test-results/workers/dedicated-less-than-2#test-file-15 

> 
> -Boris
> 

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Ms2ger]

On 11/30/2015 02:31 PM, Xiaoqian Wu wrote:
> This is a call for comments regarding the next step of Web Workers.
> 
> The latest [TEST RESULTS] of Web Workers indicate that Dedicated
> Workers have been widely implemented by the major browser vendors.
> 
> [Diff] between the latest W3C WD and the WHATWG living standard
> suggests substantial changes about the WorkerLocation interface, and
> the test results of the [WorkerLocationTestCases] show that these
> changes have been adapted by more than two major browsers.
> 
> As for Shared workers, [TEST RESULTS] suggest that this feature is
> still poorly supported. Right now both Apple and Microsoft don’t
> intend to implement it, Chrome supports only a small part of it.
> There were issues raised about [Removing-Sharedworkers] on GitHub,
> one suggestion was to pull it out into a separate working note,
> whereas others thought it’s too early to do so.
> 
> Hence our questions to the group: Is the group still interested in
> moving Workers forward? Is it the right time to publish Workers as a
> CR? Should SharedWorkers be removed from this spec?
> 
> Please provide your thoughts on these questions by Dec 14 2015. If
> there’s no interest from the members to continue the work of
> WebWorkers in W3C, we will probably stop publishing new versions of
> this spec.
> 

Let's publish it as a REC; that no longer needs interop anyway (see:
DOM4 is a REC).

HTH
Ms2ger

CfC: Is Web Workers Ready for CR? deadline Dec 14

[Xiaoqian Wu]

This is a call for comments regarding the next step of Web Workers.

The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have 
been widely implemented by the major browser vendors.

[Diff] between the latest W3C WD and the WHATWG living standard suggests 
substantial changes about the WorkerLocation interface, and the test results of 
the [WorkerLocationTestCases] show that these changes have been adapted by more 
than two major browsers.

As for Shared workers, [TEST RESULTS] suggest that this feature is still poorly 
supported. Right now both Apple and Microsoft don’t intend to implement it, 
Chrome supports only a small part of it. There were issues raised about 
[Removing-Sharedworkers] on GitHub, one suggestion was to pull it out into a 
separate working note, whereas others thought it’s too early to do so.

Hence our questions to the group: Is the group still interested in moving 
Workers forward? Is it the right time to publish Workers as a CR? Should 
SharedWorkers be removed from this spec?

Please provide your thoughts on these questions by Dec 14 2015. If there’s no 
interest from the members to continue the work of WebWorkers in W3C, we will 
probably stop publishing new versions of this spec.

Thanks.

-xiaoqian

-
[TEST RESULTS]:
dedicatedworkers-all: https://w3c.github.io/test-results/workers/dedicated-all
dedicatedworkers-less-than-2: 
https://w3c.github.io/test-results/workers/dedicated-less-than-2
dedicatedworkers-complete-fails: 
https://w3c.github.io/test-results/workers/dedicated-complete-fails
workers-all: https://w3c.github.io/test-results/workers/all
workers-less-than-2: https://w3c.github.io/test-results/workers/less-than-2
workers-complete-fails: 
https://w3c.github.io/test-results/workers/complete-fails

[Diff]: 
https://www.diffchecker.com/5zbz229w

[WorkerLocationTestCases]: 
http://w3c.github.io/test-results/workers/all.html#test-file-9

[Removing-sharedworkers]: 
https://github.com/whatwg/html/issues/315
https://github.com/w3c/workers/issues/2

Re: CfC: publish Proposed Recommendation of Web Storage 2nd Edition; deadline October 27

[Arthur Barstow]

Hi Xiaoqian - this CfC passed so please go forward with PR publication 
as you proposed below. -Thanks!


On 10/20/15 1:31 PM, Xiaoqian Wu wrote:

This is a Call for Consensus to publish a Proposed Recommendation of Web 
Storage (Second Edition) using the [PR] as the basis. Agreement with this CfC 
means you consider the test results shows interoperability and the changes 
since CR are not substantive.

The test results for Web Storage (Second Edition) [All] indicate significant 
interoperability, with only three tests that have less than two passes [<2]. 
These three tests, including a short analysis of the failure, are:

1. <http://www.w3c-test.org/webstorage/idlharness.html>; this test failure 
(which passes on Firefox) can be considered more of a Web IDL implementation issue. 
The group believes it will get better over time as WebIDL compliance progresses.

2. <http://www.w3c-test.org/webstorage/event_body_attribute.html> (which pass on 
Chrome); <http://www.w3c-test.org/webstorage/event_setattribute.html> (which pass on 
Chrome); The expected test results for these two test cases are not defined in the spec. 
The failures can be ignored as the spec move to PR.

We intend to remove those two [OPEN ISSUES] in the previous CR, which were 
raised in 2009, for the lack of interest from the editors and the implementors 
to continue the discussion. The current two [GIT ISSUES] are either resolved 
(#4) or non-substantive (#5).

Other changes includes:
* Fixed typos raised by issue#5 in [GIT ISSUES].
* Changed the Editor’s Draft to the WHATWG version.
* IDL update of the storage interface: setter creator void setItem(DOMString key, 
DOMString value) -> setter void setItem(DOMString key, DOMString value).
* Updated the refs to DOM and WebIDL.

We consider the changes since the CR as non-substantive. See [Diff] for all of 
changes between the CR and the draft PR.

We propose to publish the PR of Web Storage 2nd Edition under the Web 
Application Working Group, which has been merged to the Web Platform Working 
Group lately. Due to patent policy reasons, the next step for the Web Storage 
2nd Edition spec in Web Platform Working Group would be to publish a FPCR (i.e. 
a CR which is also a FPWD). Given that the Web Applications working group isn't 
closed, we believe a PR under the WebApps WG will be the simplest feasible 
option for WebStorage 2nd Edition.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by October 27 at the latest. Positive response is preferred and 
encouraged, and silence will be considered as agreement with the proposal. If 
there are no non-resolvable objections to this proposal, the motion will carry 
and we will request the PR be published on November 05 2015.

Thanks.

--
xiaoqian

[PR] https://w3c.github.io/webstorage/PR-webstorage-20151105.html
[All] https://w3c.github.io/test-results/webstorage/all
[<2] https://w3c.github.io/test-results/webstorage/less-than-2
[OPEN ISSUES] http://www.w3.org/TR/2015/CR-webstorage-20150609/#issues
[GIT ISSUES] https://github.com/w3c/webstorage/issues
[Diff] 
http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2015%2FCR-webstorage-20150609%2F=https%3A%2F%2Fw3c.github.io%2Fwebstorage%2FPR-webstorage-20151105.html

CfC: publish Proposed Recommendation of Web Storage 2nd Edition; deadline October 27

[Xiaoqian Wu]

This is a Call for Consensus to publish a Proposed Recommendation of Web 
Storage (Second Edition) using the [PR] as the basis. Agreement with this CfC 
means you consider the test results shows interoperability and the changes 
since CR are not substantive.

The test results for Web Storage (Second Edition) [All] indicate significant 
interoperability, with only three tests that have less than two passes [<2]. 
These three tests, including a short analysis of the failure, are:

1. <http://www.w3c-test.org/webstorage/idlharness.html>; this test failure 
(which passes on Firefox) can be considered more of a Web IDL implementation 
issue. The group believes it will get better over time as WebIDL compliance 
progresses.

2. <http://www.w3c-test.org/webstorage/event_body_attribute.html> (which pass 
on Chrome); <http://www.w3c-test.org/webstorage/event_setattribute.html> (which 
pass on Chrome); The expected test results for these two test cases are not 
defined in the spec. The failures can be ignored as the spec move to PR.

We intend to remove those two [OPEN ISSUES] in the previous CR, which were 
raised in 2009, for the lack of interest from the editors and the implementors 
to continue the discussion. The current two [GIT ISSUES] are either resolved 
(#4) or non-substantive (#5).

Other changes includes:
* Fixed typos raised by issue#5 in [GIT ISSUES].
* Changed the Editor’s Draft to the WHATWG version.
* IDL update of the storage interface: setter creator void setItem(DOMString 
key, DOMString value) -> setter void setItem(DOMString key, DOMString value).
* Updated the refs to DOM and WebIDL.

We consider the changes since the CR as non-substantive. See [Diff] for all of 
changes between the CR and the draft PR.

We propose to publish the PR of Web Storage 2nd Edition under the Web 
Application Working Group, which has been merged to the Web Platform Working 
Group lately. Due to patent policy reasons, the next step for the Web Storage 
2nd Edition spec in Web Platform Working Group would be to publish a FPCR (i.e. 
a CR which is also a FPWD). Given that the Web Applications working group isn't 
closed, we believe a PR under the WebApps WG will be the simplest feasible 
option for WebStorage 2nd Edition.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by October 27 at the latest. Positive response is preferred and 
encouraged, and silence will be considered as agreement with the proposal. If 
there are no non-resolvable objections to this proposal, the motion will carry 
and we will request the PR be published on November 05 2015.

Thanks.

--
xiaoqian

[PR] https://w3c.github.io/webstorage/PR-webstorage-20151105.html
[All] https://w3c.github.io/test-results/webstorage/all
[<2] https://w3c.github.io/test-results/webstorage/less-than-2
[OPEN ISSUES] http://www.w3.org/TR/2015/CR-webstorage-20150609/#issues
[GIT ISSUES] https://github.com/w3c/webstorage/issues
[Diff] 
http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2015%2FCR-webstorage-20150609%2F=https%3A%2F%2Fw3c.github.io%2Fwebstorage%2FPR-webstorage-20151105.html

Call for Consensus (CfC) to close the Web Intents Task Force - Deadline October 29, 2015

[Frederick Hirsch]

This is a Call for Consensus (CfC) to close the Web Intents Task Force [1].

This Task Force has been inactive for some time.  There are no relevant 
deliverables in the draft revision of the DAP WG charter [2], or the Web 
Platform WG charter [3].

The purpose of this CfC is obtain consensus to explicitly close the Task Force. 
If you agree with closing the Task Force a response with a +1 would be useful;  
if you have concerns please note them. Silence will be assumed to be agreement.

I believe the TF mail archive will remain despite the TF being closed.

Please respond by October 29, 2015 (2 weeks) to this CfC.

Thanks

regards, Frederick

Frederick Hirsch
Chair, W3C Device APIs WG (DAP)

www.fjhirsch.com
@fjhirsch

[1] http://www.w3.org/2009/dap/#webintents

[2] http://w3c.github.io/dap-charter/DeviceAPICharter.html

[3] http://www.w3.org/2015/10/webplatform-charter.html

CfC: Transition "Secure Contexts" to CR; deadline October 1st.

[Mike West]

BCC: www-tag@, public-webapps@, public-privacy@, public-geolocation@,
public-review-announce@.

Hello, WebAppSec! Two weeks ago, I noted that Secure Contexts was pretty
much done, and ready to review (
https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0068.html).
I've made some changes to the doc based on feedback during that period
(thanks mostly to Anne), and I think we're close enough to call it done and
see if anyone points out crazy things I've missed. :)

This is a call for consensus to transition to Candidate Recommendation with
the document at:

https://w3c.github.io/webappsec/specs/powerfulfeatures/published/2015-10-CR.html

The core of the specification is already implemented in Chrome and Firefox,
and is used in a number of specifications to gate certain features (like
Service Workers) to contexts which offer guarantees about their usage. I
expect those implementations can align with the specification fairly
quickly, and I don't believe anything in the document needs to be marked as
"at risk".

As discussed on public-webapps@, this document references WHATWG documents
in several places where the W3C version is out of date. A list of the
referenced terms are available for review at
https://w3c.github.io/webappsec/specs/powerfulfeatures/#index-defined-elsewhere
.

The deadline for this CfC is one week from today, October 1st. As always,
explicit (positive!) feedback to public-webapp...@w3.org is appreciated!

--
Mike West <mk...@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Fwd: [webappsec] CfC: Proposed non-normative updates to CORS

[Brad Hill]

(Dang, just realized I forgot to include WebApps on this joint deliverable.)

Members of WebApps, please note the below Call for Consensus on proposed
non-normative updates to the CORS recommendation and comment on
public-webapp...@w3.org by Monday, August 10, 2015.

Thank you,

Brad Hill
co-chair, WebAppSec WG

-- Forwarded message -
From: Brad Hill hillb...@gmail.com
Date: Tue, Jun 30, 2015 at 2:05 PM
Subject: [webappsec] CfC: Proposed non-normative updates to CORS
To: public-webapp...@w3.org public-webapp...@w3.org


In response to https://www.w3.org/Bugs/Public/show_bug.cgi?id=28861 and
other requests, I would like to propose the following non-normative edits
to the CORS Recommendation. (http://www.w3.org/TR/cors/)

See attached file for the proposed publication-ready document including
these edits.

A detailed description of the proposed edits follows:

1) Remove text referring to expected changes in HTML5 and the HTTP Status
Code 308, as both have advanced to REC and RFC status, respectively.

2) Update the HTTP Status Code 308 reference to point to RFC7538

3) Remove text and links for implementation reports that are 404.

4) Add the following to the end of SOTD:

p Development of the CORS algorithm after 2013 has continued in the a
href=https://fetch.spec.whatwg.org/;Fetch Living Standard/a. /p

5) Correct Section 6.2 Preflight Request, step 10, second Note, to
correctly refer to Access-Control-Request-Headers.

These changes do not impact the conformance characteristics of any user
agent implementation.  This is a call for consensus to publish these
changes, which will end in 10 days, on July 10th.

Sincerely,

Brad Hill
WebAppSec co-chair
Title: Cross-Origin Resource Sharing

 
  





   Cross-Origin Resource Sharing

   W3C Recommendation 16 January 2014

   
This Version:
http://www.w3.org/TR/2014/REC-cors-20140116/

 Latest Version:
 http://www.w3.org/TR/cors/

Previous Versions:
http://www.w3.org/TR/2013/PR-cors-20131205/
http://www.w3.org/TR/2013/CR-cors-20130129/
http://www.w3.org/TR/2012/WD-cors-20120403/
http://www.w3.org/TR/2010/WD-cors-20100727/
http://www.w3.org/TR/2009/WD-cors-20090317/
http://www.w3.org/TR/2008/WD-access-control-20080912/
http://www.w3.org/TR/2008/WD-access-control-20080214/
http://www.w3.org/TR/2007/WD-access-control-20071126/
http://www.w3.org/TR/2007/WD-access-control-20071001/
http://www.w3.org/TR/2007/WD-access-control-20070618/
http://www.w3.org/TR/2007/WD-access-control-20070215/
http://www.w3.org/TR/2006/WD-access-control-20060517/
http://www.w3.org/TR/2005/NOTE-access-control-20050613/

Editor:
Anne van Kesteren
(formerly of Opera Software ASA)
ann...@annevk.nl
   
Please note there may be errata for this document.
  
  The English version of this specification is the only normative version. Non-normative
  translations may also be available.
  



Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

  


  



  Abstract

  This document defines a mechanism to enable client-side cross-origin
  requests. Specifications that enable an API to make cross-origin requests
  to resources can use the algorithms defined by this specification. If
  such an API is used on http://example.org resources, a
  resource on http://hello-world.example can opt in using the
  mechanism described by this specification (e.g., specifying
  Access-Control-Allow-Origin: http://example.org as response
  header), which would allow that resource to be fetched cross-origin from
  http://example.org.




  Status of this Document

This section describes the status of this document at the time of
  its publication. Other documents may supersede this document. A list of
  current W3C publications and the latest revision of this technical report
  can be found in the
  W3C technical reports index at
  http://www.w3.org/TR/.

  This document has been reviewed by W3C Members, by software developers,
and by other W3C groups and interested parties, and is endorsed by the
Director as a W3C Recommendation. It is a stable document and may be
used as reference material or cited from another document. W3C's role in
making the Recommendation is to draw attention to the specification and
to promote its widespread deployment. This enhances the functionality
and interoperability of the Web.

  This W3C Recommendation of CORS was produced jointly by the
  Web Applications (WebApps)
  and
  Web Application
  Security (WebAppSec) Working Groups, and published by the
  WebAppSec Working Group. No changes were made since the previous
  publication as Proposed Recommendation.
  If you wish to make comments regarding this document, please send them to 
  public-webapp...@w3.org 
  (subscribe,
  archives).


 This document was produced by groups operating under the 5

CfC: publish Candidate Recommendation of Web Storage 2nd Edition deadline June 3 [Was: CfC: Moving webstorage to REC 2nd Edition]

[Arthur Barstow]

On 5/28/15 11:38 AM, Xiaoqian Wu wrote:

Hi Art, and all,

I believe we have enough review on the current editor's draft to publish 
directly a CR. We don't need to do the extra WD step. If implementors or others 
have additional comments, they can do so during the CR phase. So I propose that 
we publish a CR directly.


This all sounds fine to me. However, strictly speaking I believe we need 
to record the group's consensus to publish a Candidate Recommendation. 
As such, let's consider this e-mail as a CfC to publish a CR to publish 
a CR of Web Storage 2nd edition.


If anyone has comments or concerns about this CfC, please reply by June 
3 at the latest. Silence will be considered as agreeing with the 
proposal and explicit responses are preferred. If no non-resolvable 
blocking issues are raised, this CfC will be considered as passing and 
we will proceed with this proposal.


-Thanks, ArtB




Thanks.

—
xiaoqian


On 2015-5-14, at 7:30pm, Arthur Barstow art.bars...@gmail.com wrote:

Hi All,

Based on Xiaoqian's analysis [1] of Web Storage changes since the REC was 
published in 2013, this is a Call for Consensus to:

1. Publish a new WD of the spec and to seek wide review of the spec, per 
process 2014. The new WD will be placed in w3.org/TR/webstorage/. The draft WD 
is [2] and the review period will be three weeks. The draft includes a summary 
of the changes since the REC was published [3].

2. Update the REC errata doc [4] to include a reference to the new WD and its 
changes since REC section, and the github commit history.

If you have any comments or concerns about this CfC, please reply by May 21 at 
the latest. Silence will be considered as agreeing with the proposal and 
explicit responses are preferred. If no non-resolvable blocking issues are 
raised, this CfC will be considered as passing and we will proceed with this 
proposal.

-Thanks, ArtB

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0607.html
[2] https://w3c.github.io/webstorage/
[3] https://w3c.github.io/webstorage/#status-of-this-document
[4] http://dev.w3.org/html5/webstorage/publish/errata-v1.html

Re: CfC: Moving webstorage to REC 2nd Edition; deadline May 21

[Xiaoqian Wu]

Hi Art, and all,

I believe we have enough review on the current editor's draft to publish 
directly a CR. We don't need to do the extra WD step. If implementors or others 
have additional comments, they can do so during the CR phase. So I propose that 
we publish a CR directly.

Thanks.

—
xiaoqian

 On 2015-5-14, at 7:30pm, Arthur Barstow art.bars...@gmail.com wrote:
 
 Hi All,
 
 Based on Xiaoqian's analysis [1] of Web Storage changes since the REC was 
 published in 2013, this is a Call for Consensus to:
 
 1. Publish a new WD of the spec and to seek wide review of the spec, per 
 process 2014. The new WD will be placed in w3.org/TR/webstorage/. The draft 
 WD is [2] and the review period will be three weeks. The draft includes a 
 summary of the changes since the REC was published [3].
 
 2. Update the REC errata doc [4] to include a reference to the new WD and its 
 changes since REC section, and the github commit history.
 
 If you have any comments or concerns about this CfC, please reply by May 21 
 at the latest. Silence will be considered as agreeing with the proposal and 
 explicit responses are preferred. If no non-resolvable blocking issues are 
 raised, this CfC will be considered as passing and we will proceed with this 
 proposal.
 
 -Thanks, ArtB
 
 [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0607.html
 [2] https://w3c.github.io/webstorage/
 [3] https://w3c.github.io/webstorage/#status-of-this-document
 [4] http://dev.w3.org/html5/webstorage/publish/errata-v1.html
 

RE: [W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP and UDP Socket API to a Community Group

[Nilsson, Claes1]

There were no objections on the proposal in this CFC and one positive response 
(https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0035.html).

Accordingly I will issue a request for relicensing.

BR
  Claes

Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.commailto:firstname.lastn...@sonymobile.com

sonymobile.comhttp://sonymobile.com/

[cid:image001.png@01D09738.D8FFCD30]

From: Nilsson, Claes1
Sent: den 14 april 2015 10:08
To: public-sysa...@w3.org
Cc: public-webapps; Device APIs Working Group; 'Domenic Denicola'; 
'slightly...@google.com'; 'jyass...@google.com'
Subject: [W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP 
and UDP Socket APi to a Community Group

The SysApps WG charter expired Oct 1 2014 and no re-chartering process is in 
progress. Similar to Wayne Carr's CfC on Intel's SysApps specification, 
https://lists.w3.org/Archives/Public/public-sysapps/2015Mar/0001.html, I am 
issuing an informal CfC on moving the SysApps TCP and UDP Socket API to a 
Community Group. The latest version of the TCP and UDP Socket API is: 
http://www.w3.org/2012/sysapps/tcp-udp-sockets/.

The main reason why moving to a Community Group, instead of a Working Group, is 
proposed is that the original assumption for this API was a secure Web System 
Applications Runtime, standardized by the SysApps WG. As this has not been 
defined the main issue with the TCP and UDP Socket API is security, i.e. it 
does not fit with the Web Security model as it is defined today. However, in 
the current version of the API there is defined an approach to meet this issue, 
see https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0001.html for 
more information.

The purpose of this informal CfC is to determine consensus on the following 
proposition:
The members of the SysApps WG do not object to moving the TCP and UDP Socket 
API to a Community Group where other Community Groups or anyone outside W3C 
would be allowed to
take and develop them (as allowed by the Community Group Contributor License 
Agreement).

Please respond be end of day 24 April 2014.  As usual in a CfC, silence is 
considered agreement with the proposal, but a direct response is preferred.  It 
would be very helpful to express any objection.

Best regards

Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.commailto:firstname.lastn...@sonymobile.com

sonymobile.comhttp://sonymobile.com/

[cid:image002.png@01D09738.D8FFCD30]

Re: CfC: Moving webstorage to REC 2nd Edition; deadline May 21

[Kostiainen, Anssi]

 On 14 May 2015, at 14:30, Arthur Barstow art.bars...@gmail.com wrote:
 
 1. Publish a new WD of the spec and to seek wide review of the spec, per 
 process 2014. The new WD will be placed in w3.org/TR/webstorage/.

This addresses the concern and clears the confusion around an outdated /TR.

 If you have any comments or concerns about this CfC, please reply by May 21 
 at the latest. Silence will be considered as agreeing with the proposal and 
 explicit responses are preferred. If no non-resolvable blocking issues are 
 raised, this CfC will be considered as passing and we will proceed with this 
 proposal.

+1. Thanks for the swift turnaround.

Thanks,

-Anssi

RE: CfC: Moving webstorage to REC 2nd Edition; deadline May 21

[Zhang, Zhiqiang]

 From: Kostiainen, Anssi [mailto:anssi.kostiai...@intel.com]
 Sent: Thursday, May 14, 2015 21:16
 To: Arthur Barstow
 Cc: public-webapps
 Subject: Re: CfC: Moving webstorage to REC 2nd Edition; deadline May 21
 
  On 14 May 2015, at 14:30, Arthur Barstow art.bars...@gmail.com wrote:
 
  1. Publish a new WD of the spec and to seek wide review of the spec, per
 process 2014. The new WD will be placed in w3.org/TR/webstorage/.
 
 This addresses the concern and clears the confusion around an outdated /TR.

Yes, the spec looks good to me.

  If you have any comments or concerns about this CfC, please reply by May
 21 at the latest. Silence will be considered as agreeing with the proposal and
 explicit responses are preferred. If no non-resolvable blocking issues are
 raised, this CfC will be considered as passing and we will proceed with this
 proposal.
 
 +1. Thanks for the swift turnaround.

I also regenerated an implementation report at

http://w3c.github.io/test-results/webstorage/all.html

... for your reference.

BTW: I have sent out the above info yesterday, but seems the mailing list 
system didn't get it.

Thanks,
Zhiqiang

CfC: Moving webstorage to REC 2nd Edition; deadline May 21

[Arthur Barstow]

Hi All,

Based on Xiaoqian's analysis [1] of Web Storage changes since the REC 
was published in 2013, this is a Call for Consensus to:


1. Publish a new WD of the spec and to seek wide review of the spec, per 
process 2014. The new WD will be placed in w3.org/TR/webstorage/. The 
draft WD is [2] and the review period will be three weeks. The draft 
includes a summary of the changes since the REC was published [3].


2. Update the REC errata doc [4] to include a reference to the new WD 
and its changes since REC section, and the github commit history.


If you have any comments or concerns about this CfC, please reply by May 
21 at the latest. Silence will be considered as agreeing with the 
proposal and explicit responses are preferred. If no non-resolvable 
blocking issues are raised, this CfC will be considered as passing and 
we will proceed with this proposal.


-Thanks, ArtB

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0607.html
[2] https://w3c.github.io/webstorage/
[3] https://w3c.github.io/webstorage/#status-of-this-document
[4] http://dev.w3.org/html5/webstorage/publish/errata-v1.html

[W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP and UDP Socket APi to a Community Group

[Nilsson, Claes1]

The SysApps WG charter expired Oct 1 2014 and no re-chartering process is in 
progress. Similar to Wayne Carr's CfC on Intel's SysApps specification, 
https://lists.w3.org/Archives/Public/public-sysapps/2015Mar/0001.html, I am 
issuing an informal CfC on moving the SysApps TCP and UDP Socket API to a 
Community Group. The latest version of the TCP and UDP Socket API is: 
http://www.w3.org/2012/sysapps/tcp-udp-sockets/.

The main reason why moving to a Community Group, instead of a Working Group, is 
proposed is that the original assumption for this API was a secure Web System 
Applications Runtime, standardized by the SysApps WG. As this has not been 
defined the main issue with the TCP and UDP Socket API is security, i.e. it 
does not fit with the Web Security model as it is defined today. However, in 
the current version of the API there is defined an approach to meet this issue, 
see https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0001.html for 
more information.

The purpose of this informal CfC is to determine consensus on the following 
proposition:
The members of the SysApps WG do not object to moving the TCP and UDP Socket 
API to a Community Group where other Community Groups or anyone outside W3C 
would be allowed to
take and develop them (as allowed by the Community Group Contributor License 
Agreement).

Please respond be end of day 24 April 2014.  As usual in a CfC, silence is 
considered agreement with the proposal, but a direct response is preferred.  It 
would be very helpful to express any objection.

Best regards

Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.commailto:firstname.lastn...@sonymobile.com

sonymobile.comhttp://sonymobile.com/

[cid:image003.png@01D0769A.D6CA7CE0]

Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Simon Pieters]

On Sat, 21 Mar 2015 13:52:25 +0100, Arthur Barstow art.bars...@gmail.com  
wrote:


As previously mentioned on [p-w], the test results for Web Messaging  
[All] indicate significant interoperability with only two tests that  
have less than two passes [2]. The two tests, including a short  
analysis of the failure, are:


1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test  
failure (which passes on Firefox) can be considered more of a Web IDL  
implementation issue and thus not a significant interop issue.


2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this  
test failure (which passes on IE) is considered an implementation bug  
(MessageChannel and MessagePort are supposed to be exposed to Worker)  
that is expected to be fixed.


Cindy created a Draft PR [PR] that includes Hixie's updates since the  
[CR] was published (but not the PortCollection interface [PC] which is  
not broadly implemented). Overall, we consider the changes since the CR  
as non-substantive bug fixes and clarifications that align the spec with  
current implementations, and that the test suite tests the updated spec.  
See [Diff] for all of changes between the CR and the draft PR and note  
the draft PR's status section includes a short summary of the changes.


As such, this is a Call for Consensus to publish a Proposed  
Recommendation of Web Messaging using the [PR] as the basis. Agreement  
with this CfC means you consider the test results shows interoperability  
and the changes since CR are not substantive.


If you have any comments or concerns about this CfC, please reply to  
this e-mail by March 28 at the latest. Positive response is preferred  
and encouraged, and silence will be considered as agreement with the  
proposal. If there are no non-resolvable objections to this proposal,  
the motion will carry and we will request the PR be published.


Opera supports publishing.


-Thanks, ArtB

[p-w]  
https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html

[All] http://w3c.github.io/test-results/webmessaging/all.html
[2] http://w3c.github.io/test-results/webmessaging/less-than-2.html
[PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/
[CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/
[PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports
[Diff] https://www.diffchecker.com/qswiibb5







--
Simon Pieters
Opera Software

RE: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Travis Leithead]

Microsoft supports publishing this. Thanks to all involved!

-
Subject:CfC: publish Proposed Recommendation of Web Messaging; 
deadline March 28
Date:   Sat, 21 Mar 2015 08:51:45 -0400
From:   Arthur Barstow art.bars...@gmail.com
To: public-webapps public-webapps@w3.org

As previously mentioned on [p-w], the test results for Web Messaging 
[All] indicate significant interoperability with only two tests that 
have less than two passes [2]. The two tests, including a short 
analysis of the failure, are:

1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test 
failure (which passes on Firefox) can be considered more of a Web IDL 
implementation issue and thus not a significant interop issue.

2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this 
test failure (which passes on IE) is considered an implementation bug 
(MessageChannel and MessagePort are supposed to be exposed to Worker) 
that is expected to be fixed.

Cindy created a Draft PR [PR] that includes Hixie's updates since the 
[CR] was published (but not the PortCollection interface [PC] which is 
not broadly implemented). Overall, we consider the changes since the CR 
as non-substantive bug fixes and clarifications that align the spec with 
current implementations, and that the test suite tests the updated spec. 
See [Diff] for all of changes between the CR and the draft PR and note 
the draft PR's status section includes a short summary of the changes.

As such, this is a Call for Consensus to publish a Proposed 
Recommendation of Web Messaging using the [PR] as the basis. Agreement 
with this CfC means you consider the test results shows interoperability 
and the changes since CR are not substantive.

If you have any comments or concerns about this CfC, please reply to 
this e-mail by March 28 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal. If there are no non-resolvable objections to this proposal, 
the motion will carry and we will request the PR be published.

-Thanks, ArtB

[p-w] 
https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html
[All] http://w3c.github.io/test-results/webmessaging/all.html
[2] http://w3c.github.io/test-results/webmessaging/less-than-2.html
[PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/
[CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/
[PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports
[Diff] https://www.diffchecker.com/qswiibb5

Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Xiaoqian Wu]

on 25/03/2015 03:52, Sigbjorn Finne wrote:

Hi,

if it helps, Blink now passes those two failing tests; Chrome 
canary/nightly builds have the fixes included.


(Fixes for 
http://www.w3c-test.org/webmessaging/without-ports/{008,009}.html 
should appear overnight also.)


hth
--sigbjorn 


Thank you for the great news, Sigbjorn!

The Canary (Ch43) data was into the ImplReport[1] so right now we have 
at least 2 implementations that pass each test file. According to a 
recent discussion about MessagePort/MessageChannel[2], Firefox will 
serve as another implementation for these APIs soon.


Special thanks to Simon Pieters and Zhiqiang Zhang for their useful 
comments while this test suite was being updated.


[1] http://w3c.github.io/test-results/webmessaging/all
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=952139

--
xiaoqian

Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Arthur Barstow]

On 3/24/15 3:52 PM, Sigbjorn Finne wrote:

Den 3/24/2015 20:37, Arthur Barstow skreiv:

On 3/21/15 1:27 PM, Jonas Sicking wrote:

On Sat, Mar 21, 2015 at 5:52 AM, Arthur
Barstowart.bars...@gmail.com  wrote:

2.http://www.w3c-test.org/webmessaging/without-ports/025.html; this
test
failure (which passes on IE) is considered an implementation bug
(MessageChannel and MessagePort are supposed to be exposed to Worker)
that
is expected to be fixed.

I'm not sure that we can really consider lack of support in Workers a
bug. Worker support is generally non-trivial since it requires making
an API work off the main thread.

That said, mozilla has patches for worker support in progress right
now, so hopefully Firefox can serve as second implementation here
soon.


Thanks for this info Jonas.

My characterization of this failure wasn't especially good. I think the
main point with respect to discussing this failure with the Director (or
someone acting on his behalf) is that the lack of a second
implementation is not caused by a bug/issue in the spec itself, and that
at least one other browser vendor already has a relevant patches in
progress.

Given the large majority of the tests (84/86) have two or more passes
and the patch you mention above, it seems reasonable to request moving
this spec to PR now. Is that OK with you or should we consider your
position a formal objection?



Hi,

if it helps, Blink now passes those two failing tests; Chrome 
canary/nightly builds have the fixes included.


(Fixes for 
http://www.w3c-test.org/webmessaging/without-ports/{008,009}.html 
should appear overnight also.)


hth


Yes, that is indeed helpful. Thanks Sigbjorn!

-ArtB

Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Sigbjorn Finne]

Den 3/24/2015 20:37, Arthur Barstow skreiv:

On 3/21/15 1:27 PM, Jonas Sicking wrote:

On Sat, Mar 21, 2015 at 5:52 AM, Arthur
Barstowart.bars...@gmail.com  wrote:

2.http://www.w3c-test.org/webmessaging/without-ports/025.html; this
test
failure (which passes on IE) is considered an implementation bug
(MessageChannel and MessagePort are supposed to be exposed to Worker)
that
is expected to be fixed.

I'm not sure that we can really consider lack of support in Workers a
bug. Worker support is generally non-trivial since it requires making
an API work off the main thread.

That said, mozilla has patches for worker support in progress right
now, so hopefully Firefox can serve as second implementation here
soon.


Thanks for this info Jonas.

My characterization of this failure wasn't especially good. I think the
main point with respect to discussing this failure with the Director (or
someone acting on his behalf) is that the lack of a second
implementation is not caused by a bug/issue in the spec itself, and that
at least one other browser vendor already has a relevant patches in
progress.

Given the large majority of the tests (84/86) have two or more passes
and the patch you mention above, it seems reasonable to request moving
this spec to PR now. Is that OK with you or should we consider your
position a formal objection?



Hi,

if it helps, Blink now passes those two failing tests; Chrome 
canary/nightly builds have the fixes included.


(Fixes for 
http://www.w3c-test.org/webmessaging/without-ports/{008,009}.html should 
appear overnight also.)


hth
--sigbjorn

Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Jonas Sicking]

On Sat, Mar 21, 2015 at 5:52 AM, Arthur Barstow art.bars...@gmail.com wrote:

 2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this test
 failure (which passes on IE) is considered an implementation bug
 (MessageChannel and MessagePort are supposed to be exposed to Worker) that
 is expected to be fixed.

I'm not sure that we can really consider lack of support in Workers a
bug. Worker support is generally non-trivial since it requires making
an API work off the main thread.

That said, mozilla has patches for worker support in progress right
now, so hopefully Firefox can serve as second implementation here
soon.

/ Jonas

CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Arthur Barstow]

As previously mentioned on [p-w], the test results for Web Messaging 
[All] indicate significant interoperability with only two tests that 
have less than two passes [2]. The two tests, including a short 
analysis of the failure, are:


1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test 
failure (which passes on Firefox) can be considered more of a Web IDL 
implementation issue and thus not a significant interop issue.


2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this 
test failure (which passes on IE) is considered an implementation bug 
(MessageChannel and MessagePort are supposed to be exposed to Worker) 
that is expected to be fixed.


Cindy created a Draft PR [PR] that includes Hixie's updates since the 
[CR] was published (but not the PortCollection interface [PC] which is 
not broadly implemented). Overall, we consider the changes since the CR 
as non-substantive bug fixes and clarifications that align the spec with 
current implementations, and that the test suite tests the updated spec. 
See [Diff] for all of changes between the CR and the draft PR and note 
the draft PR's status section includes a short summary of the changes.


As such, this is a Call for Consensus to publish a Proposed 
Recommendation of Web Messaging using the [PR] as the basis. Agreement 
with this CfC means you consider the test results shows interoperability 
and the changes since CR are not substantive.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by March 28 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal. If there are no non-resolvable objections to this proposal, 
the motion will carry and we will request the PR be published.


-Thanks, ArtB

[p-w] 
https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html

[All] http://w3c.github.io/test-results/webmessaging/all.html
[2] http://w3c.github.io/test-results/webmessaging/less-than-2.html
[PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/
[CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/
[PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports
[Diff] https://www.diffchecker.com/qswiibb5

Re: CfC: publish WG Note of UI Events; deadline November 14

[Arthur Barstow]

Hi All,

This CfC (original thread is [1]) is now moving forward and on March 17 
there will be two publications:


1. /UI Events (Keyboard Extension)/; W3C Working Group Note; (draft is 
http://jay.w3.org/~plehegar/uievents-ext.html).


2. /UI Events Specification (formerly DOM Level 3 Events)/; W3C Working 
Draft; (draft is http://jay.w3.org/~plehegar/uievents.html).


The following redirects will also be made:

1. http://www.w3.org/TR/DOM-Level-3-Events/ will redirect to 
http://www.w3.org/TR/uievents/.


2. http://www.w3.org/TR/uievents/ will redirect to 
http://www.w3.org/TR/2015/WD-uievents-20150317/.


-Regards, ArtB

[1] https://lists.w3.org/Archives/Public/www-dom/2014OctDec/0039.html


On 11/7/14 10:28 AM, Arthur Barstow wrote:
During WebApps' October 27 meeting, the participants agreed to stop 
work on the UI Events spec and to publish it as a WG Note (see 
[Mins]). As such, this is a formal Call for Consensus (CfC) to:


a) Stop work on this spec

b) Publish a gutted WG Note of the spec; see [Draft-Note]

c) Gut the ED (this will be done if/when this CfC passes)

d) Prefix the spec's [Bugs] with HISTORICAL and turn off creating 
new bugs


e) Travis will move all bugs that are relevant to D3E to the D3E bug 
component


Note Action-734 resulted in a discussion about the rationale for this 
proposal ([Discuss]).


If anyone has comments or concerns about this CfC, please reply by 
November 14 at the latest. Positive response is preferred and 
encouraged and silence will be considered as agreement with the 
proposal. In the absence of any non-resolvable issues, I will see make 
sure the Note is published.


-Thanks, AB

[Mins] http://www.w3.org/2014/10/27-webapps-minutes.html#item05
[Draft-Note] https://dvcs.w3.org/hg/d4e/raw-file/default/tr.html
[Bugs] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=UI%20Eventsresolution=---
[Discuss] 
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0262.html

CfC: publish Wide Review Draft of Manifest for web application; deadline Feb 5

[Arthur Barstow]

Marcos is working toward a Candidate Recommendation of Manifest for web 
application and before that step, we need to publish a Working Draft 
for Wide Review [WR] (a WR Draft is equivalent to a Last Call draft 
as defined in the consortium's 2005 Process). As such, this is a Call 
for Consensus to publish a new WR draft of this spec using the 2014 
Process [PD-2014] and the proposed review period is three weeks.


The latest Editor's Draft of the spec is: http://w3c.github.io/manifest/.

If you have any comments or concerns about this CfC, please reply by 
February 5 at the latest. Silence will be considered as agreeing with 
the proposal and explicit responses are preferred. If no non-resolvable 
blocking issues are raised, this CfC will be considered as passing and 
we will proceed with the publication.


Assuming this CfC passes, Marcos suggested the following groups be 
explicitly asked to review this spec: CSS WG - in particular, the 
display mode media feature, and WebAppSec WG. Please let us know if 
there are other groups we should ask to review the spec.


-Thanks, ArtB

[WR] http://www.w3.org/2014/Process-20140801/#wide-review
[PD-2014] http://www.w3.org/2014/Process-20140801/#rec-advance

Re: CfC: publish FPWD of Packaging on the Web; deadline November 3

[Arthur Barstow]

On 10/27/14 12:34 AM, Arthur Barstow wrote:
Jeni and the TAG would like to publish - on behalf of both the TAG and 
WebApps - a First Public Working Draft (FPWD) of the Packaging on the 
Web specification and this is a Call for Consensus (CfC) to do so 
using the following ED as the basis:


http://w3ctag.github.io/packaging-on-the-web/


FYI, this FPWD was published today 
http://www.w3.org/TR/2015/WD-web-packaging-20150115/.


Sorry for the delay.

-AB

Re: CfC: publish WG Note of UI Events; deadline November 14

[Arthur Barstow]

On 11/21/14 8:43 AM, Philippe Le Hegaret wrote:

On Wed, 2014-11-19 at 09:44 -0500, Arthur Barstow wrote:

On 11/19/14 9:35 AM, Anne van Kesteren wrote:

On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com wrote:

Although there appears to be agreement that work on the [uievents] spec
should stop, the various replies raise sufficient questions that I consider
this CfC (as written) as failed.

Travis, Gary - would you please make a specific proposal for these two
specs? In particular, what is the title and shortname for each document, and
which spec/shortname becomes the WG Note?

After we have agreed on a way forward, I'll start a new CfC.

(I believe the Principle of Least Surprise here means considering specs that
currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose a
document titled UI Events with a shortname of DOM-Level-3-Events could be
a bit confusing to some, although strictly speaking could be done.)

My proposal would be to update UI Events with the latest editor's
draft of DOM Level 3 Events (title renamed, of course) and have the
DOM Level 3 Events URL redirect to UI Events. That would communicate
clearly what happened.

Yves, Philippe - can Anne's proposal be done?

I'm not aware of any reason that would prevent us from doing so.


Hi Travis, Gary, Philippe,

Since Anne's proposal hasn't been implemented, what exactly is the plan 
for these two specs?


There is also a related proposal DOM L3 Events Input Events Work to the 
Editing Task Force by Ben [Ben] and followup by Gary [Gary].


What do you recommend here, i.e., Who is going to do What and When?

-Thanks, ArtB

[Ben] 
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0575.html
[Gary] 
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0576.html

Re: CfC: publish WG Note of UI Events; deadline November 14

[Philippe Le Hegaret]

On Wed, 2014-12-10 at 10:22 -0500, Arthur Barstow wrote:
 Hi Travis, Gary, Philippe,
 
 Since Anne's proposal hasn't been implemented, what exactly is the plan 
 for these two specs?
 
 There is also a related proposal DOM L3 Events Input Events Work to the 
 Editing Task Force by Ben [Ben] and followup by Gary [Gary].
 
 What do you recommend here, i.e., Who is going to do What and When?

I sent a few questions to the editors on this front but didn't receive
responses. I'd like some guidances here before publishing.

Philippe

RE: CfC: Move URL spec to 2014 Process (and publish)

[David Walp]

Microsoft supports the proposal.

cheers
-Original Message-
From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru] 
Sent: Tuesday, December 2, 2014 4:45 PM
To: Webapps WG
Subject: Re: CfC: Move URL spec to 2014 Process (and publish)

03.12.2014, 02:41, cha...@yandex-team.ru cha...@yandex-team.ru:
 Hello all,

 this is a call for consensus on the proposal

 Webapps will publish future drafts of the URL specification under the 
 2014 Process Document http://www.w3.org/2014/Process-20140801/

 Silence will be taken as assent but positive response to this email is 
 preferred, and will be accepted before midnight Hawaii time on Wednesday 
 December 10.

Yandex supports the proposal.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex 
cha...@yandex-team.ru - - - Find more at http://yandex.com

CfC: Move URL spec to 2014 Process (and publish)

[chaals]

Hello all,

this is a call for consensus on the proposal

Webapps will publish future drafts of the URL specification under the 2014 
Process Document http://www.w3.org/2014/Process-20140801/

Silence will be taken as assent but positive response to this email is 
preferred, and will be accepted before midnight Hawaii time on Wednesday 
December 10.

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CfC: Move URL spec to 2014 Process (and publish)

[chaals]

03.12.2014, 02:41, cha...@yandex-team.ru cha...@yandex-team.ru:
 Hello all,

 this is a call for consensus on the proposal

 Webapps will publish future drafts of the URL specification under the 2014 
 Process Document http://www.w3.org/2014/Process-20140801/

 Silence will be taken as assent but positive response to this email is 
 preferred, and will be accepted before midnight Hawaii time on Wednesday 
 December 10.

Yandex supports the proposal.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CfC: publish WG Note of UI Events; deadline November 14

[Philippe Le Hegaret]

On Wed, 2014-11-19 at 09:44 -0500, Arthur Barstow wrote:
 On 11/19/14 9:35 AM, Anne van Kesteren wrote:
  On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com 
  wrote:
  Although there appears to be agreement that work on the [uievents] spec
  should stop, the various replies raise sufficient questions that I consider
  this CfC (as written) as failed.
 
  Travis, Gary - would you please make a specific proposal for these two
  specs? In particular, what is the title and shortname for each document, 
  and
  which spec/shortname becomes the WG Note?
 
  After we have agreed on a way forward, I'll start a new CfC.
 
  (I believe the Principle of Least Surprise here means considering specs 
  that
  currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose a
  document titled UI Events with a shortname of DOM-Level-3-Events could be
  a bit confusing to some, although strictly speaking could be done.)
  My proposal would be to update UI Events with the latest editor's
  draft of DOM Level 3 Events (title renamed, of course) and have the
  DOM Level 3 Events URL redirect to UI Events. That would communicate
  clearly what happened.
 
 Yves, Philippe - can Anne's proposal be done?

I'm not aware of any reason that would prevent us from doing so.

Philippe

CfC: publish Proposed Recommendation of Server-Sent Events; deadline November 28

[Arthur Barstow]

The latest interop data Zhiqiang generated for Server-sent Events [All] 
indicates 102/124 passes and [2] isolates the 22 failures with less 
than two implementations including 9 failures which are due to Web IDL 
implementation bugs (thus, not counting the WebIDL failures the pass 
rate is 111/124 or ~90%).


The non Web IDL failures are:

1. 
http://www.w3c-test.org/eventsource/dedicated-worker/eventsource-constructor-non-same-origin.htm 

2. 
http://www.w3c-test.org/eventsource/shared-worker/eventsource-constructor-non-same-origin.htm

3. http://www.w3c-test.org/eventsource/format-field-retry-bogus.htm

My take on these failures is:

#1 and #2 test the UA's error handling of URLs that cannot be resolved 
(f.ex. unsupported URL scheme, URL doesn't exist). The failures appear 
to be relatively low priority implementation bugs (see [Bug119974]) that 
seem unlikely to occur in a tested deployment.


#3 tests the UA's handling of invalid data value for the retry 
(constructor) parameter. This test actually now passes when I run it on 
FF beta 34.0 so it should be removed from [2]. Regardless, the failure 
appears to be a relatively low priority implementation bug that seems 
unlikely to occur in a tested deployment.


As such, this is Call for Consensus to publish SSE as a Proposed 
Recommendation. If you have any comments or concerns about this CfC, 
please reply to this e-mail by November 28 at the latest. Positive 
response is preferred and encouraged, and silence will be considered as 
agreement with the proposal.


The [ED] has changed since the [CR] was published (see [Diff]) so this 
proposal assumes that if/when there is a resource commitment to include 
changes on the TR track, that will be done separately.


-Thanks, AB

[All] http://w3c.github.io/test-results/eventsource/less-than-2.html
[2] http://w3c.github.io/test-results/eventsource/less-than-2.html
[Bug119974] https://bugs.webkit.org/show_bug.cgi?id=119974

[CR] http://www.w3.org/TR/2012/CR-eventsource-20121211/
[ED] http://dev.w3.org/html5/eventsource/
[Diff] 
http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%2Feventsource%2FOverview.html%3Frev%3D1.233%3Bcontent-type%3Dtext%252Fhtmldoc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%2Feventsource%2FOverview.html%3Frev%3D1.258%3Bcontent-type%3Dtext%252Fhtml 

Re: CfC: publish Proposed Recommendation of Server-Sent Events; deadline November 28

[Glenn Adams]

+1

On Fri, Nov 21, 2014 at 7:02 AM, Arthur Barstow art.bars...@gmail.com
wrote:

 The latest interop data Zhiqiang generated for Server-sent Events [All]
 indicates 102/124 passes and [2] isolates the 22 failures with less than
 two implementations including 9 failures which are due to Web IDL
 implementation bugs (thus, not counting the WebIDL failures the pass rate
 is 111/124 or ~90%).

 The non Web IDL failures are:

 1. http://www.w3c-test.org/eventsource/dedicated-worker/
 eventsource-constructor-non-same-origin.htm
 2. http://www.w3c-test.org/eventsource/shared-worker/
 eventsource-constructor-non-same-origin.htm
 3. http://www.w3c-test.org/eventsource/format-field-retry-bogus.htm

 My take on these failures is:

 #1 and #2 test the UA's error handling of URLs that cannot be resolved
 (f.ex. unsupported URL scheme, URL doesn't exist). The failures appear to
 be relatively low priority implementation bugs (see [Bug119974]) that seem
 unlikely to occur in a tested deployment.

 #3 tests the UA's handling of invalid data value for the retry
 (constructor) parameter. This test actually now passes when I run it on FF
 beta 34.0 so it should be removed from [2]. Regardless, the failure
 appears to be a relatively low priority implementation bug that seems
 unlikely to occur in a tested deployment.

 As such, this is Call for Consensus to publish SSE as a Proposed
 Recommendation. If you have any comments or concerns about this CfC, please
 reply to this e-mail by November 28 at the latest. Positive response is
 preferred and encouraged, and silence will be considered as agreement with
 the proposal.

 The [ED] has changed since the [CR] was published (see [Diff]) so this
 proposal assumes that if/when there is a resource commitment to include
 changes on the TR track, that will be done separately.

 -Thanks, AB

 [All] http://w3c.github.io/test-results/eventsource/less-than-2.html
 [2] http://w3c.github.io/test-results/eventsource/less-than-2.html
 [Bug119974] https://bugs.webkit.org/show_bug.cgi?id=119974

 [CR] http://www.w3.org/TR/2012/CR-eventsource-20121211/
 [ED] http://dev.w3.org/html5/eventsource/
 [Diff] http://services.w3.org/htmldiff?doc1=http%3A%2F%
 2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%2Feventsource%2FOverview.html%
 3Frev%3D1.233%3Bcontent-type%3Dtext%252Fhtmldoc2=http%3A%
 2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%
 2Feventsource%2FOverview.html%3Frev%3D1.258%3Bcontent-type%3Dtext%252Fhtml

Re: CfC: publish WG Note of UI Events; deadline November 14

[Arthur Barstow]

On 11/7/14 10:28 AM, Arthur Barstow wrote:
During WebApps' October 27 meeting, the participants agreed to stop 
work on the UI Events spec and to publish it as a WG Note (see 
[Mins]). As such, this is a formal Call for Consensus (CfC) to:


a) Stop work on this spec

b) Publish a gutted WG Note of the spec; see [Draft-Note]

c) Gut the ED (this will be done if/when this CfC passes)

d) Prefix the spec's [Bugs] with HISTORICAL and turn off creating 
new bugs


e) Travis will move all bugs that are relevant to D3E to the D3E bug 
component



Although there appears to be agreement that work on the [uievents] spec 
should stop, the various replies raise sufficient questions that I 
consider this CfC (as written) as failed.


Travis, Gary - would you please make a specific proposal for these two 
specs? In particular, what is the title and shortname for each document, 
and which spec/shortname becomes the WG Note?


After we have agreed on a way forward, I'll start a new CfC.

(I believe the Principle of Least Surprise here means considering specs 
that currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I 
suppose a document titled UI Events with a shortname of 
DOM-Level-3-Events could be a bit confusing to some, although strictly 
speaking could be done.)


-Thanks, AB

[uievents] http://www.w3.org/TR/uievents/
[DOM-Level-3-Events] http://www.w3.org/TR/DOM-Level-3-Events/



[Mins] http://www.w3.org/2014/10/27-webapps-minutes.html#item05
[Draft-Note] https://dvcs.w3.org/hg/d4e/raw-file/default/tr.html
[Bugs] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=UI%20Eventsresolution=---
[Discuss] 
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0262.html

Re: CfC: publish WG Note of UI Events; deadline November 14

[Anne van Kesteren]

On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com wrote:
 Although there appears to be agreement that work on the [uievents] spec
 should stop, the various replies raise sufficient questions that I consider
 this CfC (as written) as failed.

 Travis, Gary - would you please make a specific proposal for these two
 specs? In particular, what is the title and shortname for each document, and
 which spec/shortname becomes the WG Note?

 After we have agreed on a way forward, I'll start a new CfC.

 (I believe the Principle of Least Surprise here means considering specs that
 currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose a
 document titled UI Events with a shortname of DOM-Level-3-Events could be
 a bit confusing to some, although strictly speaking could be done.)

My proposal would be to update UI Events with the latest editor's
draft of DOM Level 3 Events (title renamed, of course) and have the
DOM Level 3 Events URL redirect to UI Events. That would communicate
clearly what happened.


-- 
https://annevankesteren.nl/

Re: CfC: publish WG Note of UI Events; deadline November 14

[Arthur Barstow]

On 11/19/14 9:35 AM, Anne van Kesteren wrote:

On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com wrote:

Although there appears to be agreement that work on the [uievents] spec
should stop, the various replies raise sufficient questions that I consider
this CfC (as written) as failed.

Travis, Gary - would you please make a specific proposal for these two
specs? In particular, what is the title and shortname for each document, and
which spec/shortname becomes the WG Note?

After we have agreed on a way forward, I'll start a new CfC.

(I believe the Principle of Least Surprise here means considering specs that
currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose a
document titled UI Events with a shortname of DOM-Level-3-Events could be
a bit confusing to some, although strictly speaking could be done.)

My proposal would be to update UI Events with the latest editor's
draft of DOM Level 3 Events (title renamed, of course) and have the
DOM Level 3 Events URL redirect to UI Events. That would communicate
clearly what happened.


Yves, Philippe - can Anne's proposal be done?

Re: CfC: publish WG Note of UI Events; deadline November 14

[Pradeep Kumar]

+1
On 19-Nov-2014 8:07 pm, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com
 wrote:
  Although there appears to be agreement that work on the [uievents] spec
  should stop, the various replies raise sufficient questions that I
 consider
  this CfC (as written) as failed.
 
  Travis, Gary - would you please make a specific proposal for these two
  specs? In particular, what is the title and shortname for each document,
 and
  which spec/shortname becomes the WG Note?
 
  After we have agreed on a way forward, I'll start a new CfC.
 
  (I believe the Principle of Least Surprise here means considering specs
 that
  currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose
 a
  document titled UI Events with a shortname of DOM-Level-3-Events could
 be
  a bit confusing to some, although strictly speaking could be done.)

 My proposal would be to update UI Events with the latest editor's
 draft of DOM Level 3 Events (title renamed, of course) and have the
 DOM Level 3 Events URL redirect to UI Events. That would communicate
 clearly what happened.


 --
 https://annevankesteren.nl/

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

[Arthur Barstow]

On 11/7/14 11:46 AM, Arthur Barstow wrote:

this is a Call for Consensus to:

a) Publish a gutted WG Note of the spec (see [Draft-Note])


FYI, this WG Note has been published 
http://www.w3.org/TR/2014/NOTE-XMLHttpRequest2-20141118/.

Re: CfC: publish a WG Note of Fullscreen; deadline November 14

[Arthur Barstow]

On 11/7/14 8:39 AM, Arthur Barstow wrote:

this is a formal Call for Consensus to:

a) Stop work on the spec (and remove it as a deliverable if/when 
WebApps' charter is updated)


b) Publish a WG Note of this spec; (see [Draft-Note] for the proposed 
document)


c) gut the WG Note of all technical content (as WebApps did recently 
with [e.g.])


d) gut the ED [ED] of all technical content (note: this hasn't been 
done yet but I will do so if/when this CfC passes)


FYI, the WG Note was published 
http://www.w3.org/TR/2014/NOTE-fullscreen-20141118/.

Re: CfC: publish Proposed Recommendation of Indexed Database; deadline November 9

[Arthur Barstow]

On 11/2/14 2:27 PM, Arthur Barstow wrote:
During WebApps' October 27 meeting [Mins], the group reviewed the 
Indexed Database  testing data [Data] and agreed the specification 
should be published as a Proposed Recommendation (see [CR]). As such, 
this is Call for Consensus to publish a Proposed Recommendation of 
Indexed Database.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by November 9 at the latest. Positive response is 
preferred and encouraged, and silence will be considered as agreement 
with the proposal.


We now have a DRAFT Proposed Recommendation:

  [Draft-PR] 
https://dvcs.w3.org/hg/IndexedDB/raw-file/default/Overview-PR-Nov-2014.html


It is based on the latest ED and includes Jonas' fix for Bug [25251]. It 
does not include the three Block Issues that are in the CR (my 
understanding is Joshua intends to remove those issue blocks from the ED).


[Diff] is a diff between [CR] and [Draft-PR].

-Thanks, AB

[25251] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25251
[Diff] 
http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-IndexedDB-20130704%2Fdoc2=https%3A%2F%2Fdvcs.w3.org%2Fhg%2FIndexedDB%2Fraw-file%2Fdefault%2FOverview-PR-Nov-2014.html



[Mins] http://www.w3.org/2014/10/27-webapps-minutes.html#item12
[Data] 
http://lists.w3.org/Archives/Public/public-test-infra/2014OctDec/0008.html

[CR] http://www.w3.org/TR/2013/CR-IndexedDB-20130704/

Re: CfC: publish a WG Note of Fullscreen; deadline November 14

[Arthur Barstow]

On 11/8/14 2:07 PM, cha...@yandex-team.ru wrote:

08.11.2014, 14:43, Domenic Denicola d...@domenic.me:

From: Arthur Barstow [mailto:art.bars...@gmail.com]

  OK, so I just checked in a patch that sets the Latest Editor's Draft points 
to Anne's document
  https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html.

I think it would be ideal to change the label to e.g. See Instead or Maintained 
Version or Replaced By. Framing the WHATWG as a source of Editor's Drafts for the W3C is 
unnecessarily combative.

Agree that it's the wrong framing, and the point is that the current W3C work 
is recognised as being supereseded...


I just updated the Draft WG Note to use See Instead 
https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html.


-Thanks, AB

Re: CfC: publish WG Note of UI Events; deadline November 14

[Кошмарчик]

On Fri, Nov 7, 2014 at 7:36 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Nov 7, 2014 at 4:28 PM, Arthur Barstow art.bars...@gmail.com
 wrote:
  If anyone has comments or concerns about this CfC, please reply by
 November
  14 at the latest.

 My concern is that we previously agreed that UI Events would be a much
 more suitable name for the contents of DOM Level 3 Events.


I agree. UI Events is a much more descriptive name for the content.

My primary concern is that we (specifically, I) have been telling people
that UI Events is not the same as D3E. If we change this, then I'll have to
have those conversations all over again, but reversed. ^_^

But we
 would keep using DOM Level 3 Events because it would be done quickly
 and then we'd move on to UI Events. As we now know we did not finish
 DOM Level 3 Events quickly.


FWIW, we pushed to have it done quickly and it was delayed:
(1) once because the spec was a step backward from DOM2 in some regards and
that needed to be fixed,
(2) again because there was feedback that style and presentation should be
updated to match more recent specs.

#2 is when the WG effectively decided that cleaning up the presentation was
more important than releasing it quickly.

So I would like us to abandon that name
 and settle on UI Events.


SGTM.

With regards to the current contents of UI Events, I assume that publishing
a gutted WD Note is meant simply to establish a historical record of what
was worked on before the content is deleted?  When we were focusing on
completing the D3E spec quickly, this is where we sent items that we felt
should be part of D3E, but would take too much time to finalize. We'll want
to reconsider some of these items for inclusion back in D3E (er... I mean
UI Events).

-Gary

Re: CfC: publish a WG Note of Fullscreen; deadline November 14

[Tab Atkins Jr.]

On Sat, Nov 8, 2014 at 5:43 AM, Domenic Denicola d...@domenic.me wrote:
 From: Arthur Barstow [mailto:art.bars...@gmail.com]
 OK, so I just checked in a patch that sets the Latest Editor's Draft points 
 to Anne's document
 https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html.

 I think it would be ideal to change the label to e.g. See Instead or 
 Maintained Version or Replaced By. Framing the WHATWG as a source of 
 Editor's Drafts for the W3C is unnecessarily combative.

I use a replaced by wording on specs I've moved elsewhere; see
https://tabatkins.github.io/specs/css-color/ for an example.

~TJ

Re: CfC: publish WG Note of UI Events; deadline November 14

[Arthur Barstow]

On 11/7/14 10:36 AM, Anne van Kesteren wrote:

On Fri, Nov 7, 2014 at 4:28 PM, Arthur Barstow art.bars...@gmail.com wrote:

If anyone has comments or concerns about this CfC, please reply by November
14 at the latest.

My concern is that we previously agreed that UI Events would be a much
more suitable name for the contents of DOM Level 3 Events.


Please provide a link to that agreement.


But we would keep using DOM Level 3 Events because it would be done quickly
and then we'd move on to UI Events. As we now know we did not finish
DOM Level 3 Events quickly. So I would like us to abandon that name
and settle on UI Events.


Travis, Gary - what are your thoughts on Anne's proposal?

-Thanks, AB

RE: CfC: publish a WG Note of Fullscreen; deadline November 14

[Domenic Denicola]

From: Arthur Barstow [mailto:art.bars...@gmail.com] 

 OK, so I just checked in a patch that sets the Latest Editor's Draft points 
 to Anne's document 
 https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html.

I think it would be ideal to change the label to e.g. See Instead or 
Maintained Version or Replaced By. Framing the WHATWG as a source of 
Editor's Drafts for the W3C is unnecessarily combative.

RE: CfC: publish WG Note of XHR Level 2; deadline November 14

[Domenic Denicola]

From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru] 

 That doesn't work with the way W3C manages its work and paper trails.

I guess I was just inspired by Mike Smith earlier saying something along the 
lines of don't let past practice constrain your thinking as to what can be 
done in this case, and was hopeful we could come to the even-more-optimal 
solution.

In any case, maybe we could also add meta name=robots contents=noindex to 
this and previous drafts?

Re: CfC: publish a WG Note of Fullscreen; deadline November 14

[chaals]

08.11.2014, 14:43, Domenic Denicola d...@domenic.me:
 From: Arthur Barstow [mailto:art.bars...@gmail.com]
  OK, so I just checked in a patch that sets the Latest Editor's Draft points 
 to Anne's document
  https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html.

 I think it would be ideal to change the label to e.g. See Instead or 
 Maintained Version or Replaced By. Framing the WHATWG as a source of 
 Editor's Drafts for the W3C is unnecessarily combative.

Agree that it's the wrong framing, and the point is that the current W3C work 
is recognised as being supereseded...

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

[chaals]

08.11.2014, 14:46, Domenic Denicola d...@domenic.me:
 From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru]
  That doesn't work with the way W3C manages its work and paper trails.

 I guess I was just inspired by Mike Smith earlier saying something along the 
 lines of don't let past practice constrain your thinking as to what can be 
 done in this case, and was hopeful we could come to the even-more-optimal 
 solution.

 In any case, maybe we could also add meta name=robots contents=noindex 
 to this and previous drafts?

I'd object to doing that. While some search engines sometimes provide odd 
results for queries that match a series of drafts (I know, we're guilty of that 
too), overall I think it is helpful to be able to find oddities that were in a 
draft for a while. In particular it supports people doing a little bit of 
investigation on their own, rather than making it necessary to find someone who 
was around at the time and can give a clear and comprehensive explanation of 
how and why a decision was made.

Something that *would* make sense to me is to start adding schema.org metadata 
for documents. And checking that we can e.g. explain that some document is 
superseded by another one.

I'll go put my schema.org hat on and chase that down...

cheesr

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com