Chaals McCathie Nevile | 12 Jul 12:59 2016

Review request: Wake Lock API

Hello all,

The Device & Sensors Working Group has asked us to review the Wake Lock
API, on it way to Candidate Recommendation status:

Their specific question is whether the API "fits" with the rest of the Web
Platform. Please provide feedback before the end of August, preferably as
issues in the github repository:

Alternatively, comments can be made by email to the public mailing list
public-device-apis@... with a subject prefixed with [wake-lock]

Unless somebody specifically asks for feedback to be endorsed by this  
group, comments should be made in a personal capacity.




Charles McCathie Nevile - web standards - CTO Office, Yandex
    chaals@... - - - Find more at

Léonie Watson | 12 Jul 12:48 2016

Service Workers meeting info

Hello WP,

Information for the meeting on 28/29 July is here: 

If you plan to attend, it would be helpful if you could create a PR to 
add yourself to the attendees list (or let me know and I'll add you).


It looks like the meeting info is complete on this page, except for --
 <at> LeonieWatson Carpe diem

Travis Leithead | 8 Jul 22:14 2016

Quick update on WebIDL "Level 1"

While editing work continues on the “second edition” of WebIDL here:, we have been fine-tuning the “Level 1” CR snapshot [1] to replace and supersede the 2012 version [2].


The “Level 1” editors are making final tweaks to the draft and tests, and hope to be ready to transition to Proposed Recommendation status by the end of July.


The purpose of the “Level 1” document is to serve as a stable reference for W3C specs that link to WebIDL. It contains a subset of the WebIDL syntax that is considered stable (as verified by interoperable tests). Implementations should not use the Level 1 document as a guide, but instead track changes to the editors draft. We expect to follow-up Level 1 with a Level 2 as additional editor’s draft syntax and behavior stabilizes, are implemented as part of other specs, and shown to be interoperable.


-Travis & Yves





Grisha Lyukshin | 7 Jul 03:09 2016

Re: Thank you Hallvord (looking for Clipboard API editor…)

<!-- p {margin-top:0; margin-bottom:0} -->

Hi Chaals,

I am interested.

I will little 'r' you for details.

Thank you.


Sent from Outlook

From: Chaals McCathie Nevile <>
Sent: Wednesday, July 06, 2016 3:24:12 PM
To: public-webapps WG
Subject: Thank you Hallvord (looking for Clipboard API editor…)
Dear all,

part of this mail is to thank Hallvord Steen for his efforts in this group 
over a number of years. As a result of changed employment he is stepping 
down as a member and in particular as editor of the Clipboard APIs 
specification, which is just one part of the contribution he has made that 
will be missed.

The other purpose of the mail is to note that we are therefore looking for 
a new editor for Clipboard APIs. If anyone wants to do this, please let me 
know and I will happily work with you if there is anything about editing a 
W3C specification that you are not sure about.

Thank you Hallvord, all the best, and I hope we see you back in the 
Working Group at some stage.



Charles McCathie Nevile - web standards - CTO Office, Yandex - - - Find more at

Chaals McCathie Nevile | 5 Jul 16:15 2016

Call for Consensus: Publish HTML 5.2 FPWD?

This is a call for consensus on the proposition:

Publish the current editors' draft of HTML 5.2 - - as a First Public Working Draft.

Silence will be considered assent, but positive responses are preferred.  
In an effort to find a smoother way to assess consensus, there are three  
possible mechanisms for feedback, and you should pick the one you find  
most convenient:

You can provide a response in this email thread.

You can provide a comment or thumbs-up in the issue in the HTML repo -

You can provide a comment or thumbs-up in the issue in the WebPlatformWG  
repo -

There is no need to use more than one of these mechanisms, as the chairs  
will collate the results.

If many people use the issues instead of email, we will likely propose a  
change to the work mode for assessing consensus.

There will be a separate thread on the merits of any procedural change -  
please *only* reply to this thread to support or oppose the FPWD  


Chaals, for the chairs


Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@... - - - Find more at

Léonie Watson | 25 Jun 20:12 2016

Re: CFC: Republish Pointer Lock as CR

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.



 <at> LeonieWatson Carpe diem

Kirill Topolyan | 18 Jun 19:57 2016

[selectors-api] typo in specification


At the moment I'm translating "Selectors API Level 1" [1] and it seems I have noticed a typo in the original document.


Section 6.4:
"If result is invalid ([SELECT], section 12), raisea a SYNTAX_ERR exception ([DOM-LEVEL-3-CORE],
section 1.4) and abort this algorithm."

