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

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

Re: Meeting between Web platform and ARIA at TPAC

[Chaals McCathie Nevile]

Hi Rich

Cc+ Adrian - co-chair of the WG

On Thu, 04 Aug 2016 16:00:18 +0200, Rich Schwerdtfeger  
<richsch...@gmail.com> wrote:



Leonie, Charles,

I would like to request a 90 minute meeting on Friday at TPAC.


We generally don't have more than 60 minutes for meeting sessions. You're  
requesting a joint session with the ARIA WG, right?


I've put a marker into the agenda for now:  
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23TPAC-4.md


Of critical importance is the discussion regarding the requirements  
around Web Components. Some issues I know we need to discuss are:


1. ARIA 2.0 extensibility
2. ARIA  2.0 needed semantics


Can you provide a bit more framing information for these questions? What  
do you think WP can help with?


3. Ability to reference elements inside a web component and from within  
the web component to outside the web component.


This sounds like it should be brought up directly in the Web Components  
work. We don't expect many, if any, of the people most involved in that to  
be there on Friday, having set aside a full day for the topic on the  
Monday.


Again, framing the issue in more detail in advance would be helpful. Is  
there a requirement to do this, a use case, do you want it to be  
impossible, or what? It would probably be a good idea to check the issues  
currently filed, and if there isn't an issue (open or closed) that matches  
this, then file one - or if there is one already explain your use cases /  
requirements there.


cheers

Chaals

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

Type correction Re: New editors for Clipboard API spec

[Chaals McCathie Nevile]

On Sun, 31 Jul 2016 02:16:17 +0200, Chaals McCathie Nevile  
<cha...@yandex-team.ru> wrote:



Hi,

I'm happy to announce


Grisha *Lyukshin*. Sorry Grisha

and Gary Kačmarčik as the new editors of the Clipboard API  
specification, and to thank them for

volunteering,


cheers


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

Fwd: Minutes / results of editing meeting

[Chaals McCathie Nevile]

FYI

--- Forwarded message ---
From: "Chaals McCathie Nevile" <cha...@yandex-team.ru>
To: "public-editing...@w3.org" <public-editing...@w3.org>
Cc:
Subject: Minutes / results of meeting
Date: Sat, 30 Jul 2016 23:51:18 +0200

Hi folks,

Detailed minutes are at http://www.w3.org/2016/07/29-editing-minutes.html

Gary produced a summary of what we said and decided at
https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ

And Grisha filed issues, and what we decided on them, in the issue tracker
https://github.com/w3c/editing

Thanks to Ojan and Google for hosting.

cheers


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

New editors for Clipboard API spec

[Chaals McCathie Nevile]

Hi,

I'm happy to announce Grisha Lyushkin and Gary Kačmarčik as the new editors
of the Clipboard API specification, and to thank them for volunteering, as
well as Hallvord for the work he put into it until now.

cheers

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

Re: Draft recharter proposal

[Chaals McCathie Nevile]

On Fri, 29 Jul 2016 18:29:44 +0200, Olli Pettay <o...@pettay.fi> wrote:


On 07/29/2016 06:13 PM, Chaals McCathie Nevile wrote:

Hi folks,

our charter expires at the end of September. I've produced a draft  
version of a new charter, for people to comment on:

http://w3c.github.io/charter-html/group-charter.html

Feel free to raise comments as issues:  
https://github.com/w3c/charter-html/issues/new


As per the change section:

New deliverables:
Microdata

Removed as deliverables:
Streams; URL; XHR1

Marked as deliverables to be taken up if incubation suggests likely  
success:
Background Synchronisation; Filesystem API; FindText API; HTML Import;  
Input Methods; Packaging; Quota API



Given what has been happening with directory upload stuff recently,  
Filesystem stuff is a bit controversial.
(Gecko and Edge implementing https://wicg.github.io/entries-api/, or  
something quite similar. The draft doesn't quite follow browsers.

  Entries API is a subset of what Blink has been shipping.)
But I think some way better API than the old Chrome-only API should be  
implemented for Filesystem in general, and at that point also

better stuff for directory upload, *and* for directory download.
I'd consider the callback based, awkward to use Blink API a legacy thing.


Filesystem is a bit controversial - there have been a number of proposals  
over most of a decade now. The idea is that if we have one that matches  
something browsers do and want to continue with, and we maintain it, that  
would be a helpful thing to do.


I thought it is pretty much agreed that HTML Import is deprecated, or  
something to not to do now.


At any rate, I believe there is not enough apparent interest to rate it as  
a definite work item.


Both of those are in a section of things the group *may* do, if there is  
reason to expect success, but I think that could be made much clearer in  
the document.


Microdata has very wide ongoing usage, and it would be helpful to have  
something clearer than the current W3C Note - which includes things  
that don't
work - for people to refer to. So I'm proposing to do the editing,  
along with Dan Brickley from Google, and to work roughly on the basis  
we use in
HTML of specifying what actually works, rather than adding in what we  
would like.



So the only implementation of HTML Microdata API in browsers was removed  
recently
https://bugzilla.mozilla.org/show_bug.cgi?id=909633 because exposing the  
API caused web pages to break.


Yes, removing the API from the spec is one of the things we expect to do.  
Browsers generally do nothing with microdata as far as I know, which is  
fine. It's not particularly directed at them anyway. It's used by search  
engines, and put into massive numbers of web sites for that purpose.


cheers, and thanks for the comments.

Chaals

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

Draft recharter proposal

[Chaals McCathie Nevile]

Hi folks,

our charter expires at the end of September. I've produced a draft version  
of a new charter, for people to comment on:  
http://w3c.github.io/charter-html/group-charter.html


Feel free to raise comments as issues:  
https://github.com/w3c/charter-html/issues/new


As per the change section:

New deliverables:
Microdata

Removed as deliverables:
Streams; URL; XHR1

Marked as deliverables to be taken up if incubation suggests likely  
success:
Background Synchronisation; Filesystem API; FindText API; HTML Import;  
Input Methods; Packaging; Quota API


Microdata has very wide ongoing usage, and it would be helpful to have  
something clearer than the current W3C Note - which includes things that  
don't work - for people to refer to. So I'm proposing to do the editing,  
along with Dan Brickley from Google, and to work roughly on the basis we  
use in HTML of specifying what actually works, rather than adding in what  
we would like.


cheers

Chaals

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

Re: Call for Consensus: Publish HTML 5.2 FPWD?

[Chaals McCathie Nevile]

On Tue, 05 Jul 2016 16:15:32 +0200, Chaals McCathie Nevile  
<cha...@yandex-team.ru> wrote:



This is a call for consensus on the proposition:

Publish the current editors' draft of HTML 5.2 -  
https://w3c.github.io/html/ - as a First Public Working Draft.


With a positive response and no objections, the call for consensus passes.  
We will prepare a draft and Transition request, and hope to make the  
publication next week.



You can provide a response in this email thread.

You can provide a comment or thumbs-up in the issue in the HTML repo -  
https://github.com/w3c/html/issues/515


Most responses were in fact on the HTML repo.

You can provide a comment or thumbs-up in the issue in the WebPlatformWG  
repo - https://github.com/w3c/WebPlatformWG/issues/43


Thanks all

Chaals for the chairs and editors

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

Review request: Wake Lock API

[Chaals McCathie Nevile]

Hello all,

The Device & Sensors Working Group has asked us to review the Wake Lock
API, on it way to Candidate Recommendation status:
https://www.w3.org/TR/wake-lock/

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:  https://github.com/w3c/wake-lock/issues

Alternatively, comments can be made by email to the public mailing list
public-device-a...@w3.org 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.


cheers

Chaals

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

Re: Quick update on WebIDL "Level 1"

[Chaals McCathie Nevile]

On Fri, 08 Jul 2016 22:21:10 +0200, Domenic Denicola  wrote:


From: Travis Leithead [mailto:travis.leith...@microsoft.com]

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.


Why is it acceptable for specs to reference a version of Web IDL that  
nobody should implement?


That's not what Travis describes. To restate his message above, the Level  
1 spec is "what people already implement". The Level 2 editor's draft is  
"what you should look at if you want to make a new implementation with all  
the new stuff - but be aware that some if it is up for debate and might  
change".


cheers

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

Thank you Hallvord (looking for Clipboard API editor…)

[Chaals McCathie Nevile]

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.


cheers

Chaals

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

Call for Consensus: Publish HTML 5.2 FPWD?

[Chaals McCathie Nevile]

This is a call for consensus on the proposition:

Publish the current editors' draft of HTML 5.2 -  
https://w3c.github.io/html/ - 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 -  
https://github.com/w3c/html/issues/515


You can provide a comment or thumbs-up in the issue in the WebPlatformWG  
repo - https://github.com/w3c/WebPlatformWG/issues/43


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


cheers

Chaals, for the chairs

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


abstain

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


Looks good, +1

—Michiel

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

Hello WP,

This is a Call For Consensus (CFC) to request that W3C republish  
Pointer
Lock as a Candidate Recommendation (CR). Extensions to the  
MouseEventInit

Dictionary [1] constitute substantive changes to the specification that
were
made after the current CR was published in 2013 [2].

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

silence will be considered as consent.

Thank you.

Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
[1]

