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].
; 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
 

Re: Telecon / meeting on first week of April for Web Components

[Xiaoqian Wu]

> On 6 Apr 2016, at 12:29 AM, Jan Miksovsky  wrote:
> 
> I’m unfamiliar with WebEx. If Chaals or someone wants to make a strong push 
> to use that, please set up the call and send out instructions for joining.

We’ve scheduled a WebEx call for this Telecon, in case you will need it.

-
Web Components
Tuesday, April 5, 2016
10:00 am  |  Pacific Daylight Time (San Francisco, GMT-07:00)  |  2 hrs
 
Join WebEx meeting
Link: https://mit.webex.com/mit/j.php?MTID=m6515c79ee5dca2d7b6fd3a07a4dd160a
Meeting number: 643 198 155
Meeting password:   webplatform
 
Join by phone
+1-617-324- US Toll Number
Access code: 643 198 155
Mobile Auto Dial:+1-617-324-,,,643198155#

--

Please feel free to use Google Hangouts if that works better for most of you. 
Have fun.

-xiaoqian

> 
> Baring that, I propose the default meeting location is on Google Hangouts: 
> https://hangouts.google.com/call/rwiluf6hlbhkzf4566hq4biedye 
> . If we go 
> ahead with Hangouts and Chaals can’t join, I’ll volunteer to act as scribe, 
> at least for the beginning.
> 
> I’m on the IRC channel gave (irc://irc.w3.org/#public-webapps 
> ) if anyone wants to discuss pre-call 
> logistics.
> 
> As a reminder: the proposed agenda for the meeting is to go through the 
> “needs consensus” items posted at 
> https://github.com/w3c/webcomponents/issues?q=is%3Aissue+is%3Aopen+label%3A%22needs+consensus%22
>  
> .
>  It sounds like it would be good to resolve pending Shadow DOM issues before 
> tackling Custom Elements issues.

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[Xiaoqian Wu]

Hi Kochi, and all,

The remote participation information of the 25th Jan Web Components meeting is 
available:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md#logistics
 


- VoIP: Join WebEx meeting (via 
https://mit.webex.com/mit/j.php?MTID=me4b93a7982bfcc65aec97d2fa899e787), 
Password [1] Required.
- Phone: +1-617-324- (US Toll Number), 645770213 (access code).

Thanks.

--
xiaoqian

[1] https://lists.w3.org/Archives/Member/w3c-archive/2016Jan/0079.html 


> On 6 Jan 2016, at 6:59 PM, Takayoshi Kochi (河内 隆仁)  wrote:
> 
> 
> 
> On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa  > wrote:
> 
> > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁)  > > wrote:
> >
> > Is there any option to attend this remotely (telcon or video conference)?
> >
> > 2015年12月9日(水) 10:26 Ryosuke Niwa >:
> >>
> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile 
> >> > > wrote:
> >> >
> >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile 
> >> > > wrote:
> >> >
> >> >> we are trying to shift the date of the Custom Elements meeting to *25* 
> >> >> Jan, from the previously proposed date of 29th.
> >> >>
> >> >> We are currently looking for a host in the Bay area - offers gratefully 
> >> >> received.
> >> >
> >> > Apple have kindly agreed to host the meeting, so it will be at 1 
> >> > Infinite Loop, Cupertino. I'll update the page shortly with logistics 
> >> > information.
> >> >
> >> > Note that if you are driving, you should allow an extra 10 minutes or so 
> >> > for parking. Carpool!
> >>
> >> Added logistics on
> >> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md 
> >> 
> 
> The conference room has a video/telephone conference capability so we should 
> be able to set up Webinars assuming someone from W3C can help us set it up.
> 
> 
> Thanks!
> Please update the logistics page if it is set up.
>  
> - R. Niwa
> 
> 
> -- 
> Takayoshi Kochi

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

[Xiaoqian Wu]