Probably it meant "raise a SYNTAX_ERR" instead "raisea a SYNTAX_ERR"?

Best regards,

Léonie Watson | 13 Jun 18:12 2016

CFC: Republish Pointer Lock as CR

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.

 <at> LeonieWatson Carpe diem


[clipboard][DnD][DataTransfer] custom types and security

Hi public-webapps, or the sub-set of your that are interested in
clipboard and DnD stuff: we've started an interesting thread regarding
DataTransfer, custom types and security here

and implementor input is especially welcome. Allow me to paste parts
of my last comment, explaining a tricky issue I'd like a wider review

Regarding the custom types: obviously, if we want to enable
interoperability between the same web apps running in different
browser engines, we need to spec a shared clipboard format for custom
data. This implies that other native software will also see a "Web
browser custom data" clipboard entry (by any description after some
bikeshedding) and potentially grow features that start making use of
said "Web browser custom data" on paste/drop.

If this is considered an extremely rare use case we should not cater
for, and custom data on the real OS clipboard is considered too risky,
we can of course spec that the browsers should keep custom data
somewhere internally and augment the DataTransfer object with the
internally stored custom data as if it were on the clipboard on the
next paste (unless the OS clipboard's contents changed meanwhile).
This seems harder to test and harder to get right, but it is a
judgement call.


Sangwhan Moon | 3 Jun 03:45 2016

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

> On Jun 3, 2016, at 01:35, Chaals McCathie Nevile <chaals@...> wrote:
> On Thu, 02 Jun 2016 18:14:38 +0200, <marcos@...> wrote:
>> Can we please kindly stop the +1s spam? It greatly diminishes the value of this mailing list.
>> For the purpose of progressing a spec, the only thing that matters is objections.
> Hi Marcos,
> If there are no objections, then the +1's indeed don't matter. But if there is one or more, then having some
measure of the overall consensus of the group is important.
> It's why we've got the arrangement that except where progressing makes a significant difference, we do it
automatically and allow for objection as the exception case. Moving to CR potentially binds members to
patent commitments, which matters to some members as well as to many people "out there in the wild", and
requires that we demonstrate agreement of the group.
> So I'm sorry for the extra mail, but in this case I'm afraid it's part of running the W3C process. If
everything goes smoothly, you can expect this for HTML twice more in the next year: once to move to Proposed
Recommendation, and once to move 5.2 to First Public Working Draft.

I believe Marcos is raising a valid concern here - while I'm not in full agreement that only objections
matter, most of the people get enough mail already and it does make it easy to get important feedback
lost in a chain of +1 mails. (and when it piles up, it's just something you zip through and mark as read,
now repeat time spent doing that multiplied by subscribers of this ML...)

Having a platform where the chairs/staff can get a quick overview of the consensus stats sounds a
like it could save time in the even anyone needs the consensus statistics. (As mentioned in a earlier
reply, WBS could work, even if it's not a great tool per se.)


>>> On 3 Jun 2016, at 12:36 AM, Mona Rekhi <mona.rekhi@...> wrote:
>>> +1
>>> Mona Rekhi
>>> SSB BART Group
>>> -----Original Message-----
>>> From: Léonie Watson [mailto:tink@...]
>>> Sent: Thursday, June 02, 2016 8:48 AM
>>> To: 'public-webapps WG' <public-webapps@...>
>>> Subject: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)
>>> Hello WP,
>>> This is a call for consensus to request that W3C publish the current HTML Working Draft (WD) as a
Candidate Recommendation (CR). It has been posted to public-webapps@...
as the official email for this WG.
>>> Please reply to this thread on public-webapps@...  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]
>>> [2]
>>> [3]
>>> [issue 43]
>>> [issue 109]
>>> [issues 159/375/422] and links [issue 233]
>>> [issue 269]
>>> [issue 372]
>>> [issue 373]
>>> [issue 427]
>>> [Issue 461]
>>> [Issue 462]
>>> --
>>>  <at> LeonieWatson Carpe diem
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@... - - - Find more at

bugzilla | 2 Jun 22:46 2016

[Bug 18242] Not clear what "script that invoked the method" means exactly in the case of e.g. a.setTimeout(b.postMessage, 0) // called from c

Domenic Denicola <d <at>> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
                 CC|                            |d <at>
         Resolution|---                         |FIXED
           Assignee|cam@...               |d <at>

--- Comment #35 from Domenic Denicola <d <at>> ---
This text no longer appears in HTML, so closing. There is still ongoing work
around figuring out the right globals in various places but that's tracked


You are receiving this mail because:
You are on the CC list for the bug.