https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
ry
[2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
--
@LeonieWatson tink.uk Carpe diem








--
Download the aXe browser extension for free:

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
Chrome:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

Life is ten percent what happens to you and ninety percent how you  
respond

to it. - Lou Holtz





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

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

[Chaals McCathie Nevile]

On Thu, 02 Jun 2016 18:14:38 +0200, <mar...@marcosc.com> 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.


cheers

Chaals

On 3 Jun 2016, at 12:36 AM, Mona Rekhi <mona.re...@ssbbartgroup.com>  
wrote:


+1

Mona Rekhi
SSB BART Group

-Original Message-
From: Léonie Watson [mailto:t...@tink.uk]
Sent: Thursday, June 02, 2016 8:48 AM
To: 'public-webapps WG' <public-webapps@w3.org>
Subject: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

Hello WP,

This is a call for consensus to request that W3C publish the current  
HTML Working Draft (WD) as a Candidate Recommendation (CR). It has been  
posted to public-webapps@w3.org as the official email for this WG.


Please reply to this thread on public-webapps@w3.org  no later than end  
of day on 10 June. Positive responses are preferred and encouraged,  
silence will be considered as assent.


The current HTML5.1 WD [1] improves upon HTML5. It includes updates  
that make it more reliable, more readable and understandable, and a  
better match for reality. Substantial changes between HTML5 and HTML5.1  
can be found in the spec [2].


When a specification moves to CR it triggers a Call For Exclusions, per  
section 4 of the W3C Patent Policy [3]. No substantive additions can be  
made to a specification in CR without starting a new Call for  
Exclusions, so we will put HTML5.1 into "feature freeze". It is  
possible to make editorial updates as necessary, and features marked  
"At Risk" may be removed if found not to be interoperable.


The following features are considered "at risk". If we cannot identify  
at least two shipping implementations, they will be marked "at risk" in  
the CR and may be removed from the Proposed Recommendation.


keygen element. [issue 43]
label as a reassociatable element [issue 109] Fixing  
requestAnimationFrame to 60Hz, not implementation-defined [issues  
159/375/422] registerContentHandler [Issue 233] inputmode attribute of  
the input element [issue 269] autofill of form elements [issue 372]  
menu, menuitem and context menus. [issue 373] dialog element [issue  
427] Text tracks exposing in-band metadata best practices [Issue 461]  
datetime and datatime-local states of the input element [Issue 462]


Please share implementation details for any of these features on  
Github. To mark other features "at risk", please identify them by 10th  
June (ideally by filing an issue and providing a test case).


At the same time we move HTML5.1 into CR, we plan to continue updating  
the Editor's Draft, and in the next few weeks we expect to post a Call  
for Consensus to publish it as the First Public Working Draft of  
HTML5.2, so improving HTML will continue without a pause. It also means  
that changes that didn't make it into
HTML5.1 will not have long to wait before being incorporated into the  
specification.


Léonie on behalf of the WP chairs and team, and HTML editors.
[1] https://www.w3.org/TR/html51/
[2] https://www.w3.org/TR/html51/changes.html#changes
[3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion

[issue 43] https://github.com/w3c/html/issues/43
[issue 109] https://github.com/w3c/html/issues/109
[issues 159/375/422] https://github.com/w3c/html/issues/159 and links  
[issue 233] https://github.com/w3c/html/issues/233

[issue 269] https://github.com/w3c/html/issues/269
[issue 372] https://github.com/w3c/html/issues/372
[issue 373] https://github.com/w3c/html/issues/373
[issue 427] https://github.com/w3c/html/issues/427
[Issue 461] https://github.com/w3c/html/issues/461
[Issue 462] https://github.com/w3c/html/issues/462


--
@LeonieWatson tink.uk Carpe diem











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

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 <t...@tink.uk> 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

Re: Self-introduction from Wanming Lin

[Chaals McCathie Nevile]

Welcome Wanming!

On Tue, 31 May 2016 09:46:15 +0200, Lin, Wanming   
wrote:



Hello WP,

My name is Wanming Lin, many thanks Wayne for inviting me join in WP WG.

I work for Intel OTC Web QA team which focuses on testing work for  
advanced Web technologies especially for latest W3C standard Web APIs.  
We started to contribute Web API test cases to W3C upstream since early  
2012, also continuously submit tests, participate in technical  
discussion in the community mailing lists, review test code from others,  
participant in and make presentations in events.


I am proud to represent my team to join in this group, I am a newbie but  
I will try my best.

Looking forward to working with you all.

Best regards,
Wanming





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

[Service Workers] meeting july/august?

[Chaals McCathie Nevile]

Hi folks,

at the last meeting people suggested another meeting in July/August.  
Should we be trying to schedule one?


The Editing folks are meeting in California 29 July. Something just before  
that would be very convenient for *me*. Others of course may have  
unaccountably different schedules. But it is generally good to give 8  
weeks notice so if people need to plan travel they can.


A meeting roughly a week after 29 July also works well for me.

Thoughts?

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

About the packaging spec Re: CFC

[Chaals McCathie Nevile]

Hi Marcos,

On Wed, 25 May 2016 00:52:07 +0100,  wrote:


On 25 May 2016, at 3:54 AM, Léonie Watson  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: 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

Re: [service worker] f2f meeting notes, next meeting details

[Chaals McCathie Nevile]

On Fri, 08 Apr 2016 07:01:14 +0200, Matt Falkenhagen <fal...@chromium.org>  
wrote:



2016-02-10 0:21 GMT+09:00 Chaals McCathie Nevile <cha...@yandex-team.ru>:


There will be another face to face meeting to discuss service workers,
hosted by Microsoft in Seattle or Redmond, on 11-12 April. Right now  
there

is a stub page for the meeting:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/11-12aprSW.md

To register for the meeting, or request agenda or remote attendance  
please

make a pull request on that page or in reply to this thread on the email
list.



FYI there some pull requests still open:
https://github.com/w3c/WebPlatformWG/pulls


Yeah, sorry, I got distracted and broke the merge button. It's been fixed  
- thanks for the reminder.


cheers

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

[Web Components] Minutes - Shadow DOM teleconf April 5

[Chaals McCathie Nevile]

Available at https://www.w3.org/2016/04/05-webapps-minutes.html or as text  
below.


Thanks to Jan Miksovsky for logistics, and in particular for scribing!

   [1]W3C

  [1] http://www.w3.org/

   - DRAFT -

 Web Components Teleconference

05 Apr 2016

   See also: [2]IRC log

  [2] http://www.w3.org/2016/04/05-webapps-irc

Attendees

   Present
  Jan Miksovsky, Domenic Denicola, Ryosuke Niwa, annevk,
  Dimitri Glazkov, Elliott Sprehn, Travis Leithead, Hayato
  Ito, dan, smaug

   Regrets
   Chair
  SV_MEETING_CHAIR

   Scribe
  Jan Miksovsky
 __

Rniwa proposing we go through Domenic’s prioritized list
   of issues

   Domenic: let’s start with some easy ones
   ... seems like “restrict to secure contents” is not going to
   happen

   [no one objects]

   Domenic: I’ll note that in the thread

   annek: on attributeChangedCallback order, sounds like we can’t
   agree on an order

   rniwa: order is an interop issue

   annek: it’s going to take a long time before Gecko gets around
   to (preserving stable attribute order)

   elliott: there’s stuff to be sacrificed there
   ... what webkit does doesn’t end up with memory optimization
   ... we’re asking Gecko to reduce the effectiveness of their
   memory optimization
   ... Chrome and WebKit both agree

   elliott: there’s no interop here, so if we change it, nothing
   breaks
   ... MutationObserver is going to give you totally different
   order in diff browsers

   domenic: propose: keep the order that’s in the spec, general
   willingness to converge on determinism

   rniwa: ok, but I wouldn’t necessarily block the other browsers
   from implementing custom elements (by forcing determinism)

   elliott: doesn’t seem like a big enough win for Gecko

sorry dglazkov :-(

   Travis: try again

no jokes this time I guess

hangouts_queue.pop()

   (Travis joins video chat)

   rniwa: should we tackle “parse  like ”?

   annek: it sounds like nobody is really interested in making
   parser changes
   ... i’m tempted to punt on the whole thing
   ... ideally a custom element could replace a , etc.,
   but...

   rniwa: I thikn that this would be really risky
   ... we’ve seen elements in the wild with a dash in their name,
   so changing this would be risky

   domenic: this would be nice, but probably not worth it
   ... nobody seems to be strongly advocating for it

   annek: this is probably okay as is

   travis: is there a good workaround?

   annke: you can always just use the DOM API to restrict your
   tree instead of the parser

   annek: but that’s a workaround
   ... or you could use custom elements for everything, reinvent
   all the elements

   elliott: that’s funny, html tables is missing column spans,
   that’s the only reason people use real tables
   ... the generalized solution we’d like to pursue is a meta tag
   that lets you opt into a more streamlined parser

   annek: an XML5 (?) parser

   elliott: we’ve spend so much time band-aiding this thing,
   that’s why we never went there

   annek: in general, that’s a fine plan

   travis: sounds like versioning to me

   annek: sounds more like strict mode

   elliott: the nature of such a thing is off topic

   annek: it is hard

   rniwa: alternative is to have an attribute to add an element to
   a slot

   domenic: certainly not v1, but any reason why that’s not a good
   idea

   rniwa: it kind of violates the fundamentals of the element

   annek: do you use display: contents on it, and then what does
   that mean? sounds like v2

   rniwa: an attribute way of adding a slot might be a v2 thing

   elliott: if this is popular, someone will write a library to
   (implement this feature), and that will be a signal to do this

   annek: let’s move to the top of the list, issue 308: should we
   use “display: contents"?
   ... I’m going to say “yes"
   ... … Gecko has an implementation of display: contents.

   rniwa: We haven’t done this yet, but our intention is to do so

   domenic: our position: reasonable semantics, main concern is
   that this adds a lot of implmentation
   ... would delay getting this into users’ hands

   travis: can someone restate the problem

   annek: can the  element itself end up in the final
   layout/flat tree

   if it ends up there, you can style it; if not, you can’t do
   anything with it

   travis: iframes are sort of like super-slots, and they’re
   independently styleable
   ... but its background color doesn’t matter, because it gets
   replaced

   (as jan) I haven’t seend the need for this

   travis: maybe it shouldn’t have a particular representation

   annek: if blink ships with its current idea of not having it in
   the layout tree, ...

   and then changes some months later...

   elliott: this doesn’t really work, you could end up styling the
   slot by mistake
   

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

[Chaals McCathie Nevile]

On Thu, 31 Mar 2016 13:45:16 +0200, Chaals McCathie Nevile  
<cha...@yandex-team.ru> wrote:


On Wed, 30 Mar 2016 23:24:59 +0200, Jan Miksovsky  
<jan@component.kitchen> wrote:


It sounds like there’s general interest in making this happen, so I  
went ahead and set up a Doodle poll for this:  
http://doodle.com/poll/z7qvrafbxw4zyit9.


(Chaals: I just noticed you offered to do that as well, but since I’d  
already set it up, I thought I’d sent it out. Hope that’s okay.)


(It's better than OK, I'm glad you did it - thank you

cheers)

If everyone could indicate their availability by, say, this Friday,  
4/1, we can see what time works best for everyone.


I assumed the timezone was Pacific. Please put it into surveys.

I don't consider myself critical or even especially important to this  
discussion. But I think it is important that it gets minuted to the point  
where those who want to know what justifies a given approach can find that.


cheers

Chaals


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

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

[Chaals McCathie Nevile]

On Wed, 30 Mar 2016 23:24:59 +0200, Jan Miksovsky <jan@component.kitchen>  
wrote:


It sounds like there’s general interest in making this happen, so I went  
ahead and set up a Doodle poll for this:  
http://doodle.com/poll/z7qvrafbxw4zyit9.


(Chaals: I just noticed you offered to do that as well, but since I’d  
already set it up, I thought I’d sent it out. Hope that’s okay.)


(It's better than OK, I'm glad you did it - thank you

cheers)

If everyone could indicate their availability by, say, this Friday, 4/1,  
we can see what time works best for everyone.


–Jan



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

TPAC schedule proposal

[Chaals McCathie Nevile]

Hi,

at this stage we're trying to shuffle everything to fit, and of course it  
doesn't. The chairs' current proposal is to request a room for all 4 days,  
with the following schedule:


Monday: Web Components
Tuesday: Editing and Selection
Thursday: Service Workers
Friday: HTML, Directory upload, plenary session (overview of everything),  
Any Other Business, …


Thus far we have a clear clash on Thursday, and it is unclear if we can  
resolve it by asking to run two parallel sessions on Tuesday although  
that's something we can consider.


If you have other terrible clashes, please let us know…

chaals, for the chairs.

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

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

[Chaals McCathie Nevile]

On Tue, 22 Mar 2016 04:17:07 +0100, Hayato Ito <hay...@chromium.org> wrote:


Either option is okay to me. I'll attend the meeting from Tokyo.


I'll attend from Europe. Is there a preferred day, and how long do you  
anticipate this being?


Should we be trying to set up a day or so face to face as well? (And while  
we're at it, do people expect to go to TPAC and want to meet there?)


I'm happy to set up e.g. a Doodle.


On Mar 21, 2016 3:17 PM, "Ryosuke Niwa" <rn...@apple.com> wrote:
>
> For people participating from Tokyo and Europe, would you prefer >  
having it in early morning or late evening?


> If so, we can schedule it at UTC 3PM, which is 8AM in bay area, >  
midnight in Tokyo, and 5AM in Europe.


Actually it's 5PM in Europe - much nicer ;)


> Another option is at UTC 7AM, which is 11PM in bay area, 3PM in Tokyo,
and 8AM in Europe.


cheers

Chaals

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

Re: HTML editors meeting

[Chaals McCathie Nevile]

Dear Ms2ger,

On Wed, 16 Mar 2016 09:56:58 +0100, Ms2ger <ms2...@gmail.com> wrote:


Hi Léonie,

Please don't send spam about your HTML fork to this mailing list; we were
promised the WG merge would not cause our time to be wasted with that  
crap.


This message fails to meet the minimum standards required for polite  
discussion.


Please refresh your memory of the group's workmode, including expected  
standards of behaviour.


cheers

Chaals (as co-chair).


Thanks
Ms2ger

On Tue, Mar 15, 2016 at 11:39 PM, Léonie Watson <t...@tink.uk> wrote:


Hello,

There will be an HTML editors meeting on 10 - 11 May 2016, at Microsoft  
in

Redmond. Info here:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/10-11mayHTML.md

If you are interested in joining the HTML editorial team, we would like  
to

hear from you. Whilst anybody can submit a PR proposing a change to the
HTML
spec, the editorial team is responsible for reviewing PRs and merging  
them

into the spec when they are ready.

Léonie.

--
@LeonieWatson tink.uk Carpe diem.










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

Re: Meeting for selection API at TPAC?

[Chaals McCathie Nevile]

On Wed, 16 Mar 2016 16:42:07 +0100, Ryosuke Niwa <rn...@apple.com> wrote:


Thanks for the rely.

Léonie & Chaals, could we allocate a time slot to discuss selection?


Sure. Any preferences for minimising clashes? How long do you think you  
need?


cheers

Chaals


On Mar 15, 2016, at 8:33 PM, Yoshifumi Inoue <yo...@google.com> wrote:

Sorry for late response.

I would like to discuss following topics:
1. Selection for Shadow DOM
2. Multiple Range support
3. Resolution of open issues towards FPWD

- yosi

2016年3月15日(火) 9:21 Ryosuke Niwa <rn...@apple.com  
<mailto:rn...@apple.com>>:

Hi all,

Is there any interest in discussing selection API at TPAC?

There are 32 open issues on Github at the moment:
https://github.com/w3c/selection-api/issues  
<https://github.com/w3c/selection-api/issues>


- R. Niwa







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

Re: HTML5's Offline-first Council of Trent

[Chaals McCathie Nevile]

The chairs and various individuals requested that Mr Maher use a tone  
acceptable in this group.


This email once again fails to meet the minimum standards of politeness  
and constructive behaviour for this group.


Mr Maher has been removed from the mailing list.

for the chairs

chaals

On Fri, 18 Mar 2016 04:52:27 +0100, Richard Maher <mahe...@googlemail.com>
wrote:


Nick, while we're waiting for Léonie to lecture you on
participation-criteria,  etiquette, and social competence, let me call on
the late, great, Rodney Dangerfield to proxy my response: -

*Judge Smails*: You have worn out your welcome, sir!
*Czervik*: Is that so? Who made you Pope of this dump?
*Judge Smails*: Bushwood...a "dump"? Well, I'll guarantee you'll never  
be a

member here!
*Czervik*: Are you kidding? You think I'd join this crummy "snobatorium"?
Why, this whole place sucks!

Now that I think about it I haven't come across a black face here yet,  
very

few females, and not many Jewish names. Maybe it's still "too soon" for
Reformation references in the W3C Country Club? (BTW. On the FTF-jolly
stakes the IETF Club kicks your arse with Honolulu and Yokohama versus  
your

Sapporo and Lisbon.)


Fresh start? If you make a good case, without calling the w3c a mafia,

people might actually engage this more seriously.

Rest assured, I am pulling out of these forums. (I'm just happy to know
that a softer gentler place continues to exist somewhere)

I've found someone who has more credibility and form here and is willing  
to
take the idea forward. Background GeoLocation was a massive issue before  
I

pinned my colours too it and is too important to the HTML5 Web App future
to be tarnished by collateral bigotry and prejudice.

But before I go, why do you all look and sound the same?

On Thu, Mar 17, 2016 at 8:49 PM, Nick Dugger <nick.dugg...@gmail.com>  
wrote:



Listen, you may not be here to make friends, but if you want to incite
change, you might try playing nicely. If you just want results, you'll  
have

greater success without your sarcasm and superiority complex.

Fresh start? If you make a good case, without calling the w3c a mafia,
people might actually engage this more seriously. As of right now, I  
can't

speak for everyone, but I definitely don't like your tone.

Thanks,
Nick Dugger

On Thu, Mar 17, 2016, 1:52 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:


On 2016-03-17 07:12, Richard Maher wrote:
>> An even more powerful (but also ignored possibility) would be
COMBINING the power
>> of the Web and App worlds instead of fighting religious wars ("the  
Web

is great"),
>> where there are no winners, only lost opportunities.
>
> That's what plugins were for wan't it? And I still cry every night  
over

the death of Applets :-(
> (A single mutliplexed (static) TCP/IP full-duplex connection per
user-agent!)

Plugins were deprecated which (IMO) was OK since they had serious
security issues, what's
less satisfactory is removing features without consider some kind of
reasonable replacement.

Several other somewhat related features are currently also subject to
removal/deprecation.


>> It gets worse...if you are the Web tech leader then you are  
apparently

free taking
>> this "shortcut" (some people would rather characterize this as an
intelligent use
>> of available resources and competences), and get away with it as  
well:

>> https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
>
> C'mon Anders, do you blame them?

Well, Google more or less wrote the "Grand Plan" and now they are
defecting from it,
while leaving everybody else with the old (non-working) plan and
_severely_disadvantaged_.


> Faced with the intractability, self-interest, and narcissism
surrounding
 > the IOC^h^h^hW3C Gordian knot, are you really surprised that   
someone

owning
 > the implementation will pull out their sword and opt for results  
over

process?

I (naively) thought that maybe _somebody_else_ (with more influence  
than a
non-member like me), would be interested in taking a closer look at  
this
powerful capability.  I only seek a constructive discussion on what to  
do

now.

Anders

>
>
> On Thu, Mar 17, 2016 at 1:34 PM, Anders Rundgren <
anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
wrote:
>
> On 2016-03-17 06:00, Richard Maher wrote:
>
> Hi Patrick (Congratulations on today) Technical Point  
follows: -

>
> On a merit-based resource allocation basis, the two most
fundamental, essential,
>
> > and absolutely necessary HTML5 Web-App feature enhancements  
are: -

>
>
> 1) Background GPS device/user tracking support
> 2) Push API 1:M broadcast capability
>
> These are enabling technologies that will catapult HTML5 Web
Apps

Meeting at TPAC - need to plan space.

[Chaals McCathie Nevile]

Dear all,

as you probably know, the W3C will hold its Technical Plenary meeting this  
year in Lisbon, September 19-23.


Rather than meet for several days in plenary, with an hour or two for any  
given topic we are considering an approach that gives more focused time to  
a few important areas of work.


We propose people ask for time to work on a particular topic - an hour,  
half a day, a day, and we'll have a look at how many people would like to  
attend each piece.


If there are other topics you don't want to clash with, e.g. because of  
significant overlap, please say so.


We will have to reserve the physical spaces by the end of this month,  
which means while we might be able to shuffle individual meetings a bit,  
we need to know pretty soon what sort of meetings we should be trying to  
accommodate.


We anticipate having a plenary session on the final day, which will mostly  
be a quick wrap on what happened for each group that met, and a quick  
run-down of all the other work we have - much as webapps has traditionally  
done at the *start* of its TPAC meetings in the past.


As well as feedback on what meetings you think you will need, we of course  
appreciate feedback on the plan itself.


As a reminder, we can organise meetings on topics throughout the year,  
although we try to give at *least* 8 weeks notice so people can plan  
ahead. Feel free to contact the chairs or team contacts and ask for help  
organising a meeting. It's not that hard, but getting the basics right  
helps everyone.


cheers

Chaals (for the chairs)

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

TPAC 2016 - meetings

[Chaals McCathie Nevile]

Dear all,

as you probably know, the W3C will hold its Technical Plenary meeting this  
year in Lisbon, September 19-23.


Rather than meet for several days in plenary, with an hour or two for any  
given topic we are considering an approach that gives more focused time to  
a few important areas of work.


We propose people ask for time to work on a particular area, for example  
"a day for editing and UI events", or "2 hours for File APIs".


If there are other topics you don't want to clash with, e.g. because of  
significant overlap, please say so.


We will have to reserve the physical spaces by the end of March, which  
means while we might be able to shuffle individual meetings a bit, we need  
to know pretty soon what sort of meetings we should be trying to  
accommodate.


We anticipate having a plenary session as some part of the final day,  
which will mostly be a quick wrap on what happened for each group that  
met, and a quick run-down of all the other work we have - much as webapps  
has traditionally done at the *start* of its TPAC meetings in the past.


As well as feedback on what meetings you think you will need, we of course  
appreciate feedback on the plan itself.


cheers

Chaals, for the chairs

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

Re: [clipboard] Sanitizing HTML content for security/privacy on copy or paste?

[Chaals McCathie Nevile]

On Tue, 09 Feb 2016 12:39:33 +0100, Hallvord Reiar Michaelsen Steen  
 wrote:



Hi,
some discussion of how browsers can try to safeguard security/privacy
while copying/pasting HTML got tangled into the "remove dangerous
formats from mandatory data types" thread [1]. I think it will be
easier to follow with a separate thread.


See also discussions on this in webappsec, with threads starting from
http://www.w3.org/mid/56b8565e.4080...@mozilla.com a few days ago, and
https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0113.html  
from January.


cheers


Context: we're talking copy from any normal public or local web page,
to paste formatted text into an online rich text editor. The questions
are about the code the UA itself would insert into the rich text
editor if no script processing took place - the source code you expose
via clipboardData.getData('text/html') may be handled differently.

So - implementors: do you do any of the following currently, and does
it happen when content is written to the clipboard (copy) or read
(paste)? Do you care if it's a cross-site paste or a same-origin
paste?

* Change IMG src to inline images as data: URLs?
* If yes, for all images or just local ones?
* Change link HREFs to remove potential embedded session IDs?
* Remove javascript: URLs from the code?
* Remove event listeners from the code?
* Inline external stylesheets
* Remove SCRIPT elements
* Any other special precautions or processing I haven't thought of?

(I know some of these would be somewhat odd or weird to do - just  
checking..)


(Also, this is not quite in scope for my spec, but I keep being asked
to figure it out.. ;))
-Hallvord R

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





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

[service worker] f2f meeting notes, next meeting details

[Chaals McCathie Nevile]

Hi folks,

for those who are wondering, the last face to face meeting created an  
agenda, as a github issue:  
https://github.com/slightlyoff/ServiceWorker/issues/806 and then just  
updated issues as they went. The relevant sisues are linked from teh  
agenda, so you can look for updates from around January 26, but as far as  
I am aware there are no actual notes available from the discussion :(


There will be another face to face meeting to discuss service workers,  
hosted by Microsoft in Seattle or Redmond, on 11-12 April. Right now there  
is a stub page for the meeting:  
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/11-12aprSW.md


To register for the meeting, or request agenda or remote attendance please  
make a pull request on that page or in reply to this thread on the email  
list.


cheers

Chaals

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

Art steps down - thank you for everything

[Chaals McCathie Nevile]

Hi folks,

as you may have noticed, Art has resigned as a co-chair of the Web  
Platform group. He began chairing the Web Application Formats group about  
a decade ago, became the leading co-chair when it merged with Web APIs to  
become the Web Apps working group, and was instrumental in making the  
transition from Web Apps to the Web Platform Group. (He also chaired  
various other W3C groups in that time).


I've been very privileged to work with Art on the webapps group for so  
many years - as many of you know, without him it would have been a much  
poorer group, and run much less smoothly. He did a great deal of work for  
the group throughout his time as co-chair, efficiently, reliably, and  
quietly.


Now we are three co-chairs, we will work between us to fill Art's shoes.  
It won't be easy.


Thanks Art for everything you've done for the group for so long.

Good luck, and I hope to see you around.

Chaals

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

Service Workers meeting, 11-12 April in Seattle

[Chaals McCathie Nevile]

Hi all,

there will be a meeting to work on Service Workers, scheduled for 11-12  
April. Microsoft have kindly agreed to host it in Seattle (or thereabouts).


An initial webpage for the meeting is in our github repo:  
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/11-12aprSW.md


If you hope or expect to attend, whether in person or remotely, please add  
your name to the page via a Pull Request, or ask us to do so.


cheers

Chaals - on behalf of the chairs

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

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

[Chaals McCathie Nevile]

On Wed, 06 Jan 2016 11:59:55 +0100, 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 (河内 隆仁)  


>
> Is there any option to attend this remotely (telcon or video  
conference)?

>
> 2015年12月9日(水) 10:26 Ryosuke Niwa :

[...]

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



On my task list this week.

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

Re: time at TPAC other than Wednesday?

[Chaals McCathie Nevile]

On Sat, 09 Jan 2016 23:20:27 +0300, Ryosuke Niwa <rn...@apple.com> wrote:



On Jan 8, 2016, at 7:12 PM, Johannes Wilm <johan...@fiduswriter.org>  
wrote:


On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin <gl...@microsoft.com>  
wrote:

Hello Johannes,

 I was the one to organize the meeting. To make things clear, this was  
an ad hoc meeting with the intent for the browsers to resolve any  
ambiguities and questions on beforeInput spec, which we did. This was  
the reason I invited representatives from each browser only.




In so far as to clarify the questions you had at the last meeting that  
you needed to resolve with your individual teams, that you had indeed  
announced at the meeting that you would talk about --- I think that is  
fair enough.


I am not 100% familiar with all processes of the W3C, but from what I  
can tell, I don't think you can treat it as having been a F2F meeting  
of this taskforce, but you can say that you had some informal talks  
with your and the other teams about this and now you come back to the  
taskforce with a proposal of how to resolve it.


Similarly, among JS editor developers we have been discussing  
informally about priorities and how we would like things to work. But  
those are informal meetings that cannot override the taskforce meetings.


Nobody said our F2F was of the task force.

Let me be blunt and say this.  I don't remember who nominated you to be  
the editor of all these documents and who approved it.  If you want to  
talk about the process, I'd like to start from there.


The chairs did. As per the W3C Process.

Cheers

Chaals

To your question about removing ContentEditable=”true”. The idea is  
consolidate multiple documents into a single editing specification  
document. We wanted to remove ContentEditable=”true” because it had no  
content there. So resolutions on CE=true from previous meetings remain  
unchanged. There is no point on having empty document floating on the  
web. So yeah, we wanted to remove the draft that has no content. We  
will merge Input Events and other ContentEditable specs into a single  
spec. We didn’t really have any discussions on execCommands spec.




Yes, I don't think that part can reasonably be said to have been part  
of something you could resolve in a closed door, unannounced meeting  
among only browser vendors.


Both the treatment of the various documents and especially  
contentEditable=True has been very controversial in this taskforce in  
the past, and I don't think you can just set aside all processes and  
consensus methods to change this.


So with all due respect, I don't think you can just delete it like  
that. Just as I cannot just delete part of the UI events spec because I  
have had a meeting with some people from TinyMCE and CKEditor and we  
decided we didn't like that part.


If the task force comes to a consensus that the document was useful,  
then we can just restore it.  The change was purely editorial in the  
nature.  First off, I don't remember when we agreed that we needed to  
have a separate spec for contenteditable=true separate from Aryeh's  
document.  If you thought the consensus of the last Paris F2F was to do  
that, then you either misunderstood the meeting's conclusion or I didn't  
object in time.


As far as I'm concerned, this is about removing an empty document the  
task force never agreed to add in the first place.


- R. Niwa





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

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

[Chaals McCathie Nevile]

On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile  
<cha...@yandex-team.ru> 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!


cheers

Chaals


If you plan to attend, please add your name to the meeting page:
<https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md>  
(or let me know directly by email and I will add you).


Note that there are two attendee lists currently - those who hope to  
attend, and those who have made a firm commitment. I currently believe  
that Domenic, Travis, Elliott and I are confirmed for the 25th, so  
listed those people already


cheers

Chaals
For the chairs



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

Custom Elements meeting will be 25th Jan (not 29th)

[Chaals McCathie Nevile]

Dear all,

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.


If you plan to attend, please add your name to the meeting page:
<https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md>  
(or let me know directly by email and I will add you).


Note that there are two attendee lists currently - those who hope to  
attend, and those who have made a firm commitment. I currently believe  
that Domenic, Travis, Elliott and I are confirmed for the 25th, so listed  
those people already


cheers

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

Re: Meeting date, january

[Chaals McCathie Nevile]

On Tue, 01 Dec 2015 00:15:23 +1000, Léonie Watson  
<lwat...@paciellogroup.com> wrote:



From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru]
Sent: 26 November 2015 01:55
it appears that there are some people may not be able to attend a  
meeting

on the 29th - although Apple has generously offered to host that day.

Is there anyone who would only be able to attend if we moved the meeting
to the 25th?
Conversely, would that shift cause problems for anyone (e.g. bought
inflexible tickets, another clash, …)

By default, we won't move the meeting, but if there are a number of  
people affected and it makes sense, we could do so. If so, I'd like to

make that decision early next week.


Either date is likely to be ok for me. A decision would be helpful in  
knowing this for certain though.


Yes, likewise for me. Anne, Olli specifically called you out as someone we  
should ask. I am assuming most people are OK either way, having heard no  
loud screaming except for Elliot...


cheers

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

Meeting date, january

[Chaals McCathie Nevile]

Hi,

it appears that there are some people may not be able to attend a meeting  
on the 29th - although Apple has generously offered to host that day.


Is there anyone who would only be able to attend if we moved the meeting  
to the 25th?
Conversely, would that shift cause problems for anyone (e.g. bought  
inflexible tickets, another clash, …)


By default, we won't move the meeting, but if there are a number of people  
affected and it makes sense, we could do so. If so, I'd like to make that  
decision early next week.


cheers

Chaals

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

No meeting in december Re: [web components] proposed meetings: 15 dec / 29 jan

[Chaals McCathie Nevile]

OK, just to formally close the loop we will not have a meeting in December.

cheers

On Mon, 16 Nov 2015 05:12:55 +0100, Hayato Ito  wrote:


Thank you, Ryosuke. I'm fine not to have a meeting in Dec.

Let me add a link to GitHub issue(s) for each item:


1. Clarify focus navigation


I think the following two GitHub issues are good starting points to know
the current status.
https://github.com/w3c/webcomponents/issues/103
https://github.com/w3c/webcomponents/issues/126


2. Clarify selection behavior (at least make it interoperable to JS)


https://github.com/w3c/webcomponents/issues/79
I think this is the hardest issue for us.


3. Decide on the style cascading order


https://github.com/w3c/webcomponents/issues/316
I think everyone can agree on Proposal 1, as I commented in the issue.


4. style inheritance


https://github.com/w3c/webcomponents/issues/314
I've already closed this issue. Please feel free to re-open the issue to
restart the discussion.


On Sat, Nov 14, 2015 at 1:31 AM Ryosuke Niwa  wrote:



> On Nov 13, 2015, at 8:08 AM, Anne van Kesteren   
wrote:

>
> On Fri, Nov 13, 2015 at 4:57 PM, Ryosuke Niwa  wrote:
>> What outstanding problems are you thinking of?
>
> Again, not I, but Hayato Ito raised these. I just happen to agree. He
> emailed this list on November 2:
>
>
https://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0149.html

Of the four issues listed there:

> On Nov 1, 2015, at 7:52 PM, Hayato Ito  wrote:
>
> > 1. Clarify focus navigation
> > 2. Clarify selection behavior (at least make it interoperable to JS)
> > 3. Decide on the style cascading order
> > 4. style inheritance  
(https://github.com/w3c/webcomponents/issues/314)


I'd like to resolve 3 and 4 ASAP since we're pretty close.  I don't  
think
we necessarily need an in-person meeting to do that though.  If  
anything,

it's probably more helpful to have discussion over mailing lists so that
each person can spend as much time as needed to understand / come up  
with

examples and proposals.

For 1, we had a rough consensus on how current focus model (in  
particular

focus ordering) should be changed to support shadow DOM during TPAC.
Namely, we would create a new tab index "scope" at both shadow roots as
well as slots, and follow the composed tree order for tab ordering.  I
think someone should document that first.

I just started working on 2 but I probably won't have a time to come up
with a proposal until mid December.


So if you guys can't make it, I don't think we necessarily need a shadow
DOM meeting in December.

- R. Niwa






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

29 Jan? Re: [web components] proposed meetings: 15 dec / 29 jan

[Chaals McCathie Nevile]

Hi folks,

having canceled the proposed december meeting, and with a little less time  
pressure, this is a check that people are still interested in a face to  
face meeting for web components stuff - shadow DOM and custom elements  
both have some currently outstanding issues.


I changed the URL of the github page:

https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/29janWC.md

If you expect to attend, please add your name to that page directly by  
Pull Request, or let me know and I will do so. Ditto for agenda items.


Note that we are looking for a host still.

cheers


On Fri, 13 Nov 2015 11:32:06 +0100, Chaals McCathie Nevile  
<cha...@yandex-team.ru> wrote:




https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/15decWC.md
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16janWC.md

Offers of hosting will be very gratefully received. We need a room for  
about 20 people, electricity, wifi, coffee/tea/snacks, lunch, and a  
speaker/mic setup for connecting remote participants.


And of course agenda…

cheers




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

[web components] proposed meetings: 15 dec / 29 jan

[Chaals McCathie Nevile]

Hi folks,

in the poll we ran, there were only about 10 responses, and the preference  
split was pretty even. I also forgot to make a place where people could  
provide their name :(


Our proposal is to look for a host on 15 December on the West Coast, for a  
meeting primarily focused on Shadow DOM, and another on 29 January in the  
Bay area for one around Custom Elements. The agenda can be adjusted to  
take account of people who are unable to travel for both of these, moving  
items from one to the other if necessary, since *many* but *not all*  
people are interested in both topics.


If people are seriously uncomfortable with this proposal, and want to  
argue for an alternative, please speak up - and if you're planning to  
attend either, please reply to this thread, privately to me, or add your  
name to the meeting pages with a Pull Request:


https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/15decWC.md
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16janWC.md

Offers of hosting will be very gratefully received. We need a room for  
about 20 people, electricity, wifi, coffee/tea/snacks, lunch, and a  
speaker/mic setup for connecting remote participants.


And of course agenda…

cheers

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

Vote: f2f Meeting(s) for components

[Chaals McCathie Nevile]

Hi,

I set up a ballot:

https://modernballots.com/elections/agkedja2/vote/

There are a few kinds of option - single day or two, two days split or  
co-located, and spread across what seemed the most easily available dates  
- 15/16 december, 24/5 and 29/30 jan.


You can write in another option if these don't work for you - and feel  
free to reply here and explain constraints.


The voting lets you give from 1 to 5 stars to each option - the ones you  
like most should get 5. You can rank choices equally.


Since the december dates in particular are very tight for people to plan  
travel, please reply asap.


cheers

Chaals

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

Re: [pointerlock] Oct 2015 Pointer Lock Status

[Chaals McCathie Nevile]

On Sat, 24 Oct 2015 05:57:06 +0900, Vincent Scheib <sch...@google.com>
wrote:


Pointer lock reached Candidate Recommendation in Dec 2013. [CR]

Implementation status:

[Looks like enough that if the implementations work - i.e. do the same
things - we are ready]


Testharness tests are not currently able to test the core Pointer Lock
features, which would require user gesures (mouse clicks) and  
synthesizing mouse movement. No progress is seen here for this

specification, but the challenge is present for several.

[...]
Yes. You are *not* required to use testharness tests. While it would be
good to get the automation of stuff like this landed, it is perfectly
reaonable to write some interop tests in the form "load this page and do
this and then this and then this, and determine whether you see this or
that". A set of tests of this nature that collectively cover the spec's  
features should be enough. And it is a Good Thing™ to use content found in  
the wild as the basis for this.


We are required to show that implementors reading the spec will get it
right, and that there is a reasonably broad interest in implementing.


Specification:
  https://w3c.github.io/pointerlock/
  Minor changes in last year (small IDL fixes, typos/grammar):
https://github.com/w3c/pointerlock/commits/gh-pages
  Feature Requests page moved to github:
https://github.com/w3c/pointerlock/blob/gh-pages/FeatureRequests.md


Next Steps:

In the Candidate Recommendation Call for Comments [CR-CfC] Arthur Barstow
proposed exit criteria:
"""
During the Candidate Recommendation period, which ends @T+3months, the
WG will complete its test suite. Before this specification exits
Candidate Recommendation, two or more independent implementations must
pass each test, although no single implementation must pass each test.
The group will also create an Implementation Report.
"""

Robust cross browser testing, as mentioned above, is challenging and I
question if browser vendors will implement sufficient support, e.g. via  
Web Driver or other means. This leaves a discussion of how much testing

is practical vs implicit demonstration of implementation consistency
via application use.


As noted above, we "only" need to show that the features defined in the
spec work right when implemented in the wild.

Good practice would suggest that this includes developers using them
"right" - if the spec isn't clear enough for authors to do this, we
still have a problem.


Feature use exists in typically smaller projects. For example
http://a-way-to-go.com/.



Working group questions:
  * How much testing is practically required to move to Proposed?
  * Ready for 'wider' review?


If it is implemented in multiple browsers, is used by websites "in the
wild", and you can show that it has been looked over to see if concerns
were indentified relating to accessibility, API design,
internationalisation, privacy, and security, we probably have sufficiently
wide review to request Proposed Rec.

A lot of that is already reflected in the spec. The cases of accessibility  
that strike me as relevant are being able to generate synthetic mouse  
events, e.g. with keyboard, escape pointer lock, and making sure that  
users understand when they have been put into it - especially for users  
with cognitive disabilities.


All these issues are addressed, but I would feel more comfortable  
requesting PR *knowing* that e.g. the APA group who do accessibility  
review have had a look at it. I'm happy to arrange that if it hasn't  
already happened. (I'm flying and not in a position to do the archaeology  
support for my memory).


cheers

Chaals

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

Re: [pointerlock] Oct 2015 Pointer Lock Status

[Chaals McCathie Nevile]

On Mon, 02 Nov 2015 05:08:10 +0900, Vincent Scheib <sch...@google.com>  
wrote:



On Sun, Nov 1, 2015 at 3:42 AM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:


Yes. You are *not* required to use testharness tests. While it would be
good to get the automation of stuff like this landed, it is perfectly
reaonable to write some interop tests in the form "load this page and do
this and then this and then this, and determine whether you see this or
that". A set of tests of this nature that collectively cover the spec's
features should be enough. And it is a Good Thing™ to use content found  
in the wild as the basis for this.


Thanks for clarifying. Basic usage is demonstrated in the wild but some
edge cases should have clear demonstration in the test suite. I will
generate those as other project priorities allow (and would of course
review any from others).


OK. We also don't want to let perfect be the enemy of good. If things are  
truly edge cases it might be worth letting them wait for a revision unless  
they are reasonably straightforward.



If it is implemented in multiple browsers, is used by websites "in the
wild", and you can show that it has been looked over to see if concerns
were indentified relating to accessibility, API design,
internationalisation, privacy, and security, we probably have  
sufficiently wide review to request Proposed Rec.


A lot of that is already reflected in the spec. The cases of  
accessibility that strike me as relevant are being able to generate

synthetic mouse events, e.g. with keyboard, escape pointer lock,
and making sure that users understand when they have been put into
it - especially for users with cognitive disabilities.


Thanks. Accessibility should be addressed more explicitly in the
specification. I will reach out to the APA and solicit suggestions.


OK, thanks. You might as well prime them with the things I called out  
above…


I guess the other thing is how you deal with Zoom, but I guess the short  
answer is "there are bigger things on screen". In fact zoom for  
accessibility is probably a use case that this spec can help, although  
maybe the mouse event stuff breaks that. I'll have a think in the morning  
if I am lucky.


cheers

Chaals

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

Re: [Web Components] proposing a f2f...

[Chaals McCathie Nevile]

On Fri, 30 Oct 2015 16:21:43 +0900, Domenic Denicola <d...@domenic.me> wrote:

Maybe we could have separate meetings (or days) for shadow DOM and for  
custom elements? I am concerned that with this growing list of shadow  
DOM topics we will not have time for custom elements, which would be  
disappointing for those of us traveling specifically for that.


It seems we might have enough work to make this a good idea.

As for dates: If we go for late January, the 26th through 28th collide  
with TC39, but the 25th or 29th would be ideal for me, since it would  
allow travel consolidation. December also works, with no conflicts.


If we go for January, this seems like a good week. I presume Travis will  
be in Australia earlier at the TAG meeting, and I'll be there too.


For people traveling to both, it seems a big ask to split the week.

Would people prefer to have a two-day meeting covering saturday or sunday,  
have one meeting in december and one in january (preferences for which is  
which?), try to have one very long day (personally I strongly advise not  
trying that, but if it's what we get I'll work with it)?


I'll set up a doodle when I get to sit down for a minute, hopefully  
tomorrow. Feel free to add to the thread in the meantime.


cheers


From: "Takayoshi Kochi (河内 隆仁)" <ko...@google.com>
Sent: Oct 30, 2015 2:52 PM
To: Ryosuke Niwa
Cc: Cynthia Shelly; Chris Wilson; Travis Leithead; Dimitri Glazkov; Olli  
Pettay; Chaals McCathie Nevile; public-webapps WG

Subject: Re: [Web Components] proposing a f2f...



On Thu, Oct 29, 2015 at 3:04 PM, Ryosuke Niwa  
<rn...@apple.com<mailto:rn...@apple.com>> wrote:


On Oct 29, 2015, at 9:47 AM, Chris Wilson  
<cwi...@google.com<mailto:cwi...@google.com>> wrote:


Or host in Seattle.  :)

On Thu, Oct 29, 2015 at 9:20 AM, Travis Leithead  
<travis.leith...@microsoft.com<mailto:travis.leith...@microsoft.com>>  
wrote:
I would prefer a late January date so as to allow me to arrange  
travel. Otherwise, I’m happy to attend remotely anytime.


I'm okay with either option with a slight preference on having it  
earlier since we didn't have much time discussing custom elements at  
TPAC.


I would like to resolve the following issues for shadow DOM:
1. Clarify focus navigation
2. Clarify selection behavior (at least make it interoperable to JS)
3. Decide on the style cascading order


In addition, I'd propose

+ Decide on style inheritance  
(https://github.com/w3c/webcomponents/issues/314)



And the following issues for custom elements:
4. Construction model. Do we do sync / almost-sync / dance?
5. Do we support upgrading?  If we do, how?

Any other issues?

- R. Niwa





--
Takayoshi Kochi



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

[Web Components] proposing a f2f...

[Chaals McCathie Nevile]

Hi,

it would be good to have a face to face meeting, and wrap up loose ends.  
At the TPAC meeting times suggested were December and late January.


If people want to do it soon, we should probably aim for December, which  
means finding a date and host. The assumption is that we will be meeting  
around the Bay Area...


I would propose a day between 10 and 14 December as a starting point  
(based on my own availability - as one of the few people traveling  
internationally).


If you cannot make a date in that window, or think we need a meeting  
later, and want to make a counter suggestion, please do so. If you can  
make it, please let me know - I am trying to get a quick sense before  
calling for a host and agreement on a particular date…


I hope we can get people settling a rough time-frame very fast, to provide  
adequate notice for people who need to organise travel.


cheers

Chaals

close action-759

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

Re: Making progress with items in Web Platform Re: App-to-App interaction APIs - one more time, with feeling

[Chaals McCathie Nevile]

Offlist.

On Sat, 17 Oct 2015 19:36:54 +0200, Anders Rundgren
<anders.rundgren@gmail.com> wrote:


On 2015-10-17 17:58, Chaals McCathie Nevile wrote:


Regarding App-to-App interaction I'm personally mainly into the
Web-to-Native variant.


As I already pointed out to Daniel, this stuff is not in the current  
scope

of the group, and you should work on it in the context of e.g. the Web
Incubator Community Group, where it is relevant to their scope.


As I wrote, this particular feature is already in Chrome and is now  
being implemented by Microsoft and Mozilla.


That doesn't make it part of the current scope of the group.

It is therefore off-topic, and having been asked to take the discussion
where it is in scope, please refrain from continuing it on webapps.

cheers

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

Making progress with items in Web Platform Re: App-to-App interaction APIs - one more time, with feeling

[Chaals McCathie Nevile]

On Sat, 17 Oct 2015 16:19:17 +0200, Anders Rundgren  
<anders.rundgren@gmail.com> wrote:



On 2015-10-16 18:00, Aymeric Vitte wrote:

Well, since I was on the list, I took the liberty of commenting a bit on  
this.


Please work on being more civil and constructive when you do. (Aymeric,  
that could apply to you to - and in fact the requirement to behave  
courteously is a general one for this list and others of the Web Platform  
WG).


Unless you work for a browser vendor or is generally "recognized" for  
some specialty, nothing seems to be of enough interest to even get

briefly evaluated.


I think you are misinterpreting your personal experience.

It is true that if you can demonstrate likely uptake on a broad scale, you  
will get a lot more enthusiasm than if you have an idea that you just  
think would help you. Browsers are among those who, by their nature, are  
more readily able to offer broad uptake. Major content producers likewise  
can do so, or those who make stuff that has a broad developer or user  
community involved.


An example of the latter are the developers of editing software. Most of  
those are very small, but they have a very large user community.  
Consequently, they have managed to engage the browser development  
community, and currently it seems that the discussions about rich-text  
editing in HTML, while complex and likely to take a long time, are very  
much worthwhile.


Meanwhile, even proposals I make as both a chair and the representative of  
a browser vendor (albeit a relatively unknown one outside Russia) stand or  
fall on the merits which include not only technical soundness but apparent  
likelihood of adoption on the Web.


Regarding App-to-App interaction I'm personally mainly into the  
Web-to-Native variant.


As I already pointed out to Daniel, this stuff is not in the current scope  
of the group, and you should work on it in the context of e.g. the Web  
Incubator Community Group, where it is relevant to their scope.


chaals, for the chairs.

Here the browser vendors have reportedly [1,2] decided to implement  
Google's
Native Messaging API "as is" without any discussions in related W3C  
forums,
something they will surely regret because it has a long list of  
shortcomings,

ranging from a difficult deployment scheme to limited functionality and
performance issues, not to mention a highly deficient security model:
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html

That the browsers vendors have gotten major push-backs after removing
their previous extension schemes (NPAPI, ActiveX) is obvious, but that
doesn't motivate rushing into crude workarounds:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/

Anders

1] https://wiki.mozilla.org/WebExtensions#Additional_APIs
2]  
http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/



Ccing the authors of [1], [2] and [3] if there is still an interest.



at this stage we don't have a deliverable for this work - i.e. the W3C
members haven't approved doing something like this in Web Platform  
working

group. Given that people repeatedly attempt to do it, I think the
conversation is worth having. Personally I think this is something the
Web needs


Indeed, that will be more than time to do so, but the current view of
the main actors or past specs seems a kind of narrowed and not very
imaginative/innovative, I don't think you should close the web intents
task force [5] but restart it on new bases.

This approach [1] and [2] looks quite good, simple and can cover all  
cases.


I don't know if we can call it a Web Component really for all cases but
let's call it as such.

In [2] examples the Bio component could be extracted to be passed to the
editor for example and/or could be shared on fb, and idem from fb be
edited, shared, etc

Or let's imagine that I am a 0 in web programming and even Web
Components are too complicate for me, I put an empty Google map and
edit/customize it via a Google map editor, there is [3] maybe too but
anyway the use cases are legions.

That's incredible that nobody can see this and that [1] did not get any
echo (this comment I especially dedicate it to some people that will
recognize themselves about some inappropriate comments, not to say more,
they made regarding the subject related to the last paragraph of this  
post).


The Intent service would then be a visible or a silent Web Component
discussing with the Intent client using postMessage.

Maybe the process could  be instanciated with something specific in href
(as suggested in [2] again) but an Intent object still looks mandatory.

But in case of visible Intent service, the pop-up style looks very ugly
and old, something should be modified so it seems to appear in the
calling page, then the Intent service needs to have the possibility to
become invisible (after login for example).

I don't see any te

Re: App-to-App interaction APIs - one more time, with feeling

[Chaals McCathie Nevile]

TL;DR: It's worth pursuing, but chat in WICG first to get a proposal that  
Web Platform WG will formally take up.


On Thu, 15 Oct 2015 19:26:11 +0200, Daniel Buchner
 wrote:

After publishing the post, Google has reached out and we’ve been  
discussing options for solving this – would you like those discussions  
to be on the ML, or >back-channeled?




Hi Daniel,

at this stage we don't have a deliverable for this work - i.e. the W3C
members haven't approved doing something like this in Web Platform working
group. Given that people repeatedly attempt to do it, I think the
conversation is worth having. Personally I think this is something the Web  
needs, so one day we are going to have to get it done. On both counts, I  
encourage you to continue the conversations… But…


Since it is currently out of scope for this group, the normal path to get
it in scope would be to discuss it within the Web Incubator Community
Group. That way we don't lose important discussion by having it all
back-chanelled in private email.

That discussion should lead to a proposal for this group - use cases,
requirements, design considerations - initial thoughts about security,
privacy, internationalisation, accessibility, consistency with other Web
APIs, performance, …), perhaps a rough outline of a spec. You would be
aiming for First Public Working Draft, not Candidate Recommendation, so
having a pile of issues and bugs isn't a problem.

If that happens the next step is to change our charter.

That is an administrative thing that takes a few weeks (largely to ensure
we get the IPR protection W3C standards can enjoy, which happens because
we spend the time to do the admin with legal processes) if there is some
broad-based support. If we are at that point, the chairs and W3C staff
will handle most of the admin, beyond asking the Working Goup if they
agree we should add this to our charter.

And then we do the github magic to make a formal W3C Web Platform Working  
Group draft (usually takes me ages, so I'll ask someone smarter who will  
take a few minutes), and we're on our way to making a W3C standard…


…after that, it's just a matter of sorting out the issues, bugs,  
implementation, and then we're done :)


Until we look at the things we decided not to include in the first  
version, so we could ship faster…


cheers


- Daniel






From: Samsung account [mailto:bnw6...@gmail.com]


Sent: Thursday, October 15, 2015 9:26 AM

To: Arthur Barstow 

Cc: Daniel Buchner ; public-webapps@w3.org

Subject: Re: App-to-App interaction APIs - one more time, with feeling








2015/10/15 下午11:58於 "Arthur Barstow" 寫道：






On 10/14/15 12:33 PM, Daniel Buchner wrote:











Hey WebAppers,






Just ran into this dragon for the 1,326^th time, so thought I would do  
a write-up to rekindle >discussion on this important area of developer  
need the platform currently fails to address:


http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/.  
We have existing APIs/specs >that get relatively close, and my first  
instinct would be to leverage those and extend their >capabilities to  
cover the broader family of use-cases highlighted

in the post.






I welcome your ideas, feedback, and commentary,











Hi Daniel,






In case you haven't done so already, perhaps the Web Platform  
Incubation Group's Discourse service >would be a "better" place to  
discuss your proposal ?







--



AB
















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

Repos and specs Re: [admin] Web Platform WG is the new WebApps

[Chaals McCathie Nevile]

On Mon, 12 Oct 2015 18:48:31 +0200, Johannes Wilm  
<johan...@fiduswriter.org> wrote:



Hey,
thanks for the info.

As I understand it, this has no practical impact on the editing  
taskforce and these are more suggestions for future task forces, right?


That is how I understand it too.

As for separate repositories: We have changed the number and names of  
the specs we need numerous times now. If we create and delete a  
repository every time we change the name or >the numbers and types of  
specs, it would have turned into a complete mess.


Yes. I think the point isn't that every document written needs a new repo,  
but that mixing two different things like Web Messaging and  
ContentEditable in the same repo is a bad idea.


Essentially we only have one single work item which is editing. We  
should now now be very far away from being very clear on the names of  
some of at least one the specs (the one >containing beforeEdit/Edit or  
beforeInput/Input), and once that happens, I would be all for moving it  
to it's own repository if we are clear that this these events will also  
be added to old >contentEditable elements, text areas, input fields,  
etc. .
We couldn't do that hitherto because as late as late August it was  
suggested we merge that spec with some of the other specs.


Yeah. We might work out how to split out editing into separate work items,  
but that isn't the highest priority work.


Note that we also haven't worked out properly what to do with HTML, which  
is clearly far too much stuff to have in one repo, beyond noting that "it  
is clearly too big to be a single work item"...


cheers

Chaals






On Mon, Oct 12, 2015 at 6:23 PM, Marcos Caceres <w...@marcosc.com> wrote:





On October 12, 2015 at 8:23:25 AM, Arthur Barstow  
(art.bars...@gmail.com) wrote:

Hi All,

On October 10, the consortium formerly started the Web Platform WG
[Charter] thus terminating WebApps.

My expectation is this change will have little to no impact on any work
started in WebApps. That said, please note the charter indicates
WebApps' less developed specs (f.ex. the Editing specs) need some
"incubation" before they may proceed on the Recommendation track.
However, that was effectively how WebApps operated so I don't see this
as a change - a spec still needs implementation commitments before
advancing to the later Recommendation stages.


For incubation, members are welcomed to bring their specs Web Incubator  
CG:

http://github.com/wicg

The WICG can help members get specs into shape and connect them with  
developers and other implementers. It's a fast, IPR friendly way, to  
get ideas road-tested before formal >>standardization.

The WPWG has its own Github repo [Github] and the group will not use

W3C's wiki. (Only a small number of WebApps' Editors actively use W3C
wiki documents (primarily IDB v2 features, Pointer Lock v2 features,
Gamepad v2 features, and D3E) and I will work with those Editors to  
move

their relevant wiki information to their spec's repo.)


Please please please (please!), don't use a single repository as a  
dumpling ground for spec - it makes it impossible for people to follow  
individual work items, file bugs, etc.. Please use >>separate  
repositories for each work item.


I would suggest maybe making your own organization on Github, and then  
managing your specs through that. Again, see:

http://github.com/wicg







--Johannes Wilm
Fidus Writer
http://www.fiduswriter.org




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

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

[Chaals McCathie Nevile]

I added a note (as a question) to the meeting wiki page:  
https://www.w3.org/wiki/Webapps/October2015Meeting


cheers

On Tue, 29 Sep 2015 11:12:16 +0500, John Daggett   
wrote:



Late Tuesday afternoon would be a good fit for me.

On Tue, Sep 29, 2015 at 8:49 AM, Ryosuke Niwa  wrote:

Hi,



Attending the recent meeting for shadow DOM styling [1] convinced me to  
join CSS WG, and further >>that we need a joint meeting between CSS WG  
and WebApps WG on this topic during TPAC to iron out >>the details.




Can we have a joint meeting (of one or two hours) on Monday (10/26) or  
Tuesday (10/27) for this?




[1] https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting



- R. Niwa












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

Minutes from Components face to face

[Chaals McCathie Nevile]

Hi folks,

Thanks to PLH (Who was a bit quicker than me to publish the work) there  
are combined minutes of nearly everything from the webapps face to face  
meeting at http://www.w3.org/2015/07/21-webapps-minutes.html


Unfortunately, about the only things that got missed were the action items  
and points of agreement which we got to at the end of the meeting :( On  
the other hand, I think a lot of the sense is clear from reading the text  
of the minutes. The general sense is that we don't have an answer to the  
outstanding big problems, but at least we understand the problems and a  
number of possible answers far better.


There were a few people (at least DomenicD, Maciej, Me, Travis) who agreed  
to go away and write up better explanations of certain proposals.


We (happy few - those in the room) also agreed that there seem not to be  
outstanding points of contention for Shadow DOM, and with a bit of work we  
can get it ready to ship (famous last words - famous for being repeated  
later) and work on the next version of it. In particular, the current  
slots proposal seems to have won favour, and an imperative API has been  
postponed.


I owe a big apology to several people who tried to dial into the meeting -  
we almost completely failed to cater for remote participation. That has  
been noted as something we have to get right, and I expect we will not  
fail in the future.


Thanks to all who participated, to Dmitry and Google for logistics, and  
again, my humblest apologies to those who tried but could not participate  
remotely through no fault of theirs.


cheers

Chaals

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

Re: Clipboard API: remove dangerous formats from mandatory data types

[Chaals McCathie Nevile]

On Tue, 28 Jul 2015 08:24:17 -0400, Hallvord Reiar Michaelsen Steen  
hst...@mozilla.com wrote:



On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile 
cha...@yandex-team.ru wrote:


I'm just thinking out loud here, but this problem is similar to one
already faced by email clients, especially those which are web-based...

On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen 
hst...@mozilla.com wrote:

 So PNG, JPG et al go in the support

reading from clipboard list, and the support writing starts out with
text/plain, text/html and text/uri-list - although it would be nice if
CSV was also considered safe enough.



I'm not sure you should directly read image formats from the clipboard,
especially if you don't know how they got there.


What are your concerns exactly? As Wez mentioned we may have to add some
transcoding - but if there's a chunk of binary data labelled as JPEG on  
the clipboard, and the user wants to paste this into her blog editor,

how would we do that if web content shouldn't read image formats from
the clipboard?


Essentially only certain things would be delivered from the clipboard - a  
picture in the desired format, and hopefully a certain amount of metadata.  
But we would be pretty explicit that unexpected stuff may well be dropped  
- and probably *should* in various cases like images


(I think we might actually agree in practice, and be looking for words)

cheers


You shouldn't write stuff there that can be dangerous, but you really
shouldn't read it direct. So maybe what happens is that when stuff gets
written, it goes through a process like painting it onto a canvas, and  
then being scraped back off as coloured pixels and safe metadata.


Indeed, if that's what it takes.. like the addImageFromCanvas()  
suggestion below. Regarding that suggestion you asked:




Is it more than syntactic sugar?



If we allow adding image data as blobs, the normal way with
clipboardData.items.add() it would be just a convenience method. Since
Daniel Cheng has serious concerns and good arguments against allowing  
that, something like addImageFromCanvas() might be a workaround that

would let users put images on the clipboard in a safe way.. If we have
neither, I guess we'll see data:image/jpeg URLs placed on the clipboard
as plain text.
-Hallvord R.



--
Using Opera's mail client: http://www.opera.com/mail/

Re: Clipboard API: remove dangerous formats from mandatory data types

[Chaals McCathie Nevile]

I'm just thinking out loud here, but this problem is similar to one  
already faced by email clients, especially those which are web-based...


On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen  
hst...@mozilla.com wrote:



On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote:

Currently, the Clipboard API [1] mandates support for a number of  
formats.
Unfortunately, we do not believe it is possible to safely support  
writing a

number of formats to the clipboard:
- image/png
- image/jpg, image/jpeg
- image/gif



Hi Daniel,
I've been pondering this a bit and I think a first step is to split the
list of mandatory data types into two: one list for types you must
support reading from the clipboard, and one (smaller) for types you must
support writing to the clipboard. So PNG, JPG et al go in the support
reading from clipboard list, and the support writing starts out with
text/plain, text/html and text/uri-list - although it would be nice if  
CSV was also considered safe enough.


I'm not sure you should directly read image formats from the clipboard,  
especially if you don't know how they got there. You shouldn't write stuff  
there that can be dangerous, but you really shouldn't read it direct. So  
maybe what happens is that when stuff gets written, it goes through a  
process like painting it onto a canvas, and then being scraped back off as  
coloured pixels and safe metadata.


A use case for the latter is the fabled embedded accessibility that  
could have made longdesc obsolete in 1997 - although the more likely use  
case for most people is getting the right geospying in their photo stream,  
and proving to the world that their camera clock flashes like a video  
player from 1987.


So essentially we don't restrict what is in the clipboard, but we do put  
restrictions on what we will take out, and if you want to be well-behaved  
you would follow those restrictions before you put anything there. Can we  
safely implement a clean/dirty flag similar to canvas, to help avoid  
double-sanitizing? Is that worth worrying about?



It would also be good if we could come up with an API for safely writing
images to the clipboard. Just playing:
event.clipboardData.addImageFromCanvas(canvasElm, 'image/png')

Hot or not?


Safely DrawMeA(sheep) is certainly worth pondering. Is it more than  
syntactic sugar?


cheers

--
Using Opera's mail client: http://www.opera.com/mail/

Re: [WebIDL] T[] migration

[chaals]

16.07.2015, 17:59, Anne van Kesteren ann...@annevk.nl:
 On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
 travis.leith...@microsoft.com wrote:
  Should we consider keeping T[] in WebIDL, but having it map to 
 FrozenArray?

 We should just update the relevant specifications.

That seems a rational approach in any event.

But would just abandoning T[] break anything elsewhere? Is there any value in 
having it mapped and deprecated?

cheers

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

Re: Components F2F

[chaals]

Google had offered to host the meeting, and I believe they are on it.

Obviously, offers to share the hosting effort are welcome in general. I haven't 
checked but agree that based on last time 22 might be squeezing it.

cheers

02.07.2015, 09:11, Anne van Kesteren ann...@annevk.nl:
 On Thu, Jul 2, 2015 at 8:56 AM, Ryosuke Niwa rn...@apple.com wrote:
  Is Google hosting this meeting as well? Alternatively, would other browser 
 vendors (e.g. Mozilla) willing to host it this time?

 If we decide quickly it seems I can reserve a room at Mozilla for 18
 people in SF, maybe 22 in MTV. Not sure that's big enough judging from
 last meeting, but I don't have the details.

  I'm supposed to write up a document that summaries what we've agreed thus 
 far. I've been busy with other stuff lately but will try to post it before 
 the meeting.

 Excellent!

 --
 https://annevankesteren.nl/

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

F2F Meeting: Custom Elements, 21 July, Bay Area California

[chaals]

Hello,

this is a preliminary announcement.

There will be a meeting hosted in the Bay Area of California (i.e. between 
San Francisco and San Jose, roughly speaking), focusing on Custom Elements.

A meeting registration page will be available soon, and will be announced.

We will try to provide an accessible working setup for remote participation. We 
will take minutes in webapps' IRC channel irc://irc.w3.org/#webapps in the 
usual way.

cheers

Chaals

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

Registration now open Re: F2F Meeting: Custom Elements, 21 July, Bay Area California

[chaals]

Hi folks,

please register for the meeting: 
https://www.w3.org/2002/09/wbs/42538/WebComponents21July2015/

There is also a meeting page - at this stage still somewhat light on details, 
as we don't yet have too many confirmed: 
https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting

cheers

15.05.2015, 11:44, cha...@yandex-team.ru cha...@yandex-team.ru:
 Hello,

 this is a preliminary announcement.

 There will be a meeting hosted in the Bay Area of California (i.e. between 
 San Francisco and San Jose, roughly speaking), focusing on Custom Elements.

 A meeting registration page will be available soon, and will be announced.

 We will try to provide an accessible working setup for remote participation. 
 We will take minutes in webapps' IRC channel irc://irc.w3.org/#webapps in the 
 usual way.

 cheers

 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: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

[chaals]

12.05.2015, 13:35, Arthur Barstow art.bars...@gmail.com:
 Hi All,

 Thanks for this analysis Xiaoqian.

 Based on the differences, I think moving toward a 2nd edition REC seems
 reasonable.

 Re the next publication step, it seems like the next publication should
 be a (4 week) wide review WD using Process-2014.

 Re what to do with the 1st Edition errata document, rather than put
 changes in that doc, I think it would be more helpful to add a link to
 the latest ED and make sure the ED includes a summary list of changes
 since REC was published. (After the 2nd edition REC is published, the
 link could be changed to the new REC.)

 Any objections to doing the above? If not, I'll start a CfC to see
 determine if we have broad consensus to proceed this way.

I don't think we need a CfC to publish a WD, right? We should just publish it, 
and then open a CfC on the plan to move to 2nd edition with these changes 
incorporated, and asking if there are other changes we should include before we 
move ahead.

If there are no other changes people come up with, we make a CR in a few weeks. 
If there are, we need to get them reviewed - if they make sense we have a WD 
and then a CfC on whether to take that to Rec.

A couple of weeks for the CfC to give people time to check, plus a few days 
delay for publishing, seems a reasonable buffer for review, and we should be 
clear that if people need more time to check they should ask for it during the 
initial period of the CfC.

cheers

 -Thanks, ArtB

 On 5/8/15 12:58 PM, Xiaoqian Wu wrote:
  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
  [2] https://github.com/w3c/web-platform-tests/pull/1784
  [3]
  
 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
  [5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17
  [6]
  
 https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror
  [7] https://github.com/w3c/webstorage
  [8] https://www.diffchecker.com/dkbtofsi
  [9] http://www.w3.org/2014/Process-20140801/#rec-modify
  On 2015-4-30, at 8:02pm, Kostiainen, Anssi
  anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote:

  Hi,
  On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com
  mailto: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 

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

[chaals]

In this case we don't know if the spec is feature complete. We just know there 
are things that need to be done.

If they turn out to be all that needs to be done the thing is feature complete, 
and we ask for CR. If not, we hope to discover so now.

But then, it's not a big deal either way. It just feels odd calling a draft a 
wide review draft, as if we didn't want that on other drafts. And fails to 
match what the Process requests of Working drafts which is that they all 
identify which bits they particularly want reviewed - changes, the whole 
thing, missing bits, …

cheers

12.05.2015, 14:05, Arthur Barstow art.bars...@gmail.com:
 On 5/12/15 7:57 AM, cha...@yandex-team.ru wrote:
  I don't think we need a CfC to publish a WD, right? We should just
  publish it, and then open a CfC on the plan to move to 2nd edition
  with these changes incorporated, and asking if there are other changes
  we should include before we move ahead.

 Yes, our SOP is not to do a CfC for a `plain` WD publication but I
 understood a `wide review WD` as a signal the spec is feature complete
 and the next step is CR+. Thus in this case, it seems like a single CfC
 to capture that, plus the other stuff I mentioned should be sufficient.

 -AB

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

Nice version Re: Minutes of Shadow DOM meeting

[chaals]

Attached here is a clean version, which will be archived.

Note that there was a lot of sidechat in IRC it is unclear how much of that 
everyone in the room was aware of. I hope the minutes are a pretty accurate 
record now, but if people feel otherwise I hope they say so.

I'll link this version to the meeting page in the wiki: 
https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting

Dimitri, can you please forward the link to attendees who are not members of 
webapps?

cheers

26.04.2015, 00:14, cha...@yandex-team.ru cha...@yandex-team.ru:
 25.04.2015, 14:45, Bjoern Hoehrmann derhoe...@gmx.net:
  * cha...@yandex-team.ru wrote:
  We'll post a summary - there is most of one at
  
 https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0
  Perhaps a document in some kind of open format would be a better medium
  than some proprietary application with unclear stability policies that
  does not work in my browser.
  The minutes (thanks to Taylor Savage fora  great scribing job) are at
  http://www.w3.org/2015/04/25-webapps-minutes.html
  That contains just a few lines. Looks like the decade-old UTC day change
  bug is still plaguing the minutes generation tool.

 Sigh. Well, alternatively it is the decades-old scribe forgetting to do the 
 thing right… I'll put together the minutes and repost them shortly.

 I've attached a rough version but I'll need to do some more cleaning because 
 I made a mess halfway through. The content is there and legible at least…
  --
  Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
  D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de

 cheers

 --
 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.comTitle: Web apps Web Components meeting -- 26 Apr 2015





 



 - DRAFT - 
Webapps Web Components meeting
24 Apr 2015

Agenda

Attendees



Present
Chaals, Léonie, Mike™, AnnevK, Arron, Travis, Hayato, Smaug, DGlazkov, CWilso, AlexR, SamW, Maciej, TedOC, HayatoIto, Rysouke, JanMiskovsky, DomenicD, Travis_Leithead, AliceBoxhall, WilliamChen, ScottM, ErikBryn, MarkG, SteveOrvell, Misko, WilsonPage, AdamKlein, TaylorSavage, JustinF
Regrets

Chair
DGlazkov, chaals 
Scribe
chaals, taylor



Contents

  Topics
	
	Introductions
State of consensus and contention
Multiple shadow roots per element
Default value of "closed shadow tree"
Imperative distribution API
Separate event retargeting from style composition
Shadow boundary piercing combinators
consensus points...
what does closed *mean*?
Event retargeting
Named slots
Styling

	
  
  Summary of Action Items
  Summary of Resolutions












chaals scribe: chaals




Introductions

DG: Lots of people here... that's good. 
... goal of the meeting is to make sure we move Web Components closer to being interoperable standard (actually shipped...) 
... There are some contentious bits on Shadow DOM, and we aim to resolve that here. 
... We need to determine what goes into v1 that we can all live with and ship - and put the rest into a v2 
... I would like to leave here not just feeling happy, but actually going to do work and knowing what it will be. 
... would like to have champions for the things that we have to do still. 
... The goal is to get browsers implementing, but we need experts from the rest of the ecosystem to tell us about their experience too.



CW: Chris Wilson - mostly here to find the tea... (Googler)



RN: Ryosuke Niwa, Apple



AB: Alice Boxhall, Google accessibility - chrome



Misko: work on angular.js



OP: Olli Pettay / Smaug from mozilla



WC: William Chen, firefox



EO: Ted OConnor, Apple



HI: Hayato Ito, work on shadow dom for google and spec it



JustinF: Work on polymer



AvK: Anne, work for moz on standards



SW: Sam Weinig, Apple



MS: Mike™ Smith, W3C



LJW: Léonie Watson, Paciello Group.



CMN: Chaals from Yandex



AE: Arron Eicholz, MS - work on webapps



TL: Travis Leithead - the MS guy



EB: Erik Bryn



MG: Mark Giffin, writing web components docs for MDN



WP: Wilson Page, working with Web Components on firefox OS



Jan: Founder of component kitchen



MJS: Maciej, webkit at Apple



AR: Alex Russell, googler on web platform



AK: Adam Klein, V8 at google



SM: Scott Miles, work on polymer team



TS: Taylor Savage, google



SO: Steve Orvell google



[polymer team people listening on the phone - we don't let them speak]



dfreedm here in irc as well



[Domenic Denicola (Google) arrived later]


State of consensus and contention

DG: Most vendors aside from Google have explained their current position... 
... would like to figure out how important contentions are - blocker, useful to have, v1 or v2 or...



misko https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Conten

Re: Minutes of Shadow DOM meeting

[chaals]

25.04.2015, 14:45, Bjoern Hoehrmann derhoe...@gmx.net:
 * cha...@yandex-team.ru wrote:
 We'll post a summary - there is most of one at
 https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0

 Perhaps a document in some kind of open format would be a better medium
 than some proprietary application with unclear stability policies that
 does not work in my browser.
 The minutes (thanks to Taylor Savage fora  great scribing job) are at
 http://www.w3.org/2015/04/25-webapps-minutes.html

 That contains just a few lines. Looks like the decade-old UTC day change
 bug is still plaguing the minutes generation tool.

Sigh. Well, alternatively it is the decades-old scribe forgetting to do the 
thing right… I'll put together the minutes and repost them shortly.

I've attached a rough version but I'll need to do some more cleaning because I 
made a mess halfway through. The content is there and legible at least…

 --
 Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
 D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com
Title: Web apps Web COmponents meeting -- 24 Apr 2015





 



 - DRAFT - 
Web apps Web COmponents meeting
24 Apr 2015

Agenda


See also: IRC log

Attendees



Present
Chaals, Léonie, Mike™, AnnevK, Arron, Travis, Hayato, Smaug, DGlazkov, CWilso, AlexR, SamW, Maciej, TedOC, Domenic, Travis_Leithead, AliceBoxhall, WilliamChen, ScottM, ErikBryn, MarkG, SteveOrvell, Misko, WilsonPage, AdamKlein, TaylorSavage
Regrets

Chair
DGlazkov, chaals 
Scribe
chaals



Contents

  Topics
	
	Introductions
State of consensus and contention
Multiple shadow roots per element
Default value of "closed shadow tree"
Imperative distribution API
Seperate event retargeting from style composition
Shadow boundary piercing combinators
consensus points...
what does closed *mean*?
Event retargetting
Named slots
Styling

	
  
  Summary of Action Items
  Summary of Resolutions





Introductions

DG: Lots of people here... that's good. 
... goal of the meeting is to make sure we move Web Components closer to being interoperable standard (actually shipped...) 
... There are some contentious bits on Shadow DOM, and we aim to resolve that here. 
... We need to determine what goes into v1 that we can all live with and ship - and put the rest into a v2 
... I would like to leave here not just feeling happy, but actually going to do work and knowing what it will be. 
... would like to have champions for the things that we have to do still. 
... The goal is to get browsers implementing, but we need experts from the rest of the ecosystem to tell us about their experience too.



CW: Chris Wilson - mostly here to find the tea... (Googler)



RN: Ryosuke Niwa, Apple



AB: Alice Boxhall, Google accessibility - chrome



Misko: work on angular.js



OP: Smaug from mozilla



WC: William Chen, firefox



EO: Ted O'Connor, Apple



HI: Hayato Ito, work on shadow dom for google and spec it



Justin: Work on polymer



AvK: Anne, work for Mozilla on standards



SW: Sam Weinig, Apple



MS: Mike™ Smith, W3C



LJW: Léonie Watson, Paciello Group.



CMN: Chaals from Yandex



AE: Arron Eichols, MS - work on webapps



TL: Travis Leithead - the MS guy



EB: Erik Bryn



MG: Mark Giffin, writing web components docs for MDN



WP: Wilson Page, working with Web Components on firefox OS



Jan: Founder of component kitchen



MJS: Maciej, webkit at Apple



AR: Alex Russell, googler on web platform



AK: Adam Klein, V8 at google



SM: Scott Miles, work on polymer team



TS: Taylor Savage, google



SA: Steve Orvell google



[polymer team people listening on the phone - we don't let them speak]



dfreedm here in irc as well


State of consensus and contention

DG: Most vendors aside from Google have explained their current position... 
... would like to figure out how important contentions are - blocker, useful to have, v1 or v2 or...



misko https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits



- https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits The collected points of disagreement...


Multiple shadow roots per element

MJS: Apple thinks this should be removed and replaced with something like the "named slots" proposal. Strongly think this is the case for v1 - better to replace it with something useful or subclassing won't be useful. 
... there is a time trade off to replacing it



AvK: Mozilla probably don't care strongly for v1 - we would like some solution, and the Apple thing might (or not) work for us...



DG: So there is an alternative, which is not the same as "let's drop what we have"



TL: For multiple shadow roots, should be removed in v1. You can get a lot done just with a single shadow. I like Apple's proposal simplifying the way

Minutes of Shadow DOM meeting

[chaals]

Hi folks,

we're just cleaning up now.

We'll post a summary - there is most of one at 
https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0
 

The minutes (thanks to Taylor Savage fora  great scribing job) are at 
http://www.w3.org/2015/04/25-webapps-minutes.html

cheers

Chaals

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

Re: Better focus support for Shadow DOM

[chaals]

Hi, I noted the bugs, this thread, and the document in the HTML accessibility wiki where I am trying to collate stuff about focus navigation and similar keyboard access issues (in what might yet be a vain attempt to really improve the situation which is overall pretty dismal still): https://www.w3.org/WAI/PF/HTML/wiki/Keyboard 19.02.2015, 04:56, "Takayoshi Kochi (河内 隆仁)" ko...@google.com:[Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigationhttps://www.w3.org/Bugs/Public/show_bug.cgi?id=27965  I am not sure if this really is a problem (which might just be my brain going slowly). See my comment for more details, but it isn't clear to me that this needs to be fixed. On further reflection, I wonder if the point is where the author has explicitly marked tabindex="-1" - and how this relates to comound ARIA controls...  cheers Focus on shadow host should slide to its inner focusable nodehttps://www.w3.org/Bugs/Public/show_bug.cgi?id=28054On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) ko...@google.com wrote:Hi, For shadow DOMs which has multiple focusable fields under the host,the current behavior of tab navigation order gets somewhat weirdwhen you want to specify tabindex explicitly. This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue.https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome!-- Takayoshi Kochi -- Takayoshi Kochi  --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com 

Fwd: Getting to Zaragoza (may be harder)

[chaals]

 Beginning of forwarded message  
26.01.2015, 20:47, cha...@yandex-team.ru cha...@yandex-team.ru:

Hi,

TL;DR: May be harder to get a train, will probably be more expensive than I 
said.

I've been looking at the renfe site recently. There may or may not be trains, 
or fewer trains, doing the direct trip. It's a somewhat unreliable site with 
regard to available options (although if you get a ticket you can rely on it). 
I have been looking for clarification, but thought it would be better to 
announce the issues now.

It seems that the cheap prices I had found and quoted have disappeared, so 
expect something more like €35 - €75 each way.

There are also buses, which go direct from Madrid airport, or from Barcelona 
Nord* Bus station, about every 2 hours. They cost less than €20, but take about 
3 1/2 hours. http://www.alsa.es (there is a button with an english flag to 
switch to english, among the headers and banners at the top of the page).

Barcelona Nord is not the airport, it's by the Metro station Arc de Triomf. 
Some buses are Supra - bigger seats (but fewer on the Bus), sort of a 
business class bus.

If this makes you change your mind, please note it in the voting system...

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

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

Re: Feedback needed for April 2015 face-to-face location by *January 27, 2015*

[chaals]

21.01.2015, 01:40, Philippe Le Hegaret p...@w3.org:
 All,

 We are fortunate enough to have two proposed locations for the HTML and
 Web Applications face-to-face meeting in the week of April 13-17, 2015.
 Your feedback will help us picking the location.

 1. Redmond, WA, USA (Hosted by Microsoft):
 2. Zaragoza, Spain (Hosted by Yandex)

Actually it is hosted by the Ayuntamiento de Zaragoza (i.e. the city council, 
who have been a member for about a decade, and do a lot of good stuff. I just 
asked around for a host and passed on their very generous offer).

 Please provide your preferences at:
   https://www.w3.org/2002/09/wbs/42538/webapps-spring-2015/

I can't fill in the survey yet ;(

My preference is Zaragoza. It's about the same pain to get there from the 
airport (without having to rent a car), but you end up in Zaragoza, which costs 
much less than Redmond, has a real city with life, bars, history, architecture, 
and everything is walkable with a good public transport system as well.

Plus it has been 2 1/2 years since we met in Europe (compared to twice in a 
year on the West Coast - beating our long term average of 1 and a bit times / 
year).

 by January 27, 2015.

cheers

Chaals

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

IME API…

[chaals]

Hi,

while you are looking at HTML5, it would be really helpful if you could take a 
look at the work on IME API 
http://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html and if you have 
comments or questions send them to the webapps group (copied). 

(Also, I believe you could communicate directly with the editors in Japanese if 
that's easier, although the rest of us would appreciate at least a summary of 
detailed discussions or questions that turn out to be non-trivial).

cheers

Chaals

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

Re: Better focus support for Shadow DOM

[chaals]

Hi, please consider how thi relates to the management of "aria-active-descendant" and why we should not be working to bring the two of these in line. Note also that in HTML there is a proposal to deprecate (and hopefully one day abandon) tabindex with positive values, in favour of something less painful than forcing the user to press tab a zillion times as the way to get around an app. The HTML accessibility task force is currently looking at these issues for HTML, and it would be good to align the work. There is a question of where it makes more sense to have the conversation, but for the moment it is on public-html-a...@w3.org and on their wiki - listed as accesskey for increasingly irrelevant historical reasons http://www.w3.org/WAI/PF/HTML/wiki/51wishlist cheers Chaals 14.01.2015, 08:30, "Takayoshi Kochi (河内 隆仁)" ko...@google.com:Hi, For shadow DOMs which has multiple focusable fields under the host,the current behavior of tab navigation order gets somewhat weirdwhen you want to specify tabindex explicitly. This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue.https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome!-- Takayoshi Kochi  --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com 

Re: Better focus support for Shadow DOM

[chaals]

Hi Takayoshi, 14.01.2015, 13:04, "Takayoshi Kochi (河内 隆仁)" ko...@google.com:I was not aware that positive tabindex value is being deprecated, but anyway it should make sensewhen tabindex=0 specified on the shadow host. And as it has not been completely deprecated,it should be okay to keep the document as is, but I will add some comments or pointer. Yep. It was more "for your information".  For aria-activedescendant, I was not aware either, do you think it still make sense when thereal active descendant is in a shadow tree (i.e. the host and the active element live in different scope)?(added public-html-a11y to cc) Yes, because I think as far as possible it makes sense to align the models we use for managing focus in different places. (It may be that the right answer is to look at changing ARIA - but having two different models for fairly similar things seems like a bad idea to me). cheers   On Wed, Jan 14, 2015 at 6:28 PM, cha...@yandex-team.ru wrote:Hi, please consider how thi relates to the management of "aria-active-descendant" and why we should not be working to bring the two of these in line. Note also that in HTML there is a proposal to deprecate (and hopefully one day abandon) tabindex with positive values, in favour of something less painful than forcing the user to press tab a zillion times as the way to get around an app. The HTML accessibility task force is currently looking at these issues for HTML, and it would be good to align the work. There is a question of where it makes more sense to have the conversation, but for the moment it is on public-html-a...@w3.org and on their wiki - listed as accesskey for increasingly irrelevant historical reasons http://www.w3.org/WAI/PF/HTML/wiki/51wishlist cheers Chaals 14.01.2015, 08:30, "Takayoshi Kochi (河内 隆仁)" ko...@google.com:Hi, For shadow DOMs which has multiple focusable fields under the host,the current behavior of tab navigation order gets somewhat weirdwhen you want to specify tabindex explicitly. This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue.https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome!-- Takayoshi Kochi  --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com  -- Takayoshi Kochi  --Charles McCathie Nevile - web standards - CTO Office, Yandexcha...@yandex-team.ru - - - Find more at http://yandex.com 

Re: [Selection] Should selection.getRangeAt return a clone or a reference?

[chaals]

13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
 On 1/12/15 1:56 PM, Olivier Forget wrote:
  Unfortunately
  multiple range selections are not a nice to have. All real editors
  (MS Word, Google Docs, etc..) support selecting multiple ranges

 Precisely.  This is why Gecko ended up supporting it: it was needed for
 the editor that was part of the Mozilla suite back in the day

 Of course I've made this point before; it just got ignored.  :(

:(

And yeah, painful as it may be to implement in the browser, I suspect in the 
long run it is the right answer.

cheers

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

Re: Shadow tree style isolation primitive

[chaals]

13.01.2015, 00:57, Ryosuke Niwa rn...@apple.com:
  On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote:

  09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl:
  I'm wondering if it's feasible to provide developers with the
  primitive that the combination of Shadow DOM and CSS Scoping provides.
  Namely a way to isolate a subtree from selector matching (of document
  stylesheets, not necessarily user and user agent stylesheets) and
  requiring a special selector, such as , to pierce through the
  boundary.
  Sounds like a reasonable, and perhaps feasible thing to do, but the obvious 
 question is why?

  The use cases I can think of are to provide the sort of thing we do with 
 BEM today. Is the effort worth it, or are there other things I didn't think 
 of (quite likely, given I spent multiple seconds on the question)?

 The benefit of this approach is that all the styling information will be in 
 one place.  CSS cascading rules is already complicated, and having to consult 
 the markup to know where the selector boundary is will be yet another 
 cognitive stress.

Sorry, I'm dense this morning for sure. Why would all the styling information 
be in one place? I'm still thinking from the model of BEM, where the benefit is 
that for a particular block you can collect everything (styling, scripts, 
whatever magic you want - or just a couple of plain tags and 4 words) in one 
place, and the different pieces get stitched together without having to worry 
about how they will impact each other because ordinarily they wont.

(The corresponding cognitive price is that if you *want* to do things 
page-wide across a bunch of different blocks, you need to think more).

Could you provide a slightly longer-form answer for dummies (i.e. me) please?

cheers

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

Re: Shadow tree style isolation primitive

[chaals]

09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl:
 I'm wondering if it's feasible to provide developers with the
 primitive that the combination of Shadow DOM and CSS Scoping provides.
 Namely a way to isolate a subtree from selector matching (of document
 stylesheets, not necessarily user and user agent stylesheets) and
 requiring a special selector, such as , to pierce through the
 boundary.

Sounds like a reasonable, and perhaps feasible thing to do, but the obvious 
question is why?

The use cases I can think of are to provide the sort of thing we do with BEM 
today. Is the effort worth it, or are there other things I didn't think of 
(quite likely, given I spent multiple seconds on the question)?

cheers

Chaals

 This is a bit different from the `all` property as that just changes
 the values of all properties, it does not make a selector such as
 div no longer match.

 So to be clear, the idea is that if you have a tree such as

   section class=example
 h1Example/h1
 div ... /div
   /section

 Then a simple div selector would not match the innermost div if we
 isolated the section. Instead you would have to use section  div or
 some such. Or perhaps associate a set of selectors and style
 declarations with that subtree in some manner.

 --
 https://annevankesteren.nl/

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

[Manifest] Navigation Scope is unclear

[chaals]

Hi,

I'm trying to understand the navigation scope section of the manifest spec. 
More or less all the links are circular references, which isn't making it any 
clearer.

An example or two would really help...

cheers

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

Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)

[chaals]

TL;DR: Administrative details from the W3C Webapps cochair responsible for URL 
in that group. Relevant in practice is a request to minimise channels of 
communication to simplify spec archaeology, and especially to prefer 
public-webapps over www-archive, but I don't see there is any reason this 
WorkMode cannot be used.

02.12.2014, 04:19, Sam Ruby ru...@intertwingly.net:
 On 11/18/2014 03:18 PM, Sam Ruby wrote:
  Meanwhile, I'm working to integrate the following first into the WHATWG
  version of the spec, and then through the WebApps process:

  http://intertwingly.net/projects/pegurl/url.html

 Integration is proceeding, current results can be seen here:

 https://specs.webplatform.org/url/webspecs/develop/

 It is no longer clear to me what through the WebApps process means.
 In an attempt to help define such, I'm making a proposal:

 https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface

 At this point, I'm looking for general feedback.  I'm particularly
 interested in things I may have missed. 

A bunch of comments about how to work with a W3C group:

Participation and Communication…
In W3C there is a general desire to track contributions, and ensure that 
contributors have made patent commitments. When discussion is managed through 
the W3C working group, the chairs and staff contact take responsibility for 
this, in conjunction with editors. If the editor wants to use other sources, 
then we ask the editor to take responsibility for tracking those sources. The 
normal approach is to request that contributors join the Working Group, either 
as invited experts or because they represent a member organisation. In many 
cases, contributors are already represented in webapps - for instance while 
Anne van Kesteren isn't personally a member, his employer is, and there is 
therefore a commitment from them.

While webapps generally prefers conversations to be on the webapps list 
(because it makes it easier to do the archaeology in a decade or so if someone 
needs to), there is no formal ban on using other sources. However, I would ask 
that you request comments on publicly archived lists, and specifically that you 
strongly prefer public-webapps@w3.org (which is a list designated for technical 
discussion whose subscribers include W3C members who expect to discuss work 
items in the scope of the webapps group, such as the URL spec) to www-archive 
(which is just a place to give a public anchor to random email - the 
subscription list is completely random and likely not to include many 
interested W3C members).

The TR Process…
The WHATWG document is not a Public Working Draft in the sense of the W3C 
Process (which has implications for e.g. patent policy). Regularly publishing a 
Public Working Draft to w3.org/TR is part of what makes the patent policy work, 
since commitments are bound to various stages including the latest Public 
Working Draft (i.e. TR version, not editors' draft) before someone left the 
group [wds]. Those snapshots are required to be hosted by W3C and to meet the 
team's requirements, as determined by the Team from time to time. If there is 
an issue there, let's deal with it when we see it.

Webapps still generally works under the 2005 version of the Process - but we 
could change this document to the 2014 process. The only really noticeable 
difference will be that there is formally no Last Call, and the final Patent 
Exclusion opportunity is instead for the draft published as Candidate 
Recommendation. (In other words, you need to be pretty bureaucratically-minded 
to notice a difference).

Documents published by W3C are published under whatever license W3C decides. 
The Webapps charter explicitly calls out the URL spec for publishing under the 
CC-BY license [chart], so that is what I would expect for all snapshots.

For normative references, at least until Last Call or CR (depending on whether 
you use the modern Process) I don't think we need to care a huge amount. When 
we do get there, the policy for publishing at W3C will determine what we can do 
in a W3C publication - although we should note that there is a lot of 
discussion about references that fails to take reality into account,and many 
specs have normative references that are actually unusable normatively. My 
*personal* sense is that a lot more references should be informative, admitting 
the state of the universe as it is rather than as we wish it were. But I'm 
inclined to cross that when we get there.

Editors
Editors of W3C specs are required [eds] to be members of the Working Group 
publishing the spec. Webapps is pretty liberal about appointing editors - the 
principal criteria are you are in the group and volunteer to do work.

Patent Policy
As I read the invited expert agreement [iea] it uses branching (quoted - 
french-style) as an example of creating derivative works that include the 
Invited Expert's contributions when those derivative works are likely to cause 
confusion about the 

Re: URL Spec WorkMode

[chaals]

TL;DR: The administrative hold-ups are now all my fault, so I'm sorry if they 
persist, and I will start working to remove them...

(other stuff later)

02.12.2014, 15:57, Sam Ruby ru...@intertwingly.net:

 What is the hold-up for publishing a Public Working Draft?

It has been that the chairs have been pretty busy, and we dropped the ball 
between us. More recently, we sorted that out so the hold up is now me.

  Can I ask that you respond to the following email?

Yes. That's a very fair request. I may be able to do so tonight…

 http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html

 Let me know what I need to do.
  Webapps still generally works under the 2005 version of the Process -
  but we could change this document to the 2014 process. The only
  really noticeable difference will be that there is formally no Last
  Call, and the final Patent Exclusion opportunity is instead for the
  draft published as Candidate Recommendation. (In other words, you
  need to be pretty bureaucratically-minded to notice a difference).

 Lets update to 2014 now.  Its only a matter of time before not updating
 won't be an option any more.

Works for me. I'll start a Call for Consensus - but I imagine it will be a 
formality.

Cheers

Chaals

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

Re: URL Spec WorkMode

[chaals]

03.12.2014, 00:46, Sam Ruby ru...@intertwingly.net:
 On 12/02/2014 04:37 PM, Sam Ruby wrote:
  [offlist]

 Oopsie.  Note to self: double check cc list before sending emails.

:)

 In any case, the suggestion for pull requests applies to everyone.

  I notice that you are on GitHub.  One thing I encourage you to do is to
  directly edit:

  https://github.com/webspecs/url/blob/develop/docs/workmode.md

  Expand the proposal, fix mistakes, correct typos -- everything is fair
  game.

  This will result in pull requests, but pretty much anything that doesn't
  unnecessarily cause somebody to come unglued I'll take.

Sure. But I find markdown almost as painful as PDF to work with (I prefer HTML, 
but if push comes to shove probably prefer a Word document over markdown), and 
I am not sure what will cause someone to come unglued. I prefer to have some 
sense that we are on common ground before providing a pull request. (I'm also 
not a one-eyed fan of working with github).

Plus I really seriously appreciate having the history of W3C work available in 
W3C archives and seriously dislike the approach of scattering it to the four 
winds, so putting the rationale there first is a simple matter of coherence.

  The same thing is true for the working draft:

  https://github.com/w3ctag/url/tree/develop

  Change the copyright, status, metadata at the top of url.bs.  Heck, if
  you feel so inclined, change the spec itself.

Yeah, I am much happier to make proposals for spec changes (if I think they are 
needed). Frankly, I'm not terribly interested in messing with the metadata 
unless I see a concrete problem that a change will solve.

At the moment I see us 

  I'm making the same suggestion to Wendy.  I'd love for the end result to
  be a truly joint proposal.

Well, the way to work together is to find consensus. If we do that any of us 
can write it down. If not, who wrote the agreement doesn't matter.

Anyway, on to deal with the things that are overdue already...

cheers

Chaals

  - Sam Ruby

  On 12/02/2014 10:28 AM, Sam Ruby wrote:
  On 12/02/2014 09:23 AM, cha...@yandex-team.ru wrote:
  TL;DR: The administrative hold-ups are now all my fault, so I'm sorry
  if they persist, and I will start working to remove them...
  Thanks in advance for helping clear administrative obstacles!
  (other stuff later)

  02.12.2014, 15:57, Sam Ruby ru...@intertwingly.net:
  What is the hold-up for publishing a Public Working Draft?
  It has been that the chairs have been pretty busy, and we dropped the
  ball between us. More recently, we sorted that out so the hold up is
  now me.
  For discussion purposes:

  https://rawgit.com/w3ctag/url/develop/url.html
    Can I ask that you respond to the following email?
  Yes. That's a very fair request. I may be able to do so tonight…
  http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html

  Let me know what I need to do.
    Webapps still generally works under the 2005 version of the
  Process -
    but we could change this document to the 2014 process. The only
    really noticeable difference will be that there is formally no Last
    Call, and the final Patent Exclusion opportunity is instead for the
    draft published as Candidate Recommendation. (In other words, you
    need to be pretty bureaucratically-minded to notice a difference).
  Lets update to 2014 now.  Its only a matter of time before not updating
  won't be an option any more.
  Works for me. I'll start a Call for Consensus - but I imagine it will
  be a formality.

  Cheers

  Chaals

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

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

PSA: Publishing working draft of URL spec

[chaals]

Hi, (chair hat on)

this is an answer to the request in 
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html to 
publish a new Working Draft of the URL spec.

There is no need for a CfC, per our Working Mode documents, so this is 
announcement that we intend to publish a new Public Working Draft of the URL 
spec, whose technical content will be based on what is found at 
https://specs.webplatform.org/url/webspecs/develop/ and 
https://url.spec.whatwg.org/

If the document doesn't meet pubrules, that will cause a delay as Sam and I 
deal with it.

There is an open CfC to move the document to the 2014 Process, but it doesn't 
really matter whether this or the next Public Working Draft is published under 
that process so it won't hold up a Public Working Draft if we can get the 
pubrules etc sorted in time.

cheers

Chaals

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

Re: URL Spec WorkMode

[chaals]

You don't need permission to publish a revised working draft - the workmode is 
do it and see if anyone screams.

So I announced we would. Now we just have to put together something that passes 
pubrules, or figure out what to do if there are issues.

Tomorrow I am taking a day off (hence writing this after bed time) to do urgent 
stuff for my employer, and then I am flying to Australia where I spend 
Monday-Wednesday in all-day face to face before flying to Moscow. So I won't 
really be around until the CfC for the new process is announced. I can make a 
request for publication if you have a draft that you think meets pubrules. If 
you want me to actually work on such a draft, I can take the content off the 
tag github and do so - at best it will happen on the weekend, more likely the 
next weekend.

If there are *substantive* differences between the whatwg and other version, 
which one do you want to fall back to? I prefer the other one because it 
looks more complete to me, but frankly I don't care whether you choose one, the 
other, or to make spot decisions - this is a Working Draft. But I will have to 
reply to Domenic's question.

cheers

02.12.2014, 18:28, Sam Ruby ru...@intertwingly.net:
 On 12/02/2014 09:23 AM, cha...@yandex-team.ru wrote:
  TL;DR: The administrative hold-ups are now all my fault, so I'm sorry if 
 they persist, and I will start working to remove them...

 Thanks in advance for helping clear administrative obstacles!
  (other stuff later)

  02.12.2014, 15:57, Sam Ruby ru...@intertwingly.net:
  What is the hold-up for publishing a Public Working Draft?
  It has been that the chairs have been pretty busy, and we dropped the ball 
 between us. More recently, we sorted that out so the hold up is now me.

 For discussion purposes:

 https://rawgit.com/w3ctag/url/develop/url.html
    Can I ask that you respond to the following email?
  Yes. That's a very fair request. I may be able to do so tonight…
  http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html

  Let me know what I need to do.
    Webapps still generally works under the 2005 version of the Process -
    but we could change this document to the 2014 process. The only
    really noticeable difference will be that there is formally no Last
    Call, and the final Patent Exclusion opportunity is instead for the
    draft published as Candidate Recommendation. (In other words, you
    need to be pretty bureaucratically-minded to notice a difference).
  Lets update to 2014 now.  Its only a matter of time before not updating
  won't be an option any more.
  Works for me. I'll start a Call for Consensus - but I imagine it will be a 
 formality.

  Cheers

  Chaals

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

 - Sam Ruby

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

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

[chaals]

07.11.2014, 14:41, Arthur Barstow art.bars...@gmail.com:
 [ Sorry for the cross posting but the Fullscreen spec is a joint
 deliverable for WebApps and CSS ]

 Hi Anne, Tantek, WebApps and CSSWG,

 During WebApps' October 27 f2f meeting, the attendees had a straw-poll
 regarding stopping work on the Fullscreen spec (a joint deliverable for
 these two WGS) and to publish a WG Note of the spec. Since there were no
 objections raised during the poll (see [Mins]), 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)

Yes (and no)

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

Yes

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

Yes.

 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)

Abstain.

cheers

 Since the CSS WG already resolved to publish this spec as a WG Note (see
 [CSS-Mins]), there is no need for members of that group to reply to this
 CfC (although all feedback is welcome.)

 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#item09
 [Draft-Note] https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html
 [ED] https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
 [e.g.] http://www.w3.org/TR/2014/NOTE-file-system-api-20140424/
 [CSS-Mins]
 http://lists.w3.org/Archives/Public/www-style/2014Oct/0295.html##Fullscreen

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

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

[chaals]

07.11.2014, 17:53, fantasai fantasai.li...@inkedblade.net:
 On 11/07/2014 09:01 AM, Arthur Barstow wrote:
  On 11/7/14 8:48 AM, Anne van Kesteren wrote:
  On Fri, Nov 7, 2014 at 2:39 PM, Arthur Barstow art.bars...@gmail.com 
 wrote:
  [Draft-Note] https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html
  It would be nice if editor's draft points to 
 https://fullscreen.spec.whatwg.org/
  That would be OK with me but as a W3C TR I'm not sure if that is permitted 
 or not.
  Yves, Cindy, PLH - can we do as Anne suggests?

 I'm pretty sure there is no rule against pointing to another spec in a Note.
  I suppose another option is to remove the Editor's Draft from the 
 boilerplate.

 It probably makes sense to do that anyway. They should both point to the
 currently-maintained draft.

Yeah, the point is that we are not maintaining a draft and WHAT-WG are. So we 
do the world a service by pointing to that, and no service by avoiding it.

And I don't know of a rule that says we cannot do that. It isn't a normative 
reference, it's just a link to useful information.

cheers

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

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

[chaals]

07.11.2014, 15:05, Arthur Barstow art.bars...@gmail.com:
 On 11/7/14 8:43 AM, cha...@yandex-team.ru wrote:
  07.11.2014, 14:41, Arthur Barstow art.bars...@gmail.com:
  [ Sorry for the cross posting but the Fullscreen spec is a joint

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

 For the purposes of this CfC, I think my parenthetical and your `no` are
 effectively a whatever that we can defer until if/when there is a
 charter discussion. Agreed?

Yeah, definitely.

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]

07.11.2014, 18:28, Domenic Denicola d...@domenic.me:
  On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote:
  On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com 
 wrote:
  https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html
  Should this not include a reference to https://xhr.spec.whatwg.org/?

 Or better yet, just be a redirect to it, as was done with WHATWG's DOM 
 Parsing spec to the W3C one?

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

But yeah, a pointer is a pretty obvious thing to put in.

cheers

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

Spring meeting in Paris?

[chaals]

Hi,

we have had a (northern) spring meeting in California for the last few years, 
co-located with HTML.

The HTML group is considering having a meeting in may(ish) 2015 in Paris - and 
there is an offer to host such a meeting.

So the question is whether people are interested in having a face to face in 
Paris instead of Silicon Valley.

For the moment exact timing is open for debate, but initially preferred 
candidates include the last week of April and the second week of May. For those 
who get excited about such things, the Advisory Committee and the Advisory 
Board will be meeting in the first week of May in Paris.

Note that 1 and 8 May are both french holidays.

cheers

Chaals

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

Re: [streams-api] Seeking status of the Streams API spec

[chaals]

- annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@

23.10.2014, 15:06, Arthur Barstow art.bars...@gmail.com:
 On 10/22/14 6:27 PM, Paul Cotton wrote:
  given the magnitude of the changes in [changeset], a new WD should be
  published.

  Can we please wait until after the TPAC week to publish the proposed
  Streams heartbeat? Given the substantive changes being made here I
  think it would be best to have a WebApps WG discussion as proposed by
  Art [1] BEFORE publishing such a heartbeat.

 I think the draft WD captures the recent developments and discussions
 (certainly much better than the previous WD) so I prefer to go ahead
 with the publication and if there are any issues, bugs, etc., they
 should be raised 

Seconded. Note there is no reason not to raise the topic in discussion at TPAC, 
with the two drafts available for comparison.

Working Drafts do not reflect consensus...

cheers

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

Re: FileSystem API Comments

[chaals]

22.10.2014, 12:32, David Rajchenbach-Teller dtel...@mozilla.com:
 I don't see a contradiction.
 Each *web* app sees only files accessible from its domain (so your two
 apps have distinct pic.jpeg).
 Each *native* app has access to whatever the operating system says.

There are a lot of use cases for sharing data with apps of *different* origins, 
although there is of course a more complex security story than when everything 
goes into a potentially opaque sandbox. (And to make the basic security story 
work it makes sense to have some level of opacity in the sandbox).

The lack of a mechanism to do so is a huge difference with native - I have 
directories in my filesystem that are autosynched to things online, but are 
also visible.

The idea behind web intents/activites/etc generalises obviously to remove the 
distinction between web and native - I should be able to use a web-based image 
manipulation tool on stuff in my filesystem. Or several.

At the moment that can be done in a somewhat hacky way by uploading files, 
manipulating them, then asking the user to save them back. But whereas I have 
mail clients that store each email message on the filesystem, so I can import 
stuff into a different program myself instead of having to go through a service 
provider, that doesn't work for web-based email systems even when those are 
designed to be functional offline.

etc etc.

cheers

Chaals

 Or am I missing something in your message?

 Cheers,
  David

 On 22/10/14 12:23, Jonathan Bond-Caron wrote:
  That contradicts:
  - Edited files should be accessible by other client-side applications

  The api should allow for editing a 'shared folder' which multiple 
 applications / web apps can access.
  That implies a sort of locking/unlocking api:

  e.g.
  photo editor
  fs = api.getFileSystem({shareName: photos}).then((dir) = { 
 dir.openWrite(pic.jpeg) });

  super photo viewer
  fs = api.getFileSystem({shareName: photos}).then((dir) = { 
 dir.openRead(pic.jpeg) });

  What happens with the pic.jpeg?

 --
 David Rajchenbach-Teller, PhD
  Performance Team, Mozilla

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

Re: Questions on the future of the XHR spec, W3C snapshot

[chaals]

20.10.2014, 07:31, 송정기 jungkee.s...@samsung.com:
 Thanks Hallvord for having started the thread and sharing the 
 annotate_spec.js to move the testing activity forward.

Yup.

 For the spec side of it, I agree to Domenic's idea either publishing it as a 
 group note pointing to the source material or installing a redirection to it. 
 Without the Fetch refactoring, it seems that a new TR based on the old 
 snapshot won't be satisfying the forward compatibility sooner or later. E.g., 
 web authors will also expect an XHR request will fire a fetch event on a 
 service worker, but the old snapshot will still remain with a pointer to a 
 fetch in HTML spec, etc.

My answer ultimately depends on what the editors are prepared to do.

While it seems bleeding edge XHR specs will be in flux for some time (e.g. if 
Anne takes the spec of record and dismembers it into fetch, I presume he 
won't get that done within a couple of months...)

In the meantime it would be useful to have a stable reference for roughly how 
to use XHR - after all, for a lot of purposes that hasn't changed in years.

Ideally I would support Hallvord's option A, of publishing a Rec based roughly 
on what we have prior to refactoring that provides a more-or-less usable 
description of XHR, assuming it got very clear pointers to the expected future 
of refactoring the theoretical basis of the spec and cleaning up cases poorly 
or not handled by where we are now.

For the part of the world where a stable reference really is important 
(millions of citizens who want or need to use services provided by governments, 
people who rely on authorised translations, and various others), this would be 
helpful. 

Of course it assumes someone is available to do the publishing work fairly 
fast. Are the existing editors in a position to do so?

cheers

Chaals

 --
 Jungkee

 --- Original Message ---
 Sender : Domenic Denicoladome...@domenicdenicola.com
 Date   : 2014-10-20 11:44 (GMT+09:00)
 Title  : RE: Questions on the future of the XHR spec, W3C snapshot

 I just remembered another similar situation that occurred recently, and in my 
 opinion was handled perfectly:

 When it became clear that the WHATWG DOM Parsing and Serialization Standard 
 was not being actively worked on, whereas the W3C version was, a redirect was 
 installed so that going to https://domparsing.spec.whatwg.org/ redirected 
 immediately to https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html.

 This kind of solution seems optimal to me because it removes any potential 
 confusion from the picture. XHR in particular seems like a good opportunity 
 for the W3C to reciprocate, since with both specs there's a pretty clear 
 sense that we all want what's best for the web and nobody wants to have their 
 own outdated copy just for the sake of owning it.

 -Original Message-
 From: Hallvord R. M. Steen [mailto:hst...@mozilla.com]
 Sent: Friday, October 17, 2014 20:19
 To: public-webapps
 Subject: [xhr] Questions on the future of the XHR spec, W3C snapshot

 Apologies in advance that this thread will deal with something that's more in 
 the realm of politics.

 First, I'm writing as one of the W3C-appointed editors of the snapshot 
 the WebApps WG presumably would like to release as the XMLHttpRequest 
 recommendation, but I'm not speaking on behalf of all three editors, although 
 we've discussed the topic a bit between us.

 Secondly, we've all been through neverending threads about the merits of TR, 
 spec stability W3C style versus living standard, spec freedom and reality 
 alignment WHATWG style. I'd appreciate if those who consider responding to 
 this thread could be to-the-point and avoid the ideological swordmanship as 
 much as possible.

 When accepting editor positions, we first believed that we could ship a TR of 
 XHR relatively quicky. (I think of that fictive TR as XHR 2 although W3C 
 haven't released any XHR 1, simply because CORS and the other more recent API 
 changes feel like version 2 stuff to me). As editors, we expected to update 
 it with a next version if and when there were new features or significant 
 updates). However, the WHATWG version is now quite heavily refactored to be 
 XHR+Fetch. It's no longer clear to me whether pushing forward to ship XHR2 
 stand-alone is the right thing to do.. However, leaving an increasingly 
 outdated snapshot on the W3C side seems to be the worst outcome of this 
 situation. Hence I'd like a little bit of discussion and input on how we 
 should move on.

 All options I can think of are:

 a) Ship a TR based on the spec just *before* the big Fetch refactoring. The 
 only reason to consider this option is *if* we want something that's sort of 
 stand-alone, and not just a wrapper around another and still pretty dynamic 
 spec. I think such a spec and the test suite would give implementors a pretty 
 good reference (although some corner cases may not be sufficiently clarified 
 to be compatible). Much

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[chaals]

06.10.2014, 09:19, Jonas Sicking jo...@sicking.cc:
 On Sun, Oct 5, 2014 at 2:28 PM,  cha...@yandex-team.ru wrote:
  So the question turns on whether the changes would invalidate a patent 
 review, and my quick guess is that the answer is yes ;(

 Really? I would have made the opposite conclusion. Changing the event
 source makes a very small difference in behavior. I would greatly
 surprise me if it affected the applicability of a given patent.

There are a lot of patents that hang on such slender threads. And PAGs have 
been formed for them, only to discover that such a simple change made the 
difference between the patent being relevant or not.

 That said, it is theoretically possible. But that seems to be true for
 *any* normative change of a spec.

Right. That's why normative changes require returning to Last Call. :(

It seems that the way patents are handled, at least in the US which effectively 
seems to be the only jurisdiction W3C really cares about, is slowly changing. 
But slowly - and for some time we're probably tied to the fact that almost any 
normative changes can effectively revoke the licensees given under the Patent 
Policy.

:(

cheers

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

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[chaals]

Please please do. That's a useful thing to do regularly…

02.10.2014, 13:17, Mounir Lamouri mou...@lamouri.fr:
 Can we at least publish a new WD so people stop referring to the old
 TR/?

 -- Mounir

 On Wed, 1 Oct 2014, at 20:36, Arthur Barstow wrote:
  On 9/25/14 9:26 AM, Mounir Lamouri wrote:
  On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote:
  On 9/25/14 6:36 AM, Anne van Kesteren wrote:
  It effectively comes down to the fact that the specification describes
  something, but Chrome implements it in another way per how I suggested
  it should work (using animation frame tasks).
  So this appears to be [Issue-40] and I think a one-line summary is the
  Editors consider this something that can be deferred to the next version
  and Anne considers it something that should be addressed before LC is
  published.

  Vis-a-vis this CfC, it seems the main options are:

  1. Continue to work on this issue with the goal of getting broader
  consensus on the resolution

  2. Publish the LC as is

  3. Publish the LC as is but explicitly highlight this Issue and ask
  for Implementer/Developer feedback

  4. Other options?

  Of course, I'd like to hear from others but I tend to think we should
  first try #1 (especially since Anne indicates the spec and at least one
  implementations are currently not aligned).

  Mounir, Marcos - would you please work with Anne on a mutually agreeable
  solution?
  Last I checked, animation frame task was still underdefined. This is
  what you can read in the WHATWG's fullscreen specification:
  Animation frame task is not really defined yet, including relative
  order within that task, see bug 26440.

  In my opinion, if the spec is changed to use animation frame task, it
  would not change much in the current state of things.
  Well, perhaps this would be true but the devil's in the details and
  the details do matter (see below).
  Also, I'm not entirely sure why Anne is so loudly complaining about that
  issue. The issue was not closed or waived but postponed until we can
  properly hooked to the thing. LC doesn't freeze the specification and we
  could definitely get this fixed before moving to CR.

  What I suggested to him on IRC and what I believe is the best approach
  to reconcile the two worlds (WHATWG live standards and W3C snapshots) is
  to take the current version of the spec to LC and update the ED to use
  animation frame task and mark it as a WIP feature. I opened issue 75
  last week as a reminder to do that.

  Arthur, what do you think of that solution?
  We can certainly publish a LC with open issues (as was explicitly noted
  in the original CfC [1]). However, I do want to emphasize that if any
  substantive issue is filed after the LC is published, and the group
  agrees to address any such issue(s), the group must publish another LC
  before the spec can move to CR. I mention this because LC-LC loops
  are time consuming for the group, implementers and developers and thus
  should be avoided if possible. As such, it seems like pursuing #1 should
  be the next step.

  -Thanks, AB

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

Re: CfC: to using new pub process; deadline October 2

[chaals]

25.09.2014, 16:06, Arthur Barstow art.bars...@gmail.com:
 On 9/25/14 9:32 AM, Marcos Caceres wrote:
  Ok so, let's start getting consensus on the new pub work flow [1]. I want 
 us to be the first using the new pub process the second it is available.

  Does anyone object to Editors in this group using [1]?

  [1] http://www.w3.org/2014/08/pubworkflow.html

I can't see any reason to object to using this.

But I would object to publishing every update to an editor's draft as the new 
/TR draft.

Editor's drafts need to be readily available for a variety of stakeholders.

/TR drafts should be updated when there have been significant changes to the 
previous published document that would benefit from review beyond the Working 
Group - http://www.w3.org/2014/Process-20140801/#revised-wd

I.e. TR drafts should have a bit more stability than is required for an 
editor's draft. In many cases it makes a lot of sense to check in each little 
change separately to an editor's draft, in order to get good logging of what 
actually changed. Whereas a TR draft should be able to sum up the differences 
between it and a previous version (with a significant change) in a few lines.

cheers

 Thanks Marcos.

 All - if you have any comments or concerns about Marcos' CfC above,
 please send them to public-webapps @ w3.org by October 2 at the latest.
 Positive response is preferred and encouraged and silence will be
 considered as agreement with the proposal.

 -Thanks, ArtB

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

Re: CfC: publish FPWD of Selection API; deadline Sept 30

[chaals]

23.09.2014, 02:23, Arthur Barstow art.bars...@gmail.com:
 Ryosuke proposes WebApps publish a First Public Working Draft of
 Selection API and this is a Call for Consensus to do so, using the
 following Editor's Draft as the basis (draft FPWD is [1]):

    http://w3c.github.io/selection-api/

Please do.

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

Re: [xhr]

[chaals]

02.09.2014, 10:55, Anne van Kesteren ann...@annevk.nl:
 On Tue, Sep 2, 2014 at 2:54 AM, Robert Hanson hans...@stolaf.edu wrote:
  I respectively request that the wording of the warning
[...]
  Warning: Developers must not pass false for the async argument when the
  JavaScript global environment is a document environment as it has
  detrimental effects to the end user's experience. User agents are strongly
  encouraged to warn about such usage in developer tools and may experiment
  with throwing a InvalidAccessError exception when it occurs so the feature
  can eventually be removed from the platform.

 [change] to

  Note: Developers should not pass false for the async argument when the
  JavaScript global environment is a document environment as it has
  detrimental effects to the end user's experience. Developers are advised
  that passing false for the async argument may eventually be removed from the
  platform.

 Sorry. As with showModalDialog() we would really like to make this
 feature disappear. I realize this makes some forms of code generation
 harder, but hopefully you can find a way around that in time.

Perhaps we should set some sense of expectation about *when* it won't work. 
Different parts of the Web move on different timelines.

It may be simple to remove it from modern browsers, but this will simply 
motivate organisations who depend on a system that uses synch XHR to stop 
updating until they can find a way around. Understanding a bit better what 
happens in user-land would be very helpful, because giving people really good 
reasons to opt out of auto-upgrade and stick with the past is a bad idea...

 Synchronous networking on the UI thread is a no-go.

It's certainly an anti-pattern, given the thread constraints we have. But so is 
pushing big chunks of the real world to use old systems - because if they stop 
upgrading for one important problem, we revive the IE6 problem.

While I doubt we'll get a genuine flag day, it should be feasible to get a 
sense of who suffers from the change, and when we can break the web without 
causing too much serious fallout.

(My 2 kopecks)

chaals

Re: Push API draft update

[Chaals McCathieNevile]

On Tue, 28 Aug 2012 02:00:11 +0300, SULLIVAN, BRYAN L bs3...@att.com
wrote:


Hi Art,

Can you update the Webapps Publication Status page to add Eduardo as  
co-editor of the Push API draft?


Done - you should be able to do it yourselves actually, using your normal  
W3C login credentials.


We are looking forward to feedback on this update, with the goal of  
getting to FPWD by TPAC if possible.


OK, noted.

cheers

Chaals


Thanks,
Bryan Sullivan
+

From: EDUARDO FULLEA CARRERA e...@tid.es
Date: Wed, 22 Aug 2012 07:48:49 +0200
To: public-webapps (public-webapps@w3.org) public-webapps@w3.org
Cc: bs3...@att.com bs3...@att.com
Message-id: 492d97b30609c54fa9ff98b847ea5682b975989...@exclu2k7.hi.inet
Hi all,

Bryan Sullivan and myself have been working together on updating the  
Push API draft based upon feedback received and the work being driven by  
Mozilla and Telefonica to build a Push solution for Firefox OS (B2G).


You can find it at:  
http://dvcs.w3.org/hg/push/raw-file/default/index.html



This update does not intend to address yet each and every comment  
received, as some may deserve further discussions, but we think is a  
good step forward. We are looking forward to receiving your feedback.


Thanks and regards,
Eduardo Fullea
Telefonica Digital


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar  
nuestra política de envío y recepción de correo electrónico en el enlace  
situado más abajo.
This message is intended exclusively for its addressee. We only send and  
receive email on the basis of the terms set out at:

http://www.tid.es/ES/PAGINAS/disclaimer.aspx




--
Chaals - standards declaimer

Re: CfC: publish Widgets PC as a Proposed Edited Recommendation; deadline August 28

[Chaals McCathieNevile]

On Tue, 21 Aug 2012 14:20:34 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


Marcos would like to publish a Proposed Edited Recommendation [PER] of  
the Widget Packaging and XML Configuration spec [REC] to incorporate the  
spec's errata and this is a Call for Consensus to do so.


I support (as an individual).

cheers

Chaals

--
Chaals - standards declaimer