> On 30 Nov 2015, at 10:02 PM, Boris Zbarsky <bzbar...@mit.edu> 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 
<https://w3c.github.io/test-results/workers/dedicated-less-than-2#test-file-15>
> 
> -Boris
> 

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

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. ; 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.  (which pass 
on Chrome);  (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

Re: PSA: Change the Latest Editor's Drafts of WebStorage, WebWorkers, WebMessaging, Server-Sent Events and WebSockets

[Xiaoqian Wu]

> On 21 Oct, 2015, at 1:52 am, Arthur Barstow <art.bars...@gmail.com> wrote:
> 
> On 10/19/15 1:52 PM, Xiaoqian Wu wrote:
>> The Web Platform WG intents to update the Latest Editor's Drafts of a set of 
>> HTML5 API specs, including WebStorage, WebWorkers, WebMessaging, Server-Sent 
>> Events and WebSockets. As no one in WPWG has committed to work on these 
>> specs, the latest EDs will be the WHATWG version.
> 
> Hi Xiaoqian,
> 
> Is the plan to gut the current ED of all content except a link to the WHATWG 
> LS plus a message like "For the latest version of this specification use the 
> WHATWG's Living Standard.”?

Hi Art,

+1. Thanks for the good advice. 

—
xiaoqian

> 
> -Thanks, AB
> 
> 

PSA: Change the Latest Editor's Drafts of WebStorage, WebWorkers, WebMessaging, Server-Sent Events and WebSockets

[Xiaoqian Wu]

Hi All,

The Web Platform WG intents to update the Latest Editor's Drafts of a set of 
HTML5 API specs, including WebStorage, WebWorkers, WebMessaging, Server-Sent 
Events and WebSockets. As no one in WPWG has committed to work on these specs, 
the latest EDs will be the WHATWG version. Please find the list of suggested 
changes below. 

* Web Storage (CR): Editor's Draft will be 
https://html.spec.whatwg.org/multipage/webstorage.html 
;
* WebWorkers (WD): Editor's Draft will be 
https://html.spec.whatwg.org/multipage/workers.html 
;
* WebMessaging (REC): Editor's Draft will be 
https://html.spec.whatwg.org/multipage/comms.html 
;
* WebSockets (CR): Editor's Draft will be 
https://html.spec.whatwg.org/multipage/comms.html#network 
;
* Server-Sent Events (REC): Editor's Draft will be 
https://html.spec.whatwg.org/multipage/comms.html#server-sent-events 
.

The Web Platform WG will continue to maintain a stable version for each of 
these specs (while they are moving along the W3C Recommendation track), and 
deliver an updated version if necessary.

If you have any concerns with this proposal, please let us know by 22 October.

Thanks.

--
xiaoqian

Re: Normative references to Workers.

[Xiaoqian Wu]

> On 22 Sep, 2015, at 1:35 am, Anne van Kesteren  wrote:
> 
> On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow  wrote:
>> On 9/21/15 5:54 AM, Ms2ger wrote:
>>> Why?
>> 
>> I think the rationale was mentioned in
>> .
> 
> Ms2ger made a valid point. Workers is actively being updated (I
> submitted two PRs the other day, more to come). If you don't want to
> get out-of-sync you won't get to REC in the foreseeable future. It
> therefore is likely a waste of time for someone to volunteer to
> copy-and-paste text that is unstable.
> 

Thanks for explaining the situation :)

If the spec is still changing frequently, indeed it isn't a good idea to 
publish another CR… but the WebApps WG needs to clearly tell the community that 
the 2012 CR should be considered obsolete. 

I’d suggest that we publish a WD for Workers, which adapts to the current 
changes and revise the 2012 CR. The community is encouraged to refer to either 
the WHATWG version or the new WD. 

—
xiaoqian

> 
> -- 
> https://annevankesteren.nl/
> 

Re: Normative references to Workers.

[Xiaoqian Wu]

> On 16 Sep, 2015, at 8:17 pm, Arthur Barstow  wrote:
> 
> On 9/16/15 4:47 AM, Mike West wrote:
>> Note that this is an issue that's going to come up for a number of WebAppSec 
>> specs (see 
>> https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8 
>> , 
>> for instance (and that spec also needs a few things that are missing from 
>> W3C's HTML, but are present in WHATWG's)). What I hear so far on this thread 
>> is that we should simply reference the WHATWG version of those specs, which 
>> seems like a reasonable thing to do.
> 
> Yes, for the scenario you mention, I agree with you.
> 
> The grey area is when a feature is defined by both a W3C WG and WHATWG. 
> Because of the consortium's Patent Policy, I suspect consensus among 
> consortium members is to use the W3C spec for normative references. However, 
> if the W3C spec is no longer actively maintained by a WG, then normatively 
> referencing a WHATWG spec would (IMHO) be appropriate and I think the 
> Normative Reference Policy [NRP] supports such a scenario.
> 
> In this specific case, I don't believe anyone has committed to actively 
> maintain W3C Web Workers. As such, WebApps - do we have a volunteer? Please 
> let us know (or send me private e-mail if you prefer).

