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  
 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,  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   
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' 
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  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  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   
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  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"  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  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  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  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  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 >:

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  



- 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 
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   
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 >
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 into the
>
> > Native App heartland and single-handedly alter the
development-tool and deployment
> > strategies for Mobile App vendors around the world.
>
> An even more powerful (but also ignored 

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



On Jan 8, 2016, at 7:12 PM, Johannes Wilm   
wrote:


On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin   
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:
  
(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 
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  
 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 technical difficulty to spec and 

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