If it helps, I’d like to prepare a Workers draft to revise the previous CR, and 
schedule the publication ASAP (hopefully 22 Sep). The goal is to synchronise 
with the upstream, to document the changes since the previous CR and to 
identify the "at risk” features. 

Thanks.

--
xiaoqian

> 
> -Thanks, AB
> 
> [NRP] 
> 
> 
>> 
>> -mike
>> 
>> --
>> Mike West >, @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.)
>> 
>> On Tue, Sep 15, 2015 at 7:31 PM, Mike West > > wrote:
>> 
>>The "Upgrade Insecure Requests" specification[1] references the
>>WHATWG HTML spec for the
>>"set up a worker environment settings object" algorithm[2], as the
>>Web Workers Candidate Recommendation from May 2012[3]
>>substantially predates the entire concept of a "settings object",
>>and because the WHATWG is the group where work on Workers seems to
>>be being done.
>> 
>>This referential choice was flagged during a discussion of
>>transitioning the Upgrade spec to CR, where it was noted that the
>>Web Workers editor's draft from May 2014 does contain the
>>referenced concept[4].
>> 
>>It seems appropriate, then, to bring the question to this group:
>>does WebApps intend to update the Workers draft in TR? If so, is
>>there a path forward to aligning the Workers document with the
>>work that's happened over the last year and a half in WHATWG?
>>Alternatively, does WebApps intend to drop work on Workers in
>>favor of the WHATWG's document?
>> 
>>It would be helpful if we could get some clarity here. :)
>> 
>>Thanks!
>> 
>>[1]: https://w3c.github.io/webappsec/specs/upgrade/
>>[2]:
>>
>> https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
>>[3]: http://www.w3.org/TR/workers/
>>[4]: https://w3c.github.io/workers/
>> 
>>--
>>Mike West >, @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.)
>> 
>> 
> 
> 

Minutes from WebApps + HTMLWG Editing Task Force face to face meeting

[Xiaoqian Wu]

Hi folks,

The minutes of the August 23-24 Editing Task Force f2f meeting are available as:
* http://www.w3.org/2015/08/23-webapps-minutes.html 
http://www.w3.org/2015/08/23-webapps-minutes.html
* http://www.w3.org/2015/08/24-webapps-minutes.html 
http://www.w3.org/2015/08/24-webapps-minutes.html

- RESOLUTION: We think we want strict subsets - events is a subset of caret is 
a subset of typing which is a subset of true.
- RESOLUTION: we want information in selection that says where the caret is - 
before/after linebreak, where in a bidi boundary it is, and a way to say how to 
put it in a given place (before, after, or at both ends). Primitives for a 
superset of all browser behaviour, but browsers will choose for themselves 
where to put it and leave editor implementors to normalise that if they want it
- RESOLUTION: For now we can live with not being able to solve the edge case of 
knowing which end of a bidi block you get to when you move the DOM across to a 
different browser
- RESOLUTION: We are going to focus on describing ce=typing as a priority.
- RESOLUTION: : We will have typing with compositionstart (cancelable) when you 
can set a selection point, then a series on non cancelable beforeinputs to 
replace text, and two kinds of delete events - one inside composition not 
cancelable, and a normal one to be handled by the application
- RESOLUTION: We will ask the accessibility people to look at IMEs and the 
problems we should have considered here but didn’t.
- RESOLUTION: remove caret, and put it in beforeselectionchange in selection API
- RESOLUTION: have a relatedEvent to point to the UI event that caused a DI 
event to be fired.
- RESOLUTION: one delete event with data for forward/backward
- RESOLUTION: We want to be able to insert newline or new paragraph

Thanks to all meeting participants, the scribes/chairs, and the host.

--
xiaoqian

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Xiaoqian Wu]

 On 6 Jul, 2015, at 5:18 pm, Hayato Ito hay...@google.com wrote:
 
 I've finished the migration. All 141 bugs have been migrated [1]. I'll triage 
 the migrated bugs manually later.
 
 I'm sorry that public-webapps@ has received the mass flood of bugspam mail 
 again this time. That's unintentional.
 The lesson for for the future: We need to change also the setting of *every* 
 bugs to stop the auto-emails, not only from the default CC list.
 
 From now on, please use the GitHub issues [2] to file a bug for Web 
 Components. I've already updated [3] the editors' drafts of Custom Elements 
 and HTML Imports so that they have a link to GitHub Issues.
 xiaoqian@ will kindly disable the bugzilla component, Component Models, so 
 that people won't add a bug there.

Thanks Hayato.

Fyi, this bugzilla component has been disabled and renamed as HISTORICAL - 
Component Model”.

—
xiaoqian

 
 - [1]: https://github.com/w3c/webcomponents/issues/119 
 https://github.com/w3c/webcomponents/issues/119
 - [2]: https://github.com/w3c/webcomponents/issues 
 https://github.com/w3c/webcomponents/issues
 - [3]: 
 https://github.com/w3c/webcomponents/commit/54434ada278440999649915b00772b6e96e57d4d
  
 https://github.com/w3c/webcomponents/commit/54434ada278440999649915b00772b6e96e57d4d
 
 
 On Wed, Jul 1, 2015 at 4:24 PM Xiaoqian Wu xiaoq...@w3.org 
 mailto:xiaoq...@w3.org wrote:
 
 On 1 Jul, 2015, at 1:30 pm, Hayato Ito hay...@google.com 
 mailto:hay...@google.com wrote:
 
 Thank you. I appreciate that. Then, let me migrate all open bugs of 
 'Component Model'. I think that include also HTML Imports bugs in addition 
 to Custom Elements bugs.
 When I finish, I'll announce that.
 
 SGTM. Please go ahead.
 
 —
 xiaoqian

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Xiaoqian Wu]

 On 1 Jul, 2015, at 1:30 pm, Hayato Ito hay...@google.com wrote:
 
 Thank you. I appreciate that. Then, let me migrate all open bugs of 
 'Component Model'. I think that include also HTML Imports bugs in addition to 
 Custom Elements bugs.
 When I finish, I'll announce that.

SGTM. Please go ahead.

—
xiaoqian

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Xiaoqian Wu]

Hi Hayato, 

public-webapps has been removed from the default CC list of ‘Component Model’. 
Please let us know when you finish migrating and we will recover this component 
ASAP.

Thanks.

—
xiaoqian

 On 29 Jun, 2015, at 10:42 pm, Arthur Barstow art.bars...@gmail.com wrote:
 
 Yves, Xiaoqian, Mike - would one of you please do as Hayato requests below 
 (and then notify him so he can move the Custom Elements bugs to Github)?
 
 -Thanks, ArtB
 
 On 6/25/15 2:49 AM, Hayato Ito wrote:
 I am thinking about migrating Custom Element bugs[1] to Web Components 
 GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the 
 consistency.
 
 Could someone turn off the automatic email to public-webapps for Custom 
 Elements Bugs in the bugzilla so that we won't receive the mass flood of 
 bugspam by marking the all bugs MOVED? I'm assuming the automatic email is 
 on for public-webapps@.
 
 If you have any concerns about migrating, let me know that.
 
 [1] 
 https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1
 [2] https://github.com/w3c/webcomponents/issues
 
 On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com 
 mailto:hay...@google.com wrote:
 
I totally agree. I'm really sorry for spamming. I forgot that
closing a bug would trigger sending a mail to public-webapps@. My bad.
 
I thought that a closing bug would notify only people who opted-in
to add themselves to a list of cc in each bug. That might be a
good opportunity for them to keep tracking of the bug status by
subscribing a migrated bug on GitHub Issues.
 
On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr.
jackalm...@gmail.com mailto:jackalm...@gmail.com wrote:
 
Note for the future (to you and editors of other specs in
WebApps):
 
Before doing this kind of mass bug editting, please turn off the
automatic email to public-webapps.  If you can't do that yourself,
Mike Smith can (at least, he's done it in the past).  That
prevents
the mass flood of bugspam from clogging up people's inboxes. ^_^
 
~TJ
 
On Tue, May 26, 2015 at 8:30 PM, Hayato Ito hay...@google.com
mailto:hay...@google.com wrote:
 PSA: I've finished the migration. All open bugs are now
marked as MOVED
 with a link to the corresponding GitHub issue.

 On Mon, May 25, 2015 at 5:58 PM Hayato Ito
hay...@google.com mailto:hay...@google.com wrote:

 Regarding with the Shadow DOM spec, more and more workflows
are happening
 [1] on GitHub w3c/webcomponents repository recently.
 Therefore, I am thinking about migrating the bugs of the
Shadow DOM spec,
 from the bugzilla [2], to the GitHub issues [3], as some of
other specs are
 already doing so.

 As an experiment, I've just migrated the existing open bugs
on the
 bugzilla to the GitHub issues, by a tiny script I've
written using GitHub
 APIs.

 Unless there is an objection to the migration, I am going
to close the
 existing open Shadow DOM spec bugs on the bugzilla, with a
link to the
 corresponding bug on the GitHub issues.

 Please let me know if you have a concern.

 [1] https://github.com/w3c/webcomponents/commits/gh-pages
 [2]
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978
 [3] https://github.com/w3c/webcomponents/issues


 
 

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
 

A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

[Xiaoqian Wu]

Thanks for bringing this up, Anssi.

The diff between the REC and the latest Editor’s Draft[1] indicated at least 
two normative changes, so I’d like to propose a second edition of Web Storage. 
What do you say?

Here’s my analysis for the current mutex. All your comments are welcome.

* ED L174, L283
- WEBIDL Updated. The getter of the Storage interface and the key of the 
StorageEvent are Nullable;
- The test suite has been update for these changes[2][3] . These changes are 
widely implemented by the browsers.
- These changes are normative and should be accepted in the second edition.

* ED L187
- The supported property names on a Storage object should be in the order that 
the keys were last added to the storage area”(added).
- I wrote a test case[4] for this but the implementation doesn’t seem to follow 
this instruction. It’s more likely to be *in the order of keys that was defined 
by the user-agent*.
- Giving the fact this change is non-normative, we should either ignore it or 
update the instruction to be *in the order of keys that was defined by the 
user-agent*.

* ED L262
- Remove 4.3.1 (LocalStorage) Security.
- The former section claimed that user agents must throw a SecurityError 
whenever any of the members of a Storage object originally returned by the 
localStorage attribute are accessed by scripts whose effective script origin is 
not the same as the origin of the Document of the Window object on which the 
localStorage attribute was accessed. 
- There was discussion[5] that this section wasn’t clear enough, dating back to 
2012. I couldn’t find any related topics in the mailing list about why the 
editor removed this section after the Rec.
- My test case[6] indicates none of Chrome/Firefox/Safari throws the 
SecurityError in that case.
- This is a normative change and should be accepted in the second edition.

Other changes are more editorial and can be kept in the second edition, imo. 
Moreover, the archives of the Issue section need to be updated in the new 
document because the formal archives are no longer available.

A draft second edition of WebStorage[7](diff[8]) is available in GitHub. Please 
feel free to raise issues or PRs there.

FYI, according to the 2014 process document[9], to modify a Rec, we can either 
go through FPWD-CR-PR-REC, or if we can prove wide review for the changes, 
things will be easier, i.e., CR-PR-REC.

Thanks.

—
xiaoqian

[1] https://www.diffchecker.com/npgkwj7d https://www.diffchecker.com/npgkwj7d
[2] https://github.com/w3c/web-platform-tests/pull/1784 
https://github.com/w3c/web-platform-tests/pull/1784
[3] 
https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html
 
https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html
[4] 
https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html
 
https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17 
https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17
[6] 
https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror
 
https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror
[7] https://github.com/w3c/webstorage https://github.com/w3c/webstorage
[8] https://www.diffchecker.com/dkbtofsi https://www.diffchecker.com/dkbtofsi
[9] http://www.w3.org/2014/Process-20140801/#rec-modify 
http://www.w3.org/2014/Process-20140801/#rec-modify
 On 2015-4-30, at 8:02pm, Kostiainen, Anssi anssi.kostiai...@intel.com wrote:
 
 Hi,
 
 On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com wrote:
 
 On 4/21/15 5:39 AM, Kostiainen, Anssi wrote:
 Hi,
 
 Is there a plan to publish an errata to sync the Web Storage Rec [1] with 
 the latest? I counted 8 commits cherry picked into the Editor's Draft since 
 Rec [2].
 
 If no errata publication is planned, I'd expect the Rec to clearly indicate 
 its status.
 
 Re the priority of this issue, is this mostly a truth and beauty 
 process-type request or is this issue actually creating a problem(s)? (If 
 the later, I would appreciate it, if you would please provide some 
 additional context.)
 
 It was creating problems. Our QA was confused which spec was the 
 authoritative one, and wrote tests (additional ones, on top of the w-p-t 
 tests) against the Rec spec. These tests failed since Blink is compliant with 
 the latest, not the Rec. More context at: 
 https://crosswalk-project.org/jira/browse/XWALK-3527
 
 The main thing blocking the publication of errata is a commitment from 
 someone to actually do the work. I also think Ian's automatic push of 
 commits from the WHATWG version of Web Storage to [2] was stopped a long 
 time ago so there could be additional changes to be considered, and the 
 totality of changes could include normative changes. Did you check for these 
 later 

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