Re: Holding WP meetings

2016-01-27 Thread Arthur Barstow

On 1/12/16 3:44 AM, Léonie Watson wrote:

Léonie, Ade, Chaals and Art (WP co-chairs)


I agree with everything Léonie said but, FTR, I resigned from this group 
a few weeks ago.


-Best wishes, AB




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

2015-12-02 Thread Arthur Barstow
Yves and Travis would like to publish a Candidate Recommendation of 
WebIDL Level 1 and this is a Call for Consensus to do so. The draft CR is:




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


-Thanks, ArtB





Fwd: Fingerprinting Guidance for Web Specification Authors

2015-12-01 Thread Arthur Barstow
Editors, All - please see "Fingerprinting Guidance for Web Specification 
Authors" 
 and 
reflect it in your spec, accordingly.


 Forwarded Message 
Subject:Fingerprinting Guidance for Web Specification Authors
Resent-Date:Thu, 26 Nov 2015 09:15:07 +
Resent-From:public-priv...@w3.org
Date:   Thu, 26 Nov 2015 09:14:30 +
From:   Christine Runnegar 
To: public-privacy (W3C mailing list) 



PING colleagues,

The Privacy Interest Group (PING) has published a Draft Group Note of 
Fingerprinting Guidance for Web Specification Authors.

You can find it here.

http://www.w3.org/TR/2015/NOTE-fingerprinting-guidance-20151124/

We will discuss next steps on our call next Thursday (3 December 2015 at UTC 
17).

Thanks to Nick.

Christine and Tara






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

2015-11-02 Thread Arthur Barstow
Hi Xiaoqian - this CfC passed so please go forward with PR publication 
as you proposed below. -Thanks!


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

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

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

1. ; this test failure 
(which passes on Firefox) can be considered more of a Web IDL implementation issue. 
The group believes it will get better over time as WebIDL compliance progresses.

2.  (which pass on 
Chrome);  (which pass on 
Chrome); The expected test results for these two test cases are not defined in the spec. 
The failures can be ignored as the spec move to PR.

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

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

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

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

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

Thanks.

--
xiaoqian

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





[admin] Minutes from Technical Plenary 28 October 2015

2015-11-02 Thread Arthur Barstow

On 11/2/15 1:04 AM, Coralie Mercier wrote:

Minutes from TPAC 2015 [1] are available:

  1) Plenary day (Public minutes)
 http://www.w3.org/2015/10/27-tpac-minutes.html


...

We encourage those who held break-out sessions to update the session 
grid with pointers to minutes or wiki notes.

  https://www.w3.org/wiki/TPAC/2015#Session_Grid


...



feedback survey (open through 22 November):
   https://www.w3.org/2002/09/wbs/35125/tpac2015-feedback/





Re: Notes from the future of HTML session at TPAC

2015-10-28 Thread Arthur Barstow

On 10/28/15 4:46 AM, Léonie Watson wrote:

Thanks to everyone for a useful and informative discussion. Minutes
available from the following palces:

Web:
http://www.w3.org/2015/10/28-html-minutes.html


Thanks!

Would someone with write privs to these minutes please commit to at 
least identifying the folks attributed in the minutes (f.ex. who is 
"DS")? It would also be useful if the "Present" list included any other 
attendee not directly attributed.


PLH, MikeSmith - would you please do this?

-Thanks, AB




[admin] Request for Spec Status and Plans; deadline Oct 25

2015-10-22 Thread Arthur Barstow

Hi WebPlatform/WebApps,

The To: list includes Editors that are not registered for next week's 
[f2f] meeting but others are welcome to reply ...


Editors - I expect next week's meeting will include the traditional 
"round robin" of spec status and plans. As such, if you are an Editor 
and will *not* attend the meeting, please provide a short status and 
plans for your spec (as Joshua did earlier this week for IDBv2).  More 
specifically, I think the main points of interest are: what, if 
anything, is blocking the spec's progression; what, if anything, do you 
need from the group/staff/chairs to help the spec make progress; what is 
the status and plan for the test suite; what is the rough timeline for 
the next publication; what data in [PubStatus] needs to be updated; etc.


I believe the following specs will not have Editor representation at the 
meeting:


* Clipboard API and events
* File API
* Filesystem API
* Gamepad
* Manifest for a web application
* Packaging on the web
* Pointer Lock
* Push API
* Quota Management API
* Screen Orientation API
* WebIDL (2nd Ed)
* Custom Elements
* HTML Imports

(Please feel free to change the Subject: header to include your spec's 
shortname f.ex. "[clipboard] Status".)


-Thanks, ArtB

[f2f] 


[PubStatus] 





[Spec Reviews] Internationalization Best Practices for Spec Developers

2015-10-20 Thread Arthur Barstow
The I18N WG group published a FPWD of "Internationalization Best 
Practices for Spec Developers". This document includes recommendations 
and best practices for spec writers regarding topics such as characters, 
language, text direction, etc.


I presume this document (or a document like this) would be used (useful) 
when a spec is getting "wide review" from an internationalization 
perspective.


[[


*Abstract*

This document provides a checklist of internationalization-related 
considerations when developing a specification. Most checklist items 
point to detailed supporting information in other documents. Where such 
information does not yet exist, it can be given a temporary home in this 
document. The dynamic page Internationalization Techniques: Developing 
specifications 
 is 
automatically generated from this document. *The current version is 
still a very early draft, and it is expected that the information will 
change regularly as new content is added and existing content is 
modified in the light of experience and discussion.


Introduction

*Developers of specifications need advice to ensure that what they 
produce will work for communities around the globe.


The Internationalization (i18n) WG tries to assist working groups by 
reviewing specifications and engaging in discussion. Often, however, 
such interventions come later in the process than would be ideal, or 
mean that the i18n WG has to repeat the same information for each 
working group it interacts with.


It would be better if specification developers could access a checklist 
of best practices, which points to explanations, examples and rationales 
where developers need it. Developers would then be able to build this 
knowledge into their work from the earliest stages, and could thereby 
reduce rework needed when the i18n WG reviews their specification.


This document contains the beginnings of a checklist, and points to 
locations where you can find explanations, examples and rationales for 
recommendations made.  If there is no such other place, that extra 
information will be added to this document. It is still early days for 
this document, and it may also be used to develop ideas and organize them.


You may prefer to use Internationalization Techniques: Developing 
specifications 
 
most of the time, since it uses JavasScript to help you more quickly see 
what's available and drill down to the information you need. (Where 
needed, it links to this or other documents.) There is also a 
non-dynamic version 
 of the 
document available.

]]

If you have any comments or feedbck about this doc, please use 
.


--






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

2015-10-20 Thread Arthur Barstow

On 10/19/15 1:52 PM, Xiaoqian Wu wrote:
The Web Platform WG intents to update the Latest Editor's Drafts of a 
set of HTML5 API specs, including WebStorage, WebWorkers, 
WebMessaging, Server-Sent Events and WebSockets. As no one in WPWG has 
committed to work on these specs, the latest EDs will be the WHATWG 
version.


Hi Xiaoqian,

Is the plan to gut the current ED of all content except a link to the 
WHATWG LS plus a message like "For the latest version of this 
specification use the WHATWG's Living Standard."?


-Thanks, AB





Re: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread Arthur Barstow

On 10/15/15 11:39 PM, Ryosuke Niwa wrote:
Can we discuss how we can integrate ES2015 modules into HTML on 
Tuesday, October 27th at TPAC?


Both Gecko and WebKit are basically done implementing ES6 module 
supports in their respective JavaScript engines but blocked on 
http://whatwg.github.io/loader/ to support in web contents.


Since my colleague who is interested in this topic cannot attend TPAC 
in person, it would be great if we could have it in Tuesday Morning 
(Monday evening in California).


Given the WPWG charter sets an expectation of collaboration with WHATWG, 
using meeting time at TPAC for this (or other mutual areas of interest) 
seems reasonable (assuming you can find a mutually acceptable day + time).


On the other hand, perhaps it would be useful to raise discussion topics 
on the list now (and not necessarily wait for TPAC).


-AB




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

2015-10-15 Thread 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




RfC: WebRTC 1.0; deadline Oct 23

2015-10-15 Thread Arthur Barstow
[ Stefan's e-mail hasn't been delivered to p-webapps so Dom asked me to 
forward it ]


 Forwarded Message 
Subject:Review of WebRTC 1.0 from Web Applications Working Group
Date:   Thu, 15 Oct 2015 09:05:57 +
From:   Stefan Håkansson LK 
To: 	art.bars...@gmail.com , 
cha...@yandex-team.ru , Web Applications Working 
Group WG (public-webapps@w3.org) 

CC: webrtc-cha...@w3.org 



Dear Web Applications Working Group,

The WebRTC Working Group is working toward publishing the WebRTC 1.0
specification to Candidate Recommendation and is thus seeking review
from a variety of groups on the document:

http://w3c.github.io/webrtc-pc/

We are particularly interested on feedback on the following aspects from
the Web Apps WG:
- proper usage of WebIDL; in particular, the WebRTC API has now a
dependency on the maplike<> construct which is not part of the
/TR/webidl-1/ spec at the moment,
- the DataChannel API which is heavily inspired from the WebSockets API,
- the overall approach to error handling,
- the instantiation of a worker to interact with a third party system,
as defined in the Identity section

We of course also welcome feedback on any other aspect of the specification.

Any such feedback received the week before TPAC would make it possible
for us to look at it during our F2F there and so would be appreciated.
We hope to transition request to Candidate Recommendation by the end of
this year.

If you have any comments, we prefer you submit them as Github issues:
https://github.com/w3c/webrtc-pc/issues
Alternatively, you can send your comments by email to public-web...@w3.org.

Thanks,

For the WebRTC co-chairs,
Stefan






Re: CR: Web Storage (Second Edition)

2015-10-14 Thread Arthur Barstow
Josh - FYI, I just added your comments as 
. -Thanks


On 7/2/15 9:38 PM, timeless wrote:

http://www.w3.org/TR/2015/CR-webstorage-20150609/


Particpate: [sic]
the event must have its key attribute initialised to the name of the key in 
question,

`initialized` [About 11,800,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of
`initialised` [About 553,000 results]


but require the user to authorise access to local storage areas.

`authorize` [About 80,100,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of `authorise` [About 6,960,000
results]


Alternatives that do not require a user-agent-wide per-origin script lock are 
eagerly sought after.

sought-after [1]


Each site has its own separate storage area.

area => areas | storage => local storage


("must", "should", "may", etc)

etc.


If the given key does exist in the list, and its value is not equal to value, 
then it must have its value updated to value. If its previous value is equal to 
value, then the method must do nothing.
if the methods did not throw an exception or "do nothing" as defined above

it'd be nice if the above sections underlined/otherwise styled `do nothing`.


User agents should always avoid deleting data while a script that could access 
that data is running.

consider a script which does:

var global_state = window.localStorage.getItem("value");
function uses_global_state() { if (global_state == 5) {  }}
window.setTimeout(uses_global_state, 200);

between the script's initial execution, and the firing of the timeout,
is the script considered to be `running`?


[1] http://dictionary.reference.com/browse/sought-after






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

2015-10-12 Thread Arthur Barstow

On 10/12/15 12:23 PM, Marcos Caceres wrote:

Please use separate repositories for each work item.


Yes, that is expectation -> all of the WG's specs will have their own 
repo (mostly are under github.com/w3c//) and my expectation 
is that any new spec the group starts would also have its own/separate repo.


(My expectation is the group's Github repo will mostly be used for admin 
type documents.)


-Thanks, AB





[admin] Web Platform WG is the new WebApps

2015-10-12 Thread Arthur Barstow

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.


The WPWG's "work mode" is documented in [WorkMode]. The group will 
continue the use of existing Github repos and mail lists for all 
technical work (new spec repos will be created if/when needed). Github 
will be used for bug/issue tracking (although a small number of WebApps' 
specs will continue to use Bugzilla, at least for a while). The group 
will continue the use of existing IRC channels (f.ex. #webapps).


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


To formally participate in WPWG, please ask your AC rep to register you 
via [Register] and if you are a member of WebApps as an Invited Expert, 
you must submit a new IE application [IE].


If you have any questions, concerns, etc., please let us know.

-Thanks, @AFBarstow

[Charter] 
[WorkMode] 
[Github] 
[Register] 
[IE] 






RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

2015-10-05 Thread Arthur Barstow

Hi All,

The Digital Publishing Interest Group [1] is seeking feedback regarding 
the use of Service Workers in their early draft (WIP) of "Portable Web 
Publications for the Open Web Platform", in particular section 5.1 
"General Architecture for Online/Offline Publications":


  

Please note Service Workers is new to the group and the above section 
contains "some preliminary discussion (assumptions?) about Service 
Workers" and the IG "want to make sure that we are headed in the right 
direction, and we have not made incorrect assumptions about Service 
Workers".


If you have any comments about their document please send them to the 
IG's public-digipub-ig list (archive [2]).


The IG welcomes discussion and feedback during their October 19 
conference call (if interested, please contact Tzviya) and/or during 
TPAC. Although WebApps meets on Monday and Tuesday and the IG meets on 
Thursday and Friday, if there is interest in a joint meeting, my 
understanding is that some set of IG members can meet during WebApps' 
meeting (see agenda at [3] for open slots).


Alex, Jake, Jungkee - perhaps you could meet with some of the IG members 
during the October 27 Service Worker meeting. WDYT?


-Thanks, AB

[1] 
[2] 
[3] 




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

2015-09-29 Thread Arthur Barstow

On 9/29/15 11:19 AM, Alan Stearns wrote:

On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of 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

Chaals, Art,

Do you have a time preference for this? We’ve got one vote for Tuesday 
afternoon, but I think Monday afternoon could work as well.


Based on earlier feedback, Chaals added a two hour slot on Tuesday 
afternoon 
.



I see that the WebApps WG has a larger person-estimate on the schedule page - 
if that translates to a larger room, the CSSWG people could troop over to you. 
Or we could host interested people in the CSSWG room. What do you think?


Meeting in WebApps room should be fine.

-AB



Ryosuke,

We now have “Shadow DOM Styling” on the CSSWG agenda for TPAC [1]. It would 
help if you could add more detail on the particular issues you’d like ironed 
out.

Thanks,

Alan

[1] https://wiki.csswg.org/planning/tpac-2015





Re: RfC: Service Workers

2015-09-23 Thread Arthur Barstow

On 9/23/15 1:46 PM, Phillips, Addison wrote:

Could you better define what "soon" means? More specifically, do you have a 
deadline for comments? I don't see any dates in the thread below.


I think four weeks is the `normal` expectation for `wide reviews`. 
However, the Editors and some active participants are having a related 
meeting during the TPAC 2015 meeting week so I think you should consider 
October 25 as the target comment date. If that date won't work for you, 
please let me know.


-Thanks, AB





Re: RfC: Service Workers

2015-09-21 Thread Arthur Barstow
Please use the Version 1 branch for this review: 
<https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/>


On 9/21/15 7:27 AM, Arthur Barstow wrote:
[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG 
(public-web-mobile), W3C Chairs (chairs),  Review Announce list 
(public-review-announce), Geolocation WG (public-geolocation) ]


The Editors and active contributors of Service Workers intend to 
publish a Candidate Recommendation soon (details below). Consequently, 
this is a Request for Comments by the WebApps group to seek wide 
review of the latest version of the spec:


<https://slightlyoff.github.io/ServiceWorker/spec/service_worker/>

The open issues for Version 1, and the spec's version history are [1] 
and [2], respectively.


If you have any comments, we prefer you submit them as Github issues 
[3]; otherwise, please send your comments to the public-webapps list 
[4] using a Subject: prefix of "[serviceworkers]".


-Thanks, AB

[1] 
<https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Version+1%22>

[2] <https://github.com/slightlyoff/ServiceWorker/commits/master>
[3] <https://github.com/slightlyoff/ServiceWorker/issues/>
[4] <https://lists.w3.org/Archives/Public/public-webapps/>


On 9/18/15 2:22 AM, Jungkee Song wrote:

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1].

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version 
include:

  - Register/Update/Unregister of a service worker registration
  - Handle fetch events
  - Fetch and Cache resources
  - Manage service worker clients
  - Communicate between a client and a service worker
  - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue 
tracker.)


On top of the above work, the contributors are now ready to continue 
with

the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon 
during which
we would like to focus on stabilizing the features (bug fix) and 
resolving

compatibility issues among multiple implementations.

For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m 


ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/


--
Jungkee Song
Samsung Electronics







Re: Normative references to Workers.

2015-09-21 Thread Arthur Barstow

On 9/21/15 5:54 AM, Ms2ger wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 11:05 AM, Xiaoqian Wu wrote:

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


OK, thanks (and please let me know when a draft CR is ready and then 
I'll start a CfC to publish it).



Why?


I think the rationale was mentioned in 
.


-AB





RfC: Service Workers

2015-09-21 Thread Arthur Barstow
[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG 
(public-web-mobile), W3C Chairs (chairs),  Review Announce list 
(public-review-announce), Geolocation WG (public-geolocation) ]


The Editors and active contributors of Service Workers intend to publish 
a Candidate Recommendation soon (details below). Consequently, this is a 
Request for Comments by the WebApps group to seek wide review of the 
latest version of the spec:




The open issues for Version 1, and the spec's version history are [1] 
and [2], respectively.


If you have any comments, we prefer you submit them as Github issues 
[3]; otherwise, please send your comments to the public-webapps list [4] 
using a Subject: prefix of "[serviceworkers]".


-Thanks, AB

[1] 


[2] 
[3] 
[4] 


On 9/18/15 2:22 AM, Jungkee Song wrote:

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1].

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version include:
  - Register/Update/Unregister of a service worker registration
  - Handle fetch events
  - Fetch and Cache resources
  - Manage service worker clients
  - Communicate between a client and a service worker
  - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue tracker.)

On top of the above work, the contributors are now ready to continue with
the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon during which
we would like to focus on stabilizing the features (bug fix) and resolving
compatibility issues among multiple implementations.

For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m
ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/


--
Jungkee Song
Samsung Electronics





Re: Service Workers 1 and Nightly

2015-09-18 Thread Arthur Barstow

On 9/18/15 2:22 AM, Jungkee Song wrote:

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1].

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version include:
  - Register/Update/Unregister of a service worker registration
  - Handle fetch events
  - Fetch and Cache resources
  - Manage service worker clients
  - Communicate between a client and a service worker
  - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue tracker.)

On top of the above work, the contributors are now ready to continue with
the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon during which
we would like to focus on stabilizing the features (bug fix) and resolving
compatibility issues among multiple implementations.


Hi Jungkee, All,

Thanks for this update!

Regarding the publishing plan above, the latest process document 
includes an expectation that before a CR is published the spec "has 
already received wide review" [1]. Although the group is free to 
determine the wide review "requirements" (see [2]), it can be useful to 
publish a new WD and use that WD as the basis of the wide review. It 
would also be possible to use an ED (perhaps a static snapshot) as the 
basis for the review. There is also a question about which group(s) we 
explicitly want to ask to review the spec.


What are your thoughts on the document (WD vs. ED snapshot) to use as 
the review?


Which groups do we ask to review? I presume at least TAG and Web Mobile 
IG. Are there others?


-Thanks, AB

[1] 
[2] 



For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m
ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/




Re: Normative references to Workers.

2015-09-16 Thread Arthur Barstow

On 9/16/15 4:47 AM, Mike West wrote:
Note that this is an issue that's going to come up for a number of 
WebAppSec specs 
(see https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8 
, 
for instance (and that spec also needs a few things that are missing 
from W3C's HTML, but are present in WHATWG's)). What I hear so far on 
this thread is that we should simply reference the WHATWG version of 
those specs, which seems like a reasonable thing to do.


Yes, for the scenario you mention, I agree with you.

The grey area is when a feature is defined by both a W3C WG and WHATWG. 
Because of the consortium's Patent Policy, I suspect consensus among 
consortium members is to use the W3C spec for normative references. 
However, if the W3C spec is no longer actively maintained by a WG, then 
normatively referencing a WHATWG spec would (IMHO) be appropriate and I 
think the Normative Reference Policy [NRP] supports such a scenario.


In this specific case, I don't believe anyone has committed to actively 
maintain W3C Web Workers. As such, WebApps - do we have a volunteer? 
Please let us know (or send me private e-mail if you prefer).


-Thanks, AB

[NRP] 




-mike

--
Mike West >, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, 
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der 
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine 
Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Tue, Sep 15, 2015 at 7:31 PM, Mike West > wrote:


The "Upgrade Insecure Requests" specification[1] references the
WHATWG HTML spec for the
"set up a worker environment settings object" algorithm[2], as the
Web Workers Candidate Recommendation from May 2012[3]
substantially predates the entire concept of a "settings object",
and because the WHATWG is the group where work on Workers seems to
be being done.

This referential choice was flagged during a discussion of
transitioning the Upgrade spec to CR, where it was noted that the
Web Workers editor's draft from May 2014 does contain the
referenced concept[4].

It seems appropriate, then, to bring the question to this group:
does WebApps intend to update the Workers draft in TR? If so, is
there a path forward to aligning the Workers document with the
work that's happened over the last year and a half in WHATWG?
Alternatively, does WebApps intend to drop work on Workers in
favor of the WHATWG's document?

It would be helpful if we could get some clarity here. :)

Thanks!

[1]: https://w3c.github.io/webappsec/specs/upgrade/
[2]:

https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
[3]: http://www.w3.org/TR/workers/
[4]: https://w3c.github.io/workers/

--
Mike West >, @mikewest

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







Reminder: [TPAC2015] Registration is now open for Oct 26-30 meeting week; deadline October 7

2015-09-07 Thread Arthur Barstow

On 6/10/15 9:28 PM, Arthur Barstow wrote:
Registration is now open for the October 26-30 Technical Plenary and 
all Working Group meeting week [TPAC], this year in Sapporo Japan:


   <https://www.w3.org/2002/09/wbs/35125/TPAC2015/>

WebApps (the entire group) will meet on Monday and Tuesday (October 26 
and 27). Registration for WebApps' meeting (as well as all other 
meetings and events that week) is mandatory. The group's meeting page 
including draft agenda is [Meeting].


The daily fee has increased to 85.00 USD per day.

The hotel discount for meeting participants expires September 26.

-ArtB

[TPAC] <http://www.w3.org/2015/11/TPAC/Overview.html>
[Meeting] <https://www.w3.org/wiki/Webapps/October2015Meeting>





Re: [charter] Request for Comments; deadline Sept 10

2015-09-02 Thread Arthur Barstow

Hi Josh,

Thanks for the feedback!

I filed  to record your 
comments regarding the draft charter. A pull request - especially for 
the the editorial comments (such as typos, missing links, etc.) - would 
be welcome.


Below I reply to a few of your comments.

-Thanks, ArtB

On 8/28/15 10:09 AM, timeless wrote:

Art wrote:

The proposal to merge the WebApps WG and the HTML WG has started a formal
review period that ends September 10:

   
IRC: active participants, particularly editors, regularly use the #webapps W3C 
IRC channel

is this channel intentionally inherited? I like it because it's shorter, but...


My initial expectation is the #webapps and #html-wg channels will 
continue to exist, even if just for the sake of taking meeting minutes. 
At the same time, there could be some advantages to just using one new 
channel. Regardless, for the purposes of the charter, perhaps it should 
be silent on any specific channel(s), i.e. the text should be something 
like:


[[
IRC: active participants, particularly editors, group staff and chairs, 
regularly use the group's IRC channel(s).

]]



(This Group is expected to combine into an all-guidelines group in 2016 2Q).

I don't understand this.


I think this is meant to be a placeholder because there is an 
expectation the User Agent Accessibility Guidelines Working Group will 
be reorganized/restructured into some new group. Assuming the referenced 
document would be updated accordingly if/when the group's reorg is done, 
I think it would be ok to delete this sentence.




The Group may use mailing lists. Subscription to these lists is open to the 
public, subject to W3C norms of behavior.

Member/IE seem to be forced to subscribe to an ML (at their designated
email address) which may be harmful to their mailbox's health. Is it
possible to arrange for the official ML used for such mandatory joins
be an unused ML and that all communications be done on other public
lists instead of the one that people are forced to join?
(Alternatively, could someone please fix this?)


Sorry, but I don't quite understand what you are after so if this 
important, please followup via 
 or file a new issue.






Re: [charter] What is the plan for Streams API?

2015-08-10 Thread Arthur Barstow



On 8/7/15 8:32 AM, Anne van Kesteren wrote:

On Fri, Aug 7, 2015 at 1:56 PM, Arthur Barstow art.bars...@gmail.com wrote:

Given this status, and in the absence of other feedback, I think the Streams
API should remain in WebApps' charter (at least for now). Then later, the
work may proceed (if there is still agreement an additional API would be
useful); otherwise, if there is agreement to stop the work, the work can be
stopped (and a WG Note published).

What would this additional API do?


Given Takeshi's status it seems premature to speculate.

The current [TR] is now mostly void of content although it might be good 
to gut it even more as well as to add a clear note that indicates that 
work has stopped and might not resume.


-AB

[TR] http://www.w3.org/TR/streams-api/




[charter] Need clarification about Fetching resources

2015-08-07 Thread Arthur Barstow
All - WebApps' draft charter (formally being reviewed by consortium 
Members through Sept 10 [1]) includes the following text about Fetching 
resources:


[[
http://www.w3.org/2015/07/web-platform-wg.html#network

Fetching resources
  The Group MAY also define the mechanisms to fetch resources using the 
HTTP protocol and its extensions.

]]

Yves, Xiaoqian, Philippe - would you please clarify your expectations 
for this deliverable and who requested it be added? As you know, 
historically, the group has only added deliverables to its charter if 
there is a draft specification the charter can reference as well as 
commitments from group members to work on the various stages of the process.


If others have expectations (and/or commitments) for this deliverable, 
please do speak up.


-Thanks, AB

[1] https://lists.w3.org/Archives/Public/public-new-work/2015Jul/0020.html



Re: W3C's version of XMLHttpRequest should be abandoned

2015-08-07 Thread Arthur Barstow

On 8/6/15 8:07 AM, Hallvord Reiar Michaelsen Steen wrote:
On Thu, Aug 6, 2015 at 9:15 AM, Anne van Kesteren ann...@annevk.nl 
mailto:ann...@annevk.nl wrote:


According to Art the plan of record is to still pursue
https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html 



And you correctly note

but
that was last updated more than a year ago. Last formally published
a year and a half ago.


And that is mostly my fault. I intended to keep the W3C fork up to 
date (at least up to a point), but at some point I attempted to simply 
apply Git patches from Anne's edits to the WHATWG version, and it 
turned out Git had problems applying them automatically for whatever 
reason - apparently the versions were already so distinct that it 
wasn't possible. Since then I haven't found time for doing the manual 
cut-and-paste work required, and I therefore think it's probably 
better to follow Anne's advice and drop the W3C version entirely in 
favour of the WHATWG version. I still like the idea of having a 
stable spec documenting the interoperable behaviour of XHR by a 
given point in time - but I haven't been able to prioritise it and 
neither, apparently, have the other two editors.


Jungkee, Julian - we would like your input, in particular whether or not 
you can still commit to helping with the tasks required to move XHR 
Level 1 along the Recommendation track.


Others - if you can commit to helping with the main tasks (editing, 
testing, implementation, etc.) for XHR L1, please let us know.


-Thanks, AB








Re: [charter] What is the plan for Streams API?

2015-08-07 Thread Arthur Barstow

On 8/5/15 10:53 AM, Takeshi Yoshino wrote:

+domenic

We've recently finished the ReadableStream part of the spec and 
experimenting integration with the Fetch API. Most of the spec is 
still unstable. I don't have bandwidth to maintain W3C version of the 
spec even briefly currently...


Hi Takeshi, All,

Given this status, and in the absence of other feedback, I think the 
Streams API should remain in WebApps' charter (at least for now). Then 
later, the work may proceed (if there is still agreement an additional 
API would be useful); otherwise, if there is agreement to stop the work, 
the work can be stopped (and a WG Note published).


-Thanks, AB



Takeshi

On Tue, Aug 4, 2015 at 11:13 PM, Arthur Barstow art.bars...@gmail.com 
mailto:art.bars...@gmail.com wrote:


On 7/30/15 8:46 AM, Arthur Barstow wrote:

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


The WebApps + HTML WG draft charter says the following about
WebApps' Streams API:

[[
Streams API https://w3c.github.io/streams-api/
   An API for representing a stream of data in web applications.
]]

I believe the previously agreed plan of record for this spec was
to create an API on top of https://streams.spec.whatwg.org/. Is
that still something this group wants to do, and if so, who can
commit to actually doing the work, in particular: editing,
implementation, and test suite?

If we no longer have committed resources for doing the above tasks
then this spec should be removed from the draft charter.

-Thanks, AB








Re: PSA: publish WD of WebIDL Level 1

2015-08-07 Thread Arthur Barstow

On 8/4/15 2:21 PM, Tab Atkins Jr. wrote:

On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow art.bars...@gmail.com wrote:

Hi All,

This is heads-up re the intent to publish a Working Draft of WebIDL Level
1 (on or around August 4) using Yves' document as the basis and a new
shortname of WebIDL-1:

https://ylafon.github.io/webidl/publications/fpwd-20150730.html

There is an open question about what should happen with TR/WebIDL/ (which
now is the 2012 Candidate Recommendation). One option is to serve it as
WebIDL-1. Another option is to replace it with the latest version of
Cameron's Editor's Draft. A third option is to make it some type of landing
page the user can use to load the various versions. Feedback on these
options is welcome and the default (if there are no non-resolvable issues)
is to go with option #2 (Yves' preference).

The CSSWG always points the non-leveled url to the latest spec.


This is also what PLH recommended be done and that seems reasonable to 
me. Thus:


TR/WebIDL/ - TR/WebIDL-2/
TR/WebIDL-1/
TR/WebIDL-2/

The L2 version (by Cameron and Boris [L2]) has not been published as a 
TR and if there no objections to proceeding as above, I will start 
working on making this all happen.


-Thanks, AB

[L2] http://heycam.github.io/webidl/







Re: W3C's version of XMLHttpRequest should be abandoned

2015-08-06 Thread Arthur Barstow

On 8/6/15 3:15 AM, Anne van Kesteren wrote:

According to Art
https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer
maintained.


WebApps agreed to stop work on the above (aka XHR L2) and published a WG 
Note in November 2014 [1].



It should redirect to https://xhr.spec.whatwg.org/
therefore.


Yes, that seems like a reasonable thing to do and if there are no 
non-resolvable objections to doing so, I will request that redirection 
is done.



According to Art the plan of record is to still pursue
https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html


Yes, that is still the group's plan of record (per the charter [2]).


but that was last updated more than a year ago. Last formally published
a year and a half ago. That causes significant confusion. More
importantly, implementations are implementing the new features in
https://xhr.spec.whatwg.org/ so nobody has much use for a Level 1.
Especially one that is not layered on top of Fetch and therefore
doesn't even work with service workers.


As is the case with all of the group's specs, if we no longer have 
sufficient interest and commitments (editing, implementation, testing, 
etc.) to continue to move a spec toward Recommendation status, then such 
a spec should be published as WG Note, work stopped and the charter 
updated to reflect that new status.


In the case of XHR L1, indeed the ED has not changed in over a year, 
although there is still some active work on the XHR test suite [3]. As 
far as I know, the editors are still committed to move that spec to 
Recommendation and unless I hear otherwise, I presume the consensus of 
the group is to continue to include XHR L1 in the group's charter. 
However, if the Editors and/or other participants recommend otherwise, I 
would appreciate it, if they would please voice their opinion.


(BTW, the test results data [4] was  last updated in October 2014. 
Perhaps it would be useful to get some new data. Any volunteer(s)?)


-Thanks, ArtB

[1] http://www.w3.org/TR/2014/NOTE-XMLHttpRequest2-20141118/
[2] http://www.w3.org/2014/06/webapps-charter.html
[3] https://github.com/w3c/web-platform-tests/tree/master/XMLHttpRequest
[4] http://jungkees.github.io/XMLHttpRequest-test/




[charter] What is the plan for Streams API?

2015-08-04 Thread Arthur Barstow

On 7/30/15 8:46 AM, Arthur Barstow wrote:

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


The WebApps + HTML WG draft charter says the following about WebApps' 
Streams API:


[[
Streams API https://w3c.github.io/streams-api/
   An API for representing a stream of data in web applications.
]]

I believe the previously agreed plan of record for this spec was to 
create an API on top of https://streams.spec.whatwg.org/. Is that 
still something this group wants to do, and if so, who can commit to 
actually doing the work, in particular: editing, implementation, and 
test suite?


If we no longer have committed resources for doing the above tasks then 
this spec should be removed from the draft charter.


-Thanks, AB





PSA: Arun Ranganathan is now an Invited Expert

2015-08-01 Thread Arthur Barstow
I am pleased to announce Arun is nowan Invited Expert in this group (he 
is no longer a member of WebApps on behalf of Mozilla).


Thanks Arun!

-AB









[charter] Request for Comments; deadline Sept 10

2015-07-30 Thread Arthur Barstow

Hi All,

The proposal to merge the WebApps WG and the HTML WG has started a 
formal review period that ends September 10:


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

If you have any comments about the proposal, please reply to this e-mail 
or [Github] before September 10.


Note Members may submit confidential feedback and such feedback is 
available in [Results].


-Thanks, AB

[Github] https://github.com/w3c/charter-html/issues
[Results] https://www.w3.org/2002/09/wbs/33280/webplatformwg-2015/results




RfC: LCWD of Tracking Compliance and Scope; deadline October 7

2015-07-16 Thread Arthur Barstow
WebApps has been asked to review the Tracking Protection group's July 14 
Last Call Working Draft of T/racking Compliance and Scope/:


  http://www.w3.org/TR/2015/WD-tracking-compliance-20150714/

If anyone in WebApps wants to propose an official group response, please 
do so ASAP, in reply to this e-mail so the group can discuss it.


Comments should be sent to public-tracking-comments @ w3.org (archive 
[1]) by October 7. Presumably, the group also welcomes silent review 
feedback such as I reviewed section N.N and have no comments.


-Thanks, ArtB

[1] https://lists.w3.org/Archives/Public/public-tracking-comments/


On 7/14/15 9:01 PM, Justin Brookman wrote:
The Tracking Protection Working Group published today (14 July 2015) a 
Last Call Working Draft of the Tracking Compliance and Scope 
specification, and we would like to ask for review comments from the 
following groups: Privacy Interest Group, WAI Protocols and Formats 
Working Group, Web Applications WG, Internationalization Working 
Group, and Device APIs WG. Of course, we welcome and encourage other 
reviews.


The draft is available here:
http://www.w3.org/TR/2015/WD-tracking-compliance-20150714/

Abstract:
This specification defines a set of practices for compliance with a 
user's Do Not Track (DNT) tracking preference to which a server may 
claim adherence.
Comments will be most useful in identifying particular problems with 
the specification that might inhibit adoption, where this 
specification fails to further goals of user privacy and user control, 
and whether this specification creates or does not otherwise resolve 
dependencies with other technical standards, practices, or processes.


The Last Call period ends 7 October 2015. Please send comments to the 
publicly-archived public-tracking-comme...@w3.org 
mailto:public-tracking-comme...@w3.org mailing list.


Thanks,
Carl Cargill, Justin Brookman, Matthias Schunter
Co-Chairs of the Tracking Protection WG

* Announcement of Last Call publication decision: 
https://lists.w3.org/Archives/Public/public-tracking/2015Jul/.html
* Last Call comment issues will be listed in a specific Tracker 
product: https://www.w3.org/2011/tracking-protection/track/products/8
* Patent disclosure information is available: 
http://www.w3.org/2004/01/pp-impl/49311/status





[html-imports] Syntax is mystic and daunting [Was: Re: HTML5 includes from within body]

2015-07-14 Thread Arthur Barstow

Hi Anatoly,

Perhaps it would be helpful if you expanded on specific issues with the 
HTML Imports syntax, either on this list or using an Issue 
https://github.com/w3c/webcomponents/labels/html-imports.


-Regards, ArtB

On 7/14/15 3:32 AM, anatoly techtonik wrote:

7 years ago the request to add body was blocked [1]

body
  include src = header.html/
  contentHTML5 body includes are unreadable/content
/body

The reason was that parser has to block while the document
is loading. Is that still actual for 2015?

From the user experience standpoint I find the barrier for
structuring HTML5 pages too high for newcomers. The simple
include could greatly help people to work with HTML5 more
easily and learn how to make their markup more readable.
Custom elements are awesome when you're a coder, but no
so awesome when you're just a journalist of designer.

Even as experienced non-JS coder I find the current syntax
for includes mystic and daunting [2]. The paradox is that for
HTML5 includes it is not possible to know about HTML alone
- need a good knowledge of CSS selectors, DOM and
JavaScript to read the website.

1. 
http://stackoverflow.com/questions/6875404/why-does-html5-not-include-a-way-of-loading-local-html-into-the-document
2. 
http://www.html5rocks.com/en/tutorials/webcomponents/imports/#usingcontent


Please, CC.
--
anatoly t.





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

2015-06-29 Thread Arthur Barstow
Yves, Xiaoqian, Mike - would one of you please do as Hayato requests 
below (and then notify him so he can move the Custom Elements bugs to 
Github)?


-Thanks, ArtB

On 6/25/15 2:49 AM, Hayato Ito wrote:
I am thinking about migrating Custom Element bugs[1] to Web Components 
GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the 
consistency.


Could someone turn off the automatic email to public-webapps for 
Custom Elements Bugs in the bugzilla so that we won't receive the mass 
flood of bugspam by marking the all bugs MOVED? I'm assuming the 
automatic email is on for public-webapps@.


If you have any concerns about migrating, let me know that.

[1] 
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1

[2] https://github.com/w3c/webcomponents/issues

On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com 
mailto:hay...@google.com wrote:


I totally agree. I'm really sorry for spamming. I forgot that
closing a bug would trigger sending a mail to public-webapps@. My bad.

I thought that a closing bug would notify only people who opted-in
to add themselves to a list of cc in each bug. That might be a
good opportunity for them to keep tracking of the bug status by
subscribing a migrated bug on GitHub Issues.

On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr.
jackalm...@gmail.com mailto:jackalm...@gmail.com wrote:

Note for the future (to you and editors of other specs in
WebApps):

Before doing this kind of mass bug editting, please turn off the
automatic email to public-webapps.  If you can't do that yourself,
Mike Smith can (at least, he's done it in the past).  That
prevents
the mass flood of bugspam from clogging up people's inboxes. ^_^

~TJ

On Tue, May 26, 2015 at 8:30 PM, Hayato Ito hay...@google.com
mailto:hay...@google.com wrote:
 PSA: I've finished the migration. All open bugs are now
marked as MOVED
 with a link to the corresponding GitHub issue.

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

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

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

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

 Please let me know if you have a concern.

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








[admin] WebEx has replaced Zakim

2015-06-29 Thread Arthur Barstow
The consortium's Zakim voice conference bridge has been replaced with 
WebEx [1][2][3]. The group's meeting page [4] has been updated to 
reflect this change and calendar invitations were created for the three 
reoccurring telecons:


1. D3E/UI Events https://www.w3.org/wiki/Webapps/Meetings#DOM_3_Events

2. Editing APIs https://www.w3.org/wiki/Webapps/Meetings#Editing_APIs

3. Web Components https://www.w3.org/wiki/Webapps/Meetings#Web_Components

If you have any Qs, issues, etc. please let us know.

-Thanks, AB

[1] https://www.w3.org/2006/tools/wiki/WebExBestPractices
[2] https://www.w3.org/2006/tools/wiki/WebExFAQ
[3] https://www.w3.org/2006/tools/wiki/InstallingWebEx
[4] https://www.w3.org/wiki/Webapps/Meetings



PSA: publishing new WD of Service Workers on June 25

2015-06-23 Thread Arthur Barstow
This is an announcement of the intent to publish a new Working Draft of 
Service Workers on June 25 using the following document as the basis:


http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150625/

If anyone has any major concerns with this proposal, please speak up 
immediately; otherwise the WD will be published as proposed.


For some implementation data for this spec, see 
http://caniuse.com/#feat=serviceworkers.


-Thanks, ArtB



[admin] Use public-patent-issues list for all patent discussions [Was: Need a list for Extract Widget patent]

2015-06-17 Thread Arthur Barstow
All - the public-patent-issues list [1] was created for patent related 
discussions such as patent disclosures. Please use [1] (which isn't, 
AFAIK, associated with any specific group) for *all* patent related 
discussion and do not use any of WebApps' lists for such purposes.


-Thank you, AB

[1] https://lists.w3.org/Archives/Public/public-patent-issues/

On 5/28/15 5:23 PM, Arthur Barstow wrote:
Rigo, Wendy, Jeff - I don't think it is appropriate to use WebApps' 
public-webapps list regarding Web Components vs Extract Widget 
patent [1]. What list should be used?


(FYI, Aymeric Vitte's original disclosure was forwarded to the list 
[1], and Aymeric's followups are [2] and [3]).


-Thanks, AB

[1] 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0692.html
[2] 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0697.html
[3] 
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0782.html








Re: PSA: Web Components vs Extract Widget patent

2015-06-17 Thread Arthur Barstow

On 6/17/15 5:29 PM, Aymeric Vitte wrote:

As directed in [1], if anyone wants to reply to this thread, please use 
the public-patent-issues list and do *not* reply on public-webapps.


-Thank you, AB

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



Re: [Clipboard] Web API for clipboard changes.

2015-06-16 Thread Arthur Barstow

On 6/16/15 6:58 AM, James M. Greene wrote:


Please share it with the rest of the group. Thanks!



Agree. Kelvin - please do.

-Thanks, AB





Re: [Clipboard] Web API for clipboard changes.

2015-06-11 Thread Arthur Barstow

On 6/2/15 4:05 PM, Kelvin Poon wrote:


Hi public-webapps


We are exploring a new web API for content to be notified of clipboard 
changes and would like to discuss it here.



The problem

For certain classes of web apps, it is necessary to determine when new 
clipboard contents have been set, e.g. in order to fetch and display 
them, to update context menus, or synchronize the content with another 
application or device.



The problem is that the web standard currently provides no explicit 
notifications when new content is copied from another application to 
the clipboard.  As a result, these web apps typically re-fetch the 
clipboard every time they regain focus, and only act on the contents 
if they have changed since last time (e.g. passing it to a remote 
system, updating context menu, etc).  This polling mechanism is 
generally inefficient, especially when the clipboard contains a large 
image file.



We currently have interest from Citrix and Chrome Remote Experience 
teams in improving Chrome's clipboard support.



The proposal

Google propose to update the W3C Clipboard API and events 
specification http://www.w3.org/TR/clipboard-apis/with an 
onClipboardChangedevent on the document object.  The user agent should 
only signal the event if


1. a frame re-gains focus AND

2. the clipboard has changed since it last had focus.


In addition, the user agent should not signal clipboard change events 
while a frame has focus.  This will relieve the web app from the 
burden of filtering out notifications in response to clipboard changes 
generated by the app itself.



We think this new API will avoid fetching large clipboard content 
repeatedly and unnecessarily for clipboard changes.


Does the community think this API would be useful?



Hallvord, All - do you have any feedback for Kevlin?

We can go into more details and work on a detailed design together if 
the community is interested.




Kelvin, if there is a resource that includes details, please let us 
know. (I suppose another option is a Pull Request but it might make 
sense to first wait for some feedback from the group.)


-Thanks, ArtB






Re: [ime-api] [blink-dev] Removing IME API code from Blink

2015-06-11 Thread Arthur Barstow

On 5/28/15 2:04 PM, Travis Leithead wrote:

That sounds good to me (working the UI challenges for IME together with 
grammar/spell checking). Is this a direction the current IME spec could 
take--possibly with a big refactor to consider dropping the ClientRect 
exposure--or would it be better to publish as Note the current approach and 
start a new spec?

Perhaps it doesn't really matter as the above is a process question, and what 
is really needed is someone to start suggesting some concrete proposals 
here--I've been pretty much ignoring this spec for the past year, and I don't 
see that changing in the near future. It's still something I'd like to see 
moved forward, I just don't believe I have the time to move it substantially 
forward at the present moment :)


Given this, it seems like the SoTD section should include some type of 
large-ish warning/note that include text along the lines of `no one is 
actively working on this spec nor its implementation` + `help wanted`. 
Also, if the spec's [Issues] and [Bugs]  haven't properly captured the 
ClientRect exposure issue, perhaps one should be created (and/or the 
spec updated to reflect this).


On the other hand, if you propose to formally stop work on the spec as 
it is now, then it would be appropriate to have a CfC to publish a WG 
Note (and if/when there is a firm commitment to do some type of followup 
work, a new spec can be created).


WDYT?

-Thanks, ArtB

[Issues] https://github.com/w3c/ime-api/issues
[Bugs] 
https://www.w3.org/Bugs/Public/buglist.cgi?component=IME%20APIlist_id=57282product=WebAppsWGresolution=---



-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Wednesday, May 27, 2015 7:00 PM
To: Travis Leithead
Cc: Arthur Barstow; public-webapps
Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink



On May 27, 2015, at 11:46 AM, Travis Leithead travis.leith...@microsoft.com 
wrote:

I believed the use-cases for avoiding UI clashes between site-driven 
auto-complete lists and IME auto-complete boxes is still a valid use case, and 
I think the spec is still valid to try to push to recommendation. However, I'd 
also like to follow up on usage of the ms- prefixed API so that I can get an 
idea of what its real usage is.

I agree avoiding UI clashes between auto-completions of IME and web page is a great use 
case but I'm not convinced that exposing ClientRect for IME is the right API as many Web 
developers aren't even aware of UI challenges IME imposes. For example, a similar UI 
challenge emerges when dealing with auto-corrections in grammar/spell checking features 
as well.  It would be ideal if IME and spell/grammar corrections are handled in a similar 
manner so that Web apps supporting either feature will just work with both 
features.

- R. Niwa






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

2015-06-10 Thread Arthur Barstow

On 6/10/15 5:32 AM, Anne van Kesteren wrote:

On Wed, Jun 10, 2015 at 11:22 AM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:

Developing web browsers and their specs means paranoia should be part of
your job description.
It is a concern and I'm not sure how to solve it.

Well we should be able to allow some things here. Either we verify
that it is an image or we only allow images that are exported from
canvas or some such... But yeah, passing arbitrary bytes seems bad,
there needs to be some amount of validation.


Are you suggesting/proposing new normative requirement(s) in the spec 
proper and/or new text in the security/privacy considerations [1]?


[1] 
https://w3c.github.io/clipboard-apis/#other-security-and-privacy-considerations




[TPAC2015] Registration is now open for Oct 26-30 meeting week; deadline October 7

2015-06-10 Thread Arthur Barstow
Registration is now open for the October 26-30 Technical Plenary and all 
Working Group meeting week [TPAC], this year in Sapporo Japan:


   https://www.w3.org/2002/09/wbs/35125/TPAC2015/

WebApps (the entire group) will meet on Monday and Tuesday (October 26 
and 27). Registration for WebApps' meeting (as well as all other 
meetings and events that week) is mandatory. The group's meeting page 
including draft agenda is [Meeting].


The daily fee has increased to 85.00 USD per day.

The hotel discount for meeting participants expires September 26.

-ArtB

[TPAC] http://www.w3.org/2015/11/TPAC/Overview.html
[Meeting] https://www.w3.org/wiki/Webapps/October2015Meeting



Re: RfC: Style Sheet for Technical Reports; deadline July 7

2015-06-04 Thread Arthur Barstow

On 5/29/15 8:00 PM, Joshua Bell wrote:
Let me start off proposing for the group and if I'm outvoted I can 
send personal feedback. :)


Thanks Joshua!

All - in the absence of any contrary opinions, I propose we submit 
Joshua's comments on behalf of WebApps. However, we still have several 
weeks for the comment period so if you have any feedback, please send it 
by July 3


-Thanks, ArtB



Standard stylesheet: http://www.w3.org/TR/IndexedDB/
My tweaked styles: https://w3c.github.io/IndexedDB/
CSS changes are visible at:
https://github.com/w3c/IndexedDB/blob/gh-pages/index.html#L79

Differences:

* Impose a maximum body width and center to improve readability on 
wide windows +
* Increase body line spacing to ~1.45 to improve readability of dense 
text +

* Size of inline code text should match body text size +
* Reduce vertical space taken up by note/Issue blocks +
* Size of block code samples should be at least slightly closer to 
body size

* Introduce standard switch dl style

These were (of course!) inspired by some of the newer, more readable 
(IMHO) specs styles floating about.


The items marked with + above seem to already be addressed Fantasai's 
http://dev.w3.org/csswg/css-text-3/ (i.e. I'm borrowing from the right 
people...)


Other notes:

* Current IDL blocks are pretty garish; I think they could use a 
little *less* syntax highlighting.
* In dense algorithmic steps, the underlines on linked terms become 
fairly cluttered since nearly every word is a reference. I suppose the 
alternatives are color (?), style (italics is used for variables), or 
weight (used for definitions). Ideas?




On Fri, May 29, 2015 at 4:21 AM, Arthur Barstow art.bars...@gmail.com 
mailto:art.bars...@gmail.com wrote:


Fantasai is leading an effort to improve the style sheet used for
new Technical Reports. She created a survey [1] that is supposed
to reflect the entire group's feedback but she also welcomes
individual feedback via the spec-prod list [2], using the 10
questions below as a guide.

If you have individual feedback, please send it directly to [2],
using a Subject: prefix of [restyle] by July 7.

If you have feedback you propose be submitted on behalf of the
group, please reply to this e-mail, by July 3 so I  have time to
collate the feedback and submit it by the deadline.

In the absence of any feedback on behalf of the group, my reply to
the survey will be that the existing style sheet meets the We Can
Live With It Test.

-Thanks, ArtB

[1] https://www.w3.org/2002/09/wbs/1/tr-design-survey-2015/
[2] https://lists.w3.org/Archives/Public/spec-prod/

On 5/27/15 2:02 PM, fantasai wrote:

We are updating the style sheets for W3C technical reports.
  This year's styling project is minor improvements and cleanup,
  not major changes, so the look and feel will remain
substantially the same.
  Also, please note that since the publication system work is
ongoing,
  no markup will be harmed in the development of the 2016
style sheet.
  Given that, however, we hope to improve the quality and
consistency
  of styles used across W3C.

  This survey must be completed by each working group on behalf of
  the members of that working group (i.e not only on behalf of
the chairs).

  1. What group are you answering on behalf of?

  2. Paste in URLs to a representative sample (1-3 links) of
your specs.
 If styling differs substantially between /TR and your
editor's drafts,
 please link to both versions.

  3. What spec pre-processor(s) does your WG use?

  4. Paste in URLs to any WG-specific style sheets you use.

  5. What do you like about your current styles?

  6. What do you dislike about your current styles?

  7. Paste in URLs to any parts of your spec that are
stylistically complex
 or tricky, and we should therefore be careful not to
screw up.

  8. The new styles will include rules for rendering data
tables. These
 will be opt-in by class name, and rely heavily on good markup
 (use of THEAD, TBODY, COLGROUP, scope attributes, etc.).
 See examples [1][2][3].
 Paste in URLs to a sampling of any data tables you are using
 so that we can try to accommodate those in the styling,
if practical.

 [1] http://www.w3.org/TR/css-text-3/#white-space-property
 [2] http://www.w3.org/TR/css3-align/#overview
 [3]
http://www.w3.org/TR/css3-writing-modes/#logical-to-physical

  9. The CSSWG has made a number of minor improvements to the
existing spec
 styles, which we might just adopt wholesale. [4]
 Please comment on what you like/dislike about these styles

[charter] Discussions about HTMLWG charter and WebApps

2015-06-01 Thread Arthur Barstow

Hi All,

If you are interested in the charter of HTMLWG, please note there are 
related discussions in [GH], and see in particular:


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

Note WebApps is implicated, with at least three different proposals to 
replace WebApps and HTMLWG with four new Working Groups: [Ade], [PLH] 
and [Robin].


If you have any comments, please participate directly in GH (f.ex. using 
[Issues]), although I think it would be ok to also use this list.


-Thanks, ArtB

[GH] https://github.com/w3c/charter-html
[Ade] 
http://github.adrianba.net/webstandards/HTML-innovation-vs-maintenance#to-recharter-a-html-working-group-or-not

[PLH] https://github.com/w3c/charter-html/issues/14#issuecomment-103618353
[Robin] https://github.com/w3c/charter-html/issues/14
[Issues] https://github.com/w3c/charter-html/issues







RfC: Style Sheet for Technical Reports; deadline July 7

2015-05-29 Thread Arthur Barstow
Fantasai is leading an effort to improve the style sheet used for new 
Technical Reports. She created a survey [1] that is supposed to reflect 
the entire group's feedback but she also welcomes individual feedback 
via the spec-prod list [2], using the 10 questions below as a guide.


If you have individual feedback, please send it directly to [2], using a 
Subject: prefix of [restyle] by July 7.


If you have feedback you propose be submitted on behalf of the group, 
please reply to this e-mail, by July 3 so I  have time to collate the 
feedback and submit it by the deadline.


In the absence of any feedback on behalf of the group, my reply to the 
survey will be that the existing style sheet meets the We Can Live With 
It Test.


-Thanks, ArtB

[1] https://www.w3.org/2002/09/wbs/1/tr-design-survey-2015/
[2] https://lists.w3.org/Archives/Public/spec-prod/

On 5/27/15 2:02 PM, fantasai wrote:

We are updating the style sheets for W3C technical reports.
  This year's styling project is minor improvements and cleanup,
  not major changes, so the look and feel will remain substantially 
the same.

  Also, please note that since the publication system work is ongoing,
  no markup will be harmed in the development of the 2016 style sheet.
  Given that, however, we hope to improve the quality and consistency
  of styles used across W3C.

  This survey must be completed by each working group on behalf of
  the members of that working group (i.e not only on behalf of the 
chairs).


  1. What group are you answering on behalf of?

  2. Paste in URLs to a representative sample (1-3 links) of your specs.
 If styling differs substantially between /TR and your editor's 
drafts,

 please link to both versions.

  3. What spec pre-processor(s) does your WG use?

  4. Paste in URLs to any WG-specific style sheets you use.

  5. What do you like about your current styles?

  6. What do you dislike about your current styles?

  7. Paste in URLs to any parts of your spec that are stylistically 
complex

 or tricky, and we should therefore be careful not to screw up.

  8. The new styles will include rules for rendering data tables. These
 will be opt-in by class name, and rely heavily on good markup
 (use of THEAD, TBODY, COLGROUP, scope attributes, etc.).
 See examples [1][2][3].
 Paste in URLs to a sampling of any data tables you are using
 so that we can try to accommodate those in the styling, if 
practical.


 [1] http://www.w3.org/TR/css-text-3/#white-space-property
 [2] http://www.w3.org/TR/css3-align/#overview
 [3] http://www.w3.org/TR/css3-writing-modes/#logical-to-physical

  9. The CSSWG has made a number of minor improvements to the existing 
spec

 styles, which we might just adopt wholesale. [4]
 Please comment on what you like/dislike about these styles,
 as demonstrated in the CSS3 Text Editor's Draft. [5]

 [4] http://dev.w3.org/csswg/default.css
 [5] http://dev.w3.org/csswg/css-text-3/

  10. Is there anything else we should consider?

  Individual members of the WG, W3C Staff, and others are also welcome
  to send feedback to spec-p...@w3.org. Please be sure to use [restyle]
  in the subject line.

Based on the responses and the feedback and suggestions of any 
individuals
who want to help, I will create a new spec stylesheet for 2016 
publications
and (as Eric suggested) a short sample spec showing off these styles. 
There

should be plenty of time to comment on the specifics and to incorporate a
few more rounds of feedback before the last call period at TPAC; 
however

I do need to understand the WGs' requirements up front, hence the survey.

~fantasai






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

2015-05-29 Thread Arthur Barstow

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

Hi Art, and all,

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


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


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


-Thanks, ArtB




Thanks.

—
xiaoqian


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

Hi All,

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

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

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

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

-Thanks, ArtB

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






[admin] Need a list for Extract Widget patent [Was: Re: PSA: Web Components vs Extract Widget patent]

2015-05-28 Thread Arthur Barstow
Rigo, Wendy, Jeff - I don't think it is appropriate to use WebApps' 
public-webapps list regarding Web Components vs Extract Widget patent 
[1]. What list should be used?


(FYI, Aymeric Vitte's original disclosure was forwarded to the list [1], 
and Aymeric's followups are [2] and [3]).


-Thanks, AB

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0692.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0697.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0782.html





[ime-api] Fwd: [blink-dev] Removing IME API code from Blink

2015-05-27 Thread Arthur Barstow
Below is a proposal to remove the experimental IME API implementation 
from Blink.


Is there sufficient interest from other implementers to keep this spec 
on the TR track or should we formally stop work on it and publish a WG Note?


Travis, All, WDYT?

-Thanks, ArtB

 Forwarded Message 
Subject:[blink-dev] Removing IME API code from Blink
Date:   Wed, 27 May 2015 14:15:15 +0900
From:   Takayoshi Kochi ko...@chromium.org
To: blink-dev blink-...@chromium.org



IME API, experimentally implemented a while ago, has been under 
experimental flag

but we haven't got enough signal from users to get it out of experimental.
Therefore I'm thinking of removing the code from Blink (and Chromium) 
for code health.
This is not an intent to deprecate, and if we get enough interest we may 
readd/reimplement

the spec.

We don't have real-world usage number of IME API.  Even though IE11 
implements
IME API, theirs are ms- prefixed (while Blink's is unprefixed) and some 
of their API are available
under Metro mode only due to their implementation details, so we guess 
the number of

people who depend on the existence of the API is quite small.

Any objections?

spec: http://www.w3.org/TR/ime-api/
bug: crbug.com/226938 http://crbug.com/226938
chromestatus: https://www.chromestatus.com/features/6366722080636928
Intent to implement: 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/sxuEbPN6pPY/QpNxXgJyoScJ 
https://groups.google.com/a/chromium.org/forum/#%21msg/blink-dev/sxuEbPN6pPY/QpNxXgJyoScJ

caniuse: http://caniuse.com/#cats=JS%20API
--
Takayoshi Kochi
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org 
mailto:blink-dev+unsubscr...@chromium.org.






PSA: Web Components vs Extract Widget patent

2015-05-20 Thread Arthur Barstow

Hi All,

For those interested in Web Components, please note I received a related 
e-mail titled Web Components vs Extract Widget patent. I forwarded 
this e-mail (which has an attachment) to the www-archive list:


https://lists.w3.org/Archives/Public/www-archive/2015May/0008.html

Please do NOT discuss the specifics of the referenced patent on 
public-webapps.


Yves, Xiaoqian - will this information result in the formation of a 
Patent Advisory Group [PAG]? If yes, when will that PAG be launched?


-Thanks, ArtB

[PAG] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exception





PSA: HTML5 Web Messaging is a W3C Recommendation

2015-05-19 Thread Arthur Barstow

Congratulations to Ian and all the contributors!

On 5/19/15 12:53 PM, Coralie Mercier wrote:
It is my pleasure to announce that HTML5 Web Messaging is published as 
a W3C Recommendation

http://www.w3.org/TR/2015/REC-webmessaging-20150519/

This specification defines two mechanisms for communicating between 
browsing contexts in HTML documents.


All Members who responded to the Call for Review [1] of the Proposed 
Recommendation supported the publication of this specification as a 
W3C Recommendation, or abstained.


Please join us in thanking the Web Applications Working Group [2] for 
their achievement.


This announcement follows section 8.1.2 [3] of the W3C Process Document.

For Tim Berners-Lee, Director;
Philippe Le Hegaret, Interaction Domain Lead,
Xiaoqian Wu  Yves Lafon, Team Contacts;
Coralie Mercier, Acting Head of W3C Marketing  Communications

[1] 
https://lists.w3.org/Archives/Member/w3c-ac-members/2015AprJun/0004.html

[2] https://www.w3.org/2008/webapps/
[3] 
http://www.w3.org/2005/10/Process-20051014/acreview.html#ACReviewAfter







[admin] Getting notification about WebApp's web-platform-tests activity?

2015-05-18 Thread Arthur Barstow

Hi All,

Dom has a tool that could be used to notify one of WebApps' mail lists 
when a wg-webapps label is applied to something (f.ex an Issue or PR) 
in the web-platform-tests repo.


Is this something we want to use? If yes, which list? 
public-webapps-github seems like the closest match but I public-webapps 
could also be used (and if that resulted in too much e-mail we could 
revisit the list). (I suppose other options would be to resurrect 
public-webapps-testsuite or create a new list.)


WDYT?

-Thanks, AB

 Forwarded Message 
Subject:Per-WG notification of pull requests
Resent-Date:Mon, 18 May 2015 14:43:50 +
Resent-From:public-test-in...@w3.org
Date:   Mon, 18 May 2015 16:43:01 +0200
From:   Dominique Hazael-Massieux d...@w3.org
To: public-test-in...@w3.org



Hi,

I maintain a tool that some groups use to mirror part of their github
activity to a mailing list:
  https://github.com/dontcallmedom/github-notify-ml/

I've recently tweaked that tool to make it capable of filtering based on
label, and furthered tweaked this today to make it possible to be
notified when a given issue or pull request gets labeled with a
particular label.

When applied to web-platform-tests, this makes it possible to notify a
mailing list when a given pull request gets automatically labeled with
its WG label.

I've applied this to the WebRTC Working Group:
https://lists.w3.org/Archives/Public/public-webrtc-testsuite/2015May/0001.html

If you belong to other groups who would like a similar set up, please
get in touch.

I'm also interested in ideas as to where that option should be documented.

Dom







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

2015-05-14 Thread Arthur Barstow

Hi All,

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


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


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


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


-Thanks, ArtB

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



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

2015-05-12 Thread Arthur Barstow

Hi All,

Thanks for this analysis Xiaoqian.

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


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


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


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


-Thanks, ArtB

On 5/8/15 12:58 PM, Xiaoqian Wu wrote:

Thanks for bringing this up, Anssi.

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


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

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


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


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

- This is a normative change and should be accepted in the second edition.

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


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


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


Thanks.

—
xiaoqian

[1] https://www.diffchecker.com/npgkwj7d
[2] https://github.com/w3c/web-platform-tests/pull/1784
[3] 
https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html
[4] 
https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17
[6] 
https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror

[7] https://github.com/w3c/webstorage
[8] https://www.diffchecker.com/dkbtofsi
[9] http://www.w3.org/2014/Process-20140801/#rec-modify

On 2015-4-30, at 8:02pm, Kostiainen, Anssi 
anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote:


Hi,

On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com 
mailto:art.bars...@gmail.com wrote:


On 4/21/15 5:39 AM, Kostiainen, Anssi wrote:

Hi,

Is there a plan to publish an errata to sync the Web Storage Rec 
[1] with the latest? I counted 8 commits cherry picked into the 
Editor's Draft since Rec [2].


If no errata publication is planned, I'd expect the Rec to clearly 
indicate its status.


Re the priority of this issue, is this mostly a truth and beauty 
process-type request or is this issue actually creating a 
problem(s)? (If the later, I would appreciate it, if you would 
please provide some additional context.)


It was creating problems. Our QA was confused which spec was the 
authoritative one, and wrote tests (additional ones, on top of the 
w-p-t tests) against the Rec spec. These tests failed since Blink is 
compliant with the latest, not the Rec. More context at: 
https://crosswalk-project.org/jira/browse/XWALK-3527


The main thing blocking the publication of errata is a commitment 
from someone to actually do the work. I also think Ian's

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

2015-05-12 Thread Arthur Barstow

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


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


-AB





Re: Stability of Widget DigSig

2015-05-11 Thread Arthur Barstow

On 5/11/15 4:23 AM, Andrew Twigger wrote:

I expect that removing the statement from the namespace document
will resolve the concerns of ATSC and CEA members.


Andrew - the warning has been removed.

-ArtB




Thank-you for your quick response to this request.

Andrew Twigger

-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com]
Sent: 08 May 2015 13:55
To: Andrew Twigger
Cc: Marcos Caceres; Frederick Hirsch; public-webapps@w3.org
Subject: Re: Stability of Widget DigSig

Andrew - seeing no objections from the group to removing the
Implementers ... statement from [NS] document, if that statement is
removed, does that address your concern?

-Thanks, ArtB

[NS] http://www.w3.org/ns/widgets-digsig/





Re: Stability of Widget DigSig

2015-05-08 Thread Arthur Barstow

[ + Marcos and Frederick ]

Hi Andrew,

The group stopped working on XML Digital Signature for Widgets several 
years ago and there is no plan to resume work (except to process errata 
as required).


Marcos, Frederick - this spec's namespace document includes the 
following statement:


[[
http://www.w3.org/ns/widgets-digsig/

Implementers should be aware that this document is not stable.
]]

Any objections from you or anyone else to remove this statement?

-Thanks, ArtB

On 5/7/15 5:55 AM, Andrew Twigger wrote:


ATSC and CEA are developing standards that include the ability to 
download digital signed applications. Their current specifications 
reference the W3C Recommendation for XML Digital Signature for Widgets 
(18 April 2013).  However, the associated Widgets Digital Signature 
Namespace (http://www.w3.org/ns/widgets-digsig/) contains a statement 
that “Implementers should be aware that this document is not stable.” 
which has raised questions as to the stability and suitability of 
referencing Widget DigSig.  The alternative would be to reference 
XAdES with the C and T forms to allow for the inclusion of timestamp 
and certificate revocation information which are not included in 
Widget DigSig.


I would be pleased to receive any information regarding the stability 
of Widget DigSig and whether referencing XAdES would provide a better 
alternative.


Thank-you,

Andrew Twigger






Re: Stability of Widget DigSig

2015-05-08 Thread Arthur Barstow

On 5/8/15 8:47 AM, Anders Rundgren wrote:

On 2015-05-08 14:32, Frederick Hirsch wrote:

no objection, the referenced document is a Recommendation, isn't it?

http://www.w3.org/TR/widgets-digsig/


This seems to be a rather theoretical discussion:

https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget


FYI, the usage of widget in widgets-digsig is not at all related to 
the use of widget in the MDN resource reference above.


-AB





Re: Stability of Widget DigSig

2015-05-08 Thread Arthur Barstow
Andrew - seeing no objections from the group to removing the 
Implementers ... statement from [NS] document, if that statement is 
removed, does that address your concern?


-Thanks, ArtB

[NS] http://www.w3.org/ns/widgets-digsig/

On 5/8/15 7:14 AM, Arthur Barstow wrote:

[ + Marcos and Frederick ]

Hi Andrew,

The group stopped working on XML Digital Signature for Widgets several 
years ago and there is no plan to resume work (except to process 
errata as required).


Marcos, Frederick - this spec's namespace document includes the 
following statement:


[[
http://www.w3.org/ns/widgets-digsig/

Implementers should be aware that this document is not stable.
]]

Any objections from you or anyone else to remove this statement?

-Thanks, ArtB

On 5/7/15 5:55 AM, Andrew Twigger wrote:


ATSC and CEA are developing standards that include the ability to 
download digital signed applications. Their current specifications 
reference the W3C Recommendation for XML Digital Signature for 
Widgets (18 April 2013).  However, the associated Widgets Digital 
Signature Namespace (http://www.w3.org/ns/widgets-digsig/) contains a 
statement that “Implementers should be aware that this document is 
not stable.” which has raised questions as to the stability and 
suitability of referencing Widget DigSig.  The alternative would be 
to reference XAdES with the C and T forms to allow for the inclusion 
of timestamp and certificate revocation information which are not 
included in Widget DigSig.


I would be pleased to receive any information regarding the stability 
of Widget DigSig and whether referencing XAdES would provide a better 
alternative.


Thank-you,

Andrew Twigger








[widgets] implementation data [Was: Re: Stability of Widget DigSig]

2015-05-08 Thread Arthur Barstow

On 5/8/15 8:52 AM, Anders Rundgren wrote:

On 2015-05-08 14:50, Arthur Barstow wrote:

On 5/8/15 8:47 AM, Anders Rundgren wrote:

On 2015-05-08 14:32, Frederick Hirsch wrote:

no objection, the referenced document is a Recommendation, isn't it?

http://www.w3.org/TR/widgets-digsig/


This seems to be a rather theoretical discussion:

https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget


FYI, the usage of widget in widgets-digsig is not at all related to
the use of widget in the MDN resource reference above.


Just for my understanding, is the W3C Widget TR generally supported then?


See http://dev.w3.org/2006/waf/widgets/imp-report/

-AB





RfC: Subresource Integrity; deadline May 26

2015-05-07 Thread Arthur Barstow
The WebAppSec community requests review of Subresource Integrity 
http://w3c.github.io/webappsec/specs/subresourceintegrity/, specifically:


[[
Fetch Integration
Privacy and Security Considerations
CORS interactions
Future Considerations regarding broader integration into other HTML elements
Extensibility
]]

If you have any feedback, please send it to public-webappsec @ w3.org 
([archive]), using a [SRI] Subject: prefix, by May 26.


-Thanks, AB

[archive] https://lists.w3.org/Archives/Public/public-webappsec/

 Forwarded Message 
Subject:Subresource Integrity - review requested
Resent-Date:Thu, 07 May 2015 19:33:16 +
Resent-From:public-review-annou...@w3.org
Date:   Thu, 7 May 2015 19:30:48 +
From:   Brad Hill hillb...@fb.com
To: public-review-annou...@w3.org public-review-annou...@w3.org



Hello,

The Web Application Security Working Group requests review of the following 
specification before 2015-05-26:

   Subresource Integrity
   http://w3c.github.io/webappsec/specs/subresourceintegrity/

The group requests feedback via public-webapp...@w3.org with [SRI] in subject 
line

This specification defines a mechanism by which user agents may verify that a fetched resource has 
been delivered without unexpected manipulation.  Specifically, this version uses hashed metadata 
annotations delivered as a new integrity attribute of the script and link 
tags.

Level 1 is intended as a minimum viable release, targeting what the group 
believes to be a few high-value use cases with the most manageable requirements, in order 
to learn how such a mechanism will interact with the large scale architecture of the Web, 
before proceeding to additional features and scenario targets.

The group has specifically asked for feedback on the following:


Fetch Integration
Privacy and Security Considerations
CORS interactions
Future Considerations regarding broader integration into other HTML elements
Extensibility


Sincerely,

Brad Hill
Co-chair, WebAppSec WG






PSA: Martin Thomson joins Push API Editor team

2015-05-01 Thread Arthur Barstow

Hi All,

We are pleased to announce Mozilla's Martin Thomson has agreed to be a 
co-Editor of the Push API spec https://w3c.github.io/push-api/.


Eduardo and Bryan are no longer able to continue as active editors and 
we thank them for their past contributions and we hope their active 
participation will resume.


-Cheers, Team WebApps





[selectors-api] How to mark TR version as obsolete/superseded? [Was: Re: Obsolete Document]

2015-04-28 Thread Arthur Barstow

On 3/26/15 8:30 AM, Gulfaraz Yasin wrote:

Hi

It has come to my notice that the following document

http://www.w3.org/TR/selectors-api/#resolving-namespaces

is obsolete.


Hi Gulfaraz,

Thanks for your e-mail and sorry for the slow reply.


I was directed to it's page from one of StackOverflow's answers and 
after following up a bit I've been informed that the above document is 
obsolete.



Yes, this is true.


It would be very helpful if there was a notice on the page that 
informed it's visitors of the same.



Yes, I agree. I think the principle of least surprise implies the 
document at w3.org/TR/selectors-api/ should be gutted of all technical 
content and a reference to the DOM spec [DOM] (which supersede Selectors 
API) should be added (as well as a clear statement work on selectors-api 
has stopped and its features/APIs are superseded by [DOM]). However, I 
suspect the consortium's publication processes might not permit that.


Xiaoqian, Yves - can we do as I suggest above? If not, what is your 
recommendation re making sure people understand work on selectors-api 
has stopped and it is superseded by [DOM]?


-Thanks, AB

[DOM] http://www.w3.org/TR/dom/





Re: Web Storage Rec errata?

2015-04-28 Thread Arthur Barstow

On 4/21/15 5:39 AM, Kostiainen, Anssi wrote:

Hi,

Is there a plan to publish an errata to sync the Web Storage Rec [1] with the 
latest? I counted 8 commits cherry picked into the Editor's Draft since Rec [2].

If no errata publication is planned, I'd expect the Rec to clearly indicate its 
status.



Hi Anssi,

Re the priority of this issue, is this mostly a truth and beauty 
process-type request or is this issue actually creating a problem(s)? 
(If the later, I would appreciate it, if you would please provide some 
additional context.)


The main thing blocking the publication of errata is a commitment from 
someone to actually do the work. I also think Ian's automatic push of 
commits from the WHATWG version of Web Storage to [2] was stopped a long 
time ago so there could be additional changes to be considered, and the 
totality of changes could include normative changes. Did you check for 
these later changes?


If you, or anyone else, would like to help with this effort, that would 
be great. (If it would be helpful, we could create a new webstorage repo 
under github/w3c/, work on the errata in that repo and redirect the 
CVS-backed errata document to the new repo.)


Personally, I think putting errata in a separate file - as opposed to 
putting changes directly into [1] - is mostly make work and fails the 
principle of least surprise. However, I think the consortium's various 
processes preclude us from doing what I consider is the right thing.


-Thanks, ArtB



Thanks,

-Anssi

[1]http://www.w3.org/TR/webstorage/
[2]http://dev.w3.org/cvsweb/html5/webstorage/Overview.html





PSA: publishing new WD of Push API on April 30

2015-04-27 Thread Arthur Barstow
This is an announcement of the intent to publish a new WD of Push API on 
April 30 using the following document as the basis:


  https://w3c.github.io/push-api/publish/TR.html

(The sequence diagram is not found when the above document is loaded but 
the diagram will be available in the WD version.)


If anyone has any major concerns with this proposal, please speak up 
immediately; otherwise the WD will be published as proposed.


-Thanks, ArtB



Re: Minutes of Shadow DOM meeting

2015-04-25 Thread Arthur Barstow

On 4/25/15 8:45 AM, Bjoern Hoehrmann wrote:

* cha...@yandex-team.ru wrote:

http://www.w3.org/2015/04/25-webapps-minutes.html


See http://www.w3.org/2015/04/24-webapps-minutes.html.


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





Re: Minutes of Shadow DOM meeting

2015-04-25 Thread Arthur Barstow

On 4/25/15 8:45 AM, Bjoern Hoehrmann wrote:

* cha...@yandex-team.ru wrote:

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

Perhaps a document in some kind of open format would be a better medium
than some proprietary application with unclear stability policies that
does not work in my browser.


I just copied the data in the above document to the meeting's agenda page:

https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting#Summary_of_Contentious_Bits



PSA: publishing new WD of UI Events and D3E Keyboard specs April 28/30

2015-04-24 Thread Arthur Barstow
Thanks to Xiaoqian, the UI Events and the two D3E Keyboard Events 
code/key Values specs have been moved to Github and we plan to publish 
them next week using the following Draft WDs as the basis:


https://w3c.github.io/uievents/TR.html
https://w3c.github.io/DOM-Level-3-Events-code/TR.html
https://w3c.github.io/DOM-Level-3-Events-key/TR.html

If anyone has any major concerns about this, please reply right away. 
uievents is expected to be published on April 28 and the other two on or 
around April 30.


PRs are welcome and encouraged (the HTML validator reports a lot of 
errors for all of the ReSpec resolved versions of the specs)!


A few notes about these specs:

* The permissions of the specs' now obsolete Github repository will be 
set to read-only.


* After the open Bugzilla bugs are copied to Github Issues (or the last 
open Bugzilla bug is closed), the specs' Bugzilla component will be 
marked `Historical` and set to read-only.


Lastly, since this will be the second WD of UI Events since it was 
renamed, perhaps the (formerly DOM Level 3 Events) part of the title 
should now be removed https://github.com/w3c/uievents/issues/1. Any 
objections to that?


-Thanks, AB





Re: PSA: publishing new WD of UI Events and D3E Keyboard specs April 28/30

2015-04-24 Thread Arthur Barstow

On 4/24/15 11:33 AM, Gary Kacmarcik (Кошмарчик) wrote:
On Fri, Apr 24, 2015 at 7:26 AM, Arthur Barstow art.bars...@gmail.com 
mailto:art.bars...@gmail.com wrote:



* The permissions of the specs' now obsolete Github repository
will be set to read-only.


s/Github/Mercurial/ ?


Duh; what Gary said ;-).




Re: [admin] Registration for April 24 2015 Web Components f2f meeting; deadline April 10

2015-04-21 Thread Arthur Barstow

On 2/24/15 3:37 PM, Arthur Barstow wrote:
The registration page for the April 24 Web Components f2f meeting at 
Google's Mount View CA office is now open:


https://www.w3.org/2002/09/wbs/42538/webcomponents-042015/

The meeting/agenda page is: 
https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting.


The meeting page now includes Building and Room data as well as directions:

https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting#Meeting_Logistics

Thanks Chris!





[admin] Updating our /TR stylesheets

2015-04-18 Thread Arthur Barstow
Below is an announcement about a project to provide a modern design to 
future technical reports published by the W3C i.e. updating the 
stylessheet used for Technical Report 
https://github.com/w3c/tr-design/blob/gh-pages/README.md .


If you have any feedback, please use 
https://github.com/w3c/tr-design/issues (and do not reply to this thread).


 Forwarded Message 
Subject: Updating our /TR stylesheets
Date: Thu, 16 Apr 2015 08:53:21 -0400
From: Philippe Le Hegaret p...@w3.org
To: spec-prod spec-p...@w3.org

I'd like to find a path for W3C to update our /TR style sheets and since
we weren't able to do it so far, here is a radical change on how to do so.

First, since it's too complex to change documents that have been
published in the past, we must not try to do it. It has the
simplification that we're breaking the consistency of style between all
W3C documents but it allows us more forward.

Second, we shouldn't assume we need one new style and be done. Instead,
I'd like to enable ourselves to have progressive enhancements over the
years. It will also avoid having everyone trying to squeeze their own
ideas between of a once-in-a-lifetime chance to change the styles. To
make it easier on the tooling, we also need something predictable. So,
I'd like to propose that we allow ourselves to update the /TR style
sheets once per year, on January 1. All documents published in that year
would  have to use the style, ensuring some consistency. Note that it
doesn't imply we have to change the style every year, but it gives us an
opportunity if we want to.

I added a set of guidelines and an hopefully simple process to do it:
  https://github.com/w3c/tr-design/blob/gh-pages/README.md

Feedback is welcome.

Philippe







PSA: publishing new WD of Clipboard APIs and events on April 21

2015-04-16 Thread Arthur Barstow

Hi All,

A new Working Draft publication of Clipboard APIs and events is planned 
for April 21 using the following version as the basis:


  https://w3c.github.io/clipboard-apis/TR.html

If anyone has any major concerns about this, please reply right away.

A few notes about this spec:

* This spec is now using Github https://github.com/w3c/clipboard-apis/ 
and the ED is now https://w3c.github.io/clipboard-apis/. PRs are 
welcome and encouraged.


* The permissions of the spec's now obsolete CVS repository will be set 
to read-only.


* After the open Bugzilla bugs [1] are copied to Github Issues (or the 
last open Bugzilla bug is closed), the spec's Bugzilla component will be 
marked `Historical` and set to read-only.


-Thanks, ArtB

[1] 
https://www.w3.org/Bugs/Public/buglist.cgi?component=Clipboard%20API%20and%20eventslist_id=54780product=WebAppsWGresolution=---






Re: PSA: publishing new WD of File API on April 21

2015-04-15 Thread Arthur Barstow

On 4/15/15 10:23 AM, Arthur Barstow wrote:

* This spec is now using Github https://w3c.github.io/FileAPI/


That repo is actually https://github.com/w3c/FileAPI/.



PSA: publishing new WD of File API on April 21

2015-04-15 Thread Arthur Barstow

Hi All,

A new Working Draft publication of File API is planned for April 21 
using the following version as the basis:


 https://w3c.github.io/FileAPI/TR.html

If anyone has any major concerns about this, please reply right away.

A few notes about this spec:

* This spec is now using Github https://w3c.github.io/FileAPI/ and the 
ED is https://w3c.github.io/FileAPI/Overview.html. PRs are welcome and 
encouraged. (I think it would be useful if this spec used ReSpec and if 
anyone can help with that port, please do contact me.)


* The permissions of the spec's now obsolete CVS repository will be set 
to read-only.


* After the Editors copy the open Bugzilla bugs [1] to Github Issues (or 
the last open Bugzilla bug is closed), the spec's Bugzilla component 
will be marked `Historical` and set to read-only.


-Thanks, ArtB

[1] 
https://www.w3.org/Bugs/Public/buglist.cgi?component=File%20APIlist_id=54713product=WebAppsWGresolution=---






Re: PSA: publishing new WD of File API on April 21

2015-04-15 Thread Arthur Barstow

On 4/15/15 3:09 PM, Tab Atkins Jr. wrote:

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote:

* This spec is now using Github https://w3c.github.io/FileAPI/ and the ED
is https://w3c.github.io/FileAPI/Overview.html. PRs are welcome and
encouraged. (I think it would be useful if this spec used ReSpec and if
anyone can help with that port, please do contact me.)

This was actually already next on my list of specs to Bikeshed, as
soon as I finish DOM (which I'm doing as I type this).  WebIDL-heavy
specs benefit a lot from being Bikeshedded, so all the IDL definitions
get properly marked up for the linking database. ^_^


:-).

Arun , Jonas - unless we otherwise from you, we'll assume this is `all 
good` from your perspective.


-Thanks, AB





Re: PSA: publishing new WD of File API on April 21

2015-04-15 Thread Arthur Barstow

On 4/15/15 5:56 PM, Tab Atkins Jr. wrote:

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote:

  https://w3c.github.io/FileAPI/TR.html

Note that this version appears to be based off the Overview-FAWD.xml
file in the CVS repo, which hasn't been touched in 5 years.  The file
Overview-FA.xml is much more recent and appears to be what the
current file at http://www.w3.org/TR/FileAPI/ is based on (note the
relative positions of the FileList and Blob sections - in
Overview-FA.xml and the current TR, FileList comes first).  I suspect,
then, that the file you're referencing is out-of-date and shouldn't be
used.


I didn't use either of those files but Overview.html, as directed by Arun.

(He told me he stopped editing the Overview-FA.xml file some type ago).

-Thanks, AB





Re: PSA: publishing new WD of File API on April 21

2015-04-15 Thread Arthur Barstow

On 4/15/15 3:54 PM, Martin Thomson wrote:

On 15 April 2015 at 07:26, Arthur Barstow art.bars...@gmail.com wrote:

* This spec is now using Github https://w3c.github.io/FileAPI/


That repo is actually https://github.com/w3c/FileAPI/.


Since the most obvious github.io link is currently broken, would it
make sense to move Overview.html to index.html?


That would be fine with me (we've already done that for a few specs 
we've recently migrated to Github) and it seems like a reasonable `best 
practice` to follow.



  Does the name
Overview.html hold special meaning?


We'll have to ask the Editors and I believe Jonas is OOO now and Arun is 
part-time. I filed an Issue so they can provide some input and if I 
don't hear otherwise from them, I'll plan to make the filename change 
before the new WD is published.


-Thanks, AB






RfC: LCWD of Media Capture and Streams; deadline May 15

2015-04-15 Thread Arthur Barstow

Hi All,

WebApps has been asked to review and submit comments for the April 14 
Last Call Working Draft of WebRT and DAP's Media Capture and Streams spec:


http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/

WebApps is specifically mentioned re the overall usage of Web IDL and 
the definition of error handling.


If anyone in WebApps wants to propose an official group response, please 
do so ASAP, in reply to this e-mail so the group can discuss it.


Comments should be sent to public-media-capture @ w3.org [1] by May 15. 
Presumably, the groups also welcome silent review type data such as I 
reviewed section N.N and have no comments.


-Thanks, ArtB

[1] https://lists.w3.org/Archives/Public/public-media-capture/


On 4/15/15 1:31 AM, Stefan Håkansson LK wrote:

The WebRTC and Device APIs Working Groups request feedback on the Last
Call Working Draft of Media Capture and Streams, a JavaScript API that
enables access to cameras and microphones from Web browsers as well as
control of the use of the data generated (e.g. rendering what a camera
captures in a html video element):
http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/

The groups have identified the following other W3C Working Groups as
likely sources of feedback:

- HTML Working Group, especially the HTML Media Task Force, as our API
extends the HTMLMediaElement interface and defines a new type of media
input via MediaStream

- WebApps Working Group, especially on the overall usage of Web IDL and
the definition of error handling
Audio Working Group, as the Web Audio API builds upon the MediaStream
interface

- WAI Protocol and Formats Working Group, especially on the impact of
the user consent dialog and the applicability of the indicators of
device usage in assistive tools

- Web and TV Interest Group, as the manipulation of media input can be
relevant to some of their use cases (e.g. glass to glass)

- Web App Security Working Group, especially on our links between
secured origins and persistent permissions, and our current policy with
regard to handling access to this powerful feature

- Web Security Interest Group, especially on our security considerations
Privacy Interest Group, as access to camera and microphone has strong
privacy implications

- Technical Architecture Group, for an overall review of the API,
especially the introduction of the concept of a IANA registry-based
constraints system, the use of promises, and our handling of persistent
permissions

We naturally also welcome feedback from any other reviewers.

The end of last call review for this specification is set to May 15
2015; should that deadline prove difficult to meet, please get in touch
so that we can determine a new deadline for your group.

As indicated in the document, comments should be sent to the
public-media-capt...@w3.org mailing list.

Thanks,

Frederick Hirsch, Device APIs Working Group Chair,
Harald Alvestrand and Stefan Hakansson, WebRTC Working Group Chairs and
Media Capture Task Force Chairs





PSA: Seeking feedback on W3C's Modern Tooling project

2015-04-14 Thread Arthur Barstow

[Bcc public-openw3c ]

Hi All,

In case you missed it, last February, Robin, Philippe and others (see 
[1] for a list of contributors) started a project to capture the state 
of the discussion about modernising the tooling that supports the making 
of W3C standards.


The working document is http://w3c.github.io/modern-tooling/ and the 
repository is https://github.com/w3c/modern-tooling.


This is an important effort so if you have feedback, please use the 
project's Issues system https://github.com/w3c/modern-tooling/issues 
or submit a Pull Request https://github.com/w3c/modern-tooling/pulls.


-Thanks, ArtB

P.S. PSA = Public Service Announcement

[1] https://github.com/w3c/modern-tooling/graphs/contributors




Re: WebIDL Plans

2015-04-13 Thread Arthur Barstow

On 4/12/15 2:44 AM, Anne van Kesteren wrote:

On Fri, Apr 10, 2015 at 2:53 PM, Yves Lafon yla...@w3.org wrote:

We are planning to move WebIDL forward to REC, here is the plan to achieve that:

Who is we? Apparently this wasn't even discussed with the editors.


I consider Yves' posting [1] as a followup to a related started at the 
end of last year [2]. Naturally, feedback on [1] is welcome from all 
(Boris, Cameron, Everyone).


-Thanks, ArtB

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0078.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0515.html





PSA: publishing new WD of Gamepad on April 14

2015-04-09 Thread Arthur Barstow

Hi All,

A new Working Draft publication of Gamepad is planned for April 14 using 
the following version as the basis:


  https://w3c.github.io/gamepad/publish/gamepad.html

If anyone has any major concerns about this, please reply right away.

A few notes about this spec:

* This spec is now using Github https://github.com/w3c/gamepad and the 
ED is https://w3c.github.io/gamepad/gamepad.html. PRs are welcome and 
encouraged.


* The permissions of the spec's now obsolete Hg repository will be set 
to read-only.


* After Ted copies the open Bugzilla bugs to Github, the spec's Bugzilla 
component will be marked `Historical` and set to read-only.


-Thanks, ArtB




[gamepad] UA applied mapping cannot be escaped [Was: Re: PSA: publishing new WD of Gamepad on April 14]

2015-04-09 Thread Arthur Barstow

On 4/9/15 8:28 AM, Florian Bösch wrote:
If my reading is correct, there is no provision to escape a mapping 
that the UA would apply? I've observed in the past that the mappings 
can go quite awry. Would it be possible to offer a way toggle off 
mapping on a gamepad?


Hi Florian - I was about to ask you to file issues for this and I see 
that you already beat me to it :-) 
(https://github.com/w3c/gamepad/issues/).


-Thanks, Art





Reminder: [admin] Registration for April 24 2015 Web Components f2f meeting; deadline April 10

2015-04-07 Thread Arthur Barstow

On 2/24/15 3:37 PM, Arthur Barstow wrote:
The registration page for the April 24 Web Components f2f meeting at 
Google's Mount View CA office is now open:


https://www.w3.org/2002/09/wbs/42538/webcomponents-042015/

The meeting/agenda page is: 
https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting.


Please register by April 10.

-Thanks, AB





PSA: publishing new WD of Input Method Editor (IME) API on April 9

2015-04-07 Thread Arthur Barstow

Hi All,

A new Working Draft publication of IME API is planned for April 9 using 
the following version as the basis:


http://w3c.github.io/ime-api/TR.html

If anyone has any major concerns about this, please reply right away.

A few notes about this spec:

* Travis is now the sole Editor of this spec. Many thanks to Travis for 
agreeing to take the lead and to the previous Editors Takayoshi Kochi, 
Kenji Baheux and Hironori Bono.


* This spec is now using Github https://github.com/w3c/ime-api/ and 
the ED is http://w3c.github.io/ime-api/Overview.html.


* The permissions of the spec's now obsolete Hg repository will be set 
to read-only. The spec's Bugzilla component will be marked `Historical` 
and set to read-only and all open bugs will be closed after they are 
copied as Github issues.


-Thanks, ArtB




PSA: publishing new WD of Quota Management API on April 9

2015-04-06 Thread Arthur Barstow

Hi All,

A new Working Draft publication of Quota Management API is planned for 
April 9 using the following version as the basis:


  https://w3c.github.io/quota-api/TR.html

If anyone has any major concerns about this, please reply right away.

Note this spec is now using Github https://w3c.github.io/quota-api/. 
The permissions of the spec's Hg repository will be set to read-only and 
the spec's Bugzilla component will be marked `Historical` and set to 
read-only.


-Thanks, ArtB





Re: [websockets] Test results available

2015-03-26 Thread Arthur Barstow

On 3/26/15 1:02 PM, Boris Zbarsky wrote:

On 3/26/15 10:51 AM, Arthur Barstow wrote:

* All results http://w3c.github.io/test-results/websockets/all.html

* 2 passes 
http://w3c.github.io/test-results/websockets/less-than-2.html


Overall these results are pretty good: 97% of the 495 tests have two or
more passes.


Arthur,

It looks like the tests that are failed with an Error as opposed to 
a Fail are not being counted in the 2 passes list?  For example, 
http://www.w3c-test.org/websockets/Create-Secure-valid-url-array-protocols.htm 
is not in that list even though everyone fails it.


Is that an accident, or a purposeful decision?


I'm glad you reported this Boris! Indeed the less-than-2 table is 
missing several tests that have 4 Errors + 1 Timeout. I don't know why 
they aren't included. Such tests are also missing from the other 
automatically generated file complete-fails [cf] (which is a proper 
subset of the 2 table).


I'm not sure of the reason(s) to omit such errors from the less-than-2 
table or the complete-fail table. It could be a bug in the tool 
[wptreport] and perhaps there is a switch that would include the missing 
errors. I also vaguely recall a discussion about pervasive errors being 
a relatively strong indicator of a test case bug. Perhaps Robin can help 
here; Robin?


Regardless, we will also need to investigate all of these other failures 
missing from 2.


-Thanks, AB

[cf] http://w3c.github.io/test-results/websockets/complete-fails.html
[wptreport] https://github.com/darobin/wptreport




[websockets] Test results available

2015-03-26 Thread Arthur Barstow
Earlier today I ran the Web Sockets tests on Chrome 41, Chrome/Canary 
43, FF Nightly 39, IE 11, and Opera 12 and pushed the results to the 
test-results repo:


* All results http://w3c.github.io/test-results/websockets/all.html

* 2 passes http://w3c.github.io/test-results/websockets/less-than-2.html

Overall these results are pretty good: 97% of the 495 tests have two or 
more passes.


If anyone is willing to help with the failure analysis, that would be 
very much appreciated.


Odin, Simon - for the purposes of evaluating these results and the 
Candidate Recommendation (exit criteria), should the Opera data be included?


-Thanks, ArtB





Re: I18N comments on Manifest for Web applications

2015-03-25 Thread Arthur Barstow

On 3/24/15 3:07 PM, Arthur Barstow wrote:

On 3/24/15 10:21 AM, Richard Ishida wrote:
is it possible to send mail to www-internatio...@w3.org each time 
someone adds somethign to the github issue? (this is the list where 
we track and discuss issues).


if so, i see no real difference between using github or bugzilla – 
our process is designed to cope with both bugzilla and email based 
comments (though it would normally be better to start with the right 
one rather than switch part way, so changing the SOD would indeed help).


we should also ensure, however, that the titles of the issues and any 
associated notification mails always contain the i18n-issue-xxx 
string that will allow us and tracker to locate information for a 
given thread.


FYI, I just added [i18n-issue-NNN] to the title of the five Github 
issues Ken created ([GH]) for the issues Addison submitted (and 
created the I18N-WG label for them).


I don't know if the GH repo can be configured such that all activity 
for just these issues can be automagically Cc'ed to www-international 
but I know Dom has done so related work so I will follow up with him 
separately.


FYI, Dom configured GH as requested:

[[
I've updated github-notify-ml to support that feature [1], configured it 
for this particular repo and tested it [2].


Dom

1. 
https://github.com/dontcallmedom/github-notify-ml/compare/6ce58740823bf5ae3b239fa7ae411e0fc5a11ab3...20b523ab2cf12b8489e13f1241df2471ea650858
2. 
https://lists.w3.org/Archives/Public/www-international/2015JanMar/0186.html


]]

Thanks Dom!

-ArtB




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

2015-03-24 Thread Arthur Barstow

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

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

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

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

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

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

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


Thanks for this info Jonas.

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

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



Hi,

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


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


hth


Yes, that is indeed helpful. Thanks Sigbjorn!

-ArtB





Re: I18N comments on Manifest for Web applications

2015-03-24 Thread Arthur Barstow

On 3/24/15 10:21 AM, Richard Ishida wrote:
is it possible to send mail to www-internatio...@w3.org each time 
someone adds somethign to the github issue? (this is the list where we 
track and discuss issues).


if so, i see no real difference between using github or bugzilla – our 
process is designed to cope with both bugzilla and email based 
comments (though it would normally be better to start with the right 
one rather than switch part way, so changing the SOD would indeed help).


we should also ensure, however, that the titles of the issues and any 
associated notification mails always contain the i18n-issue-xxx string 
that will allow us and tracker to locate information for a given thread.


FYI, I just added [i18n-issue-NNN] to the title of the five Github 
issues Ken created ([GH]) for the issues Addison submitted (and created 
the I18N-WG label for them).


I don't know if the GH repo can be configured such that all activity for 
just these issues can be automagically Cc'ed to www-international but I 
know Dom has done so related work so I will follow up with him separately.


The boiler plate asking for feedback via GH and the Status section 
asking for feedback via p-webapps is certainly suboptimal. AFAIK, 
PubRules mandates the comment list. If we can't get that restriction 
lifted, I recommend the relevant text in the SotD clearly state using GH 
for comments/bugs/issues is *strongly preferred* and the list should 
only be used as a `last resort`.


(FYI, all of WebApps' GH activity is mirrored to [p-w-gh], thus all I18n 
activity can be found in the archive, f.ex. via [i18n].)


-Thanks, ArtB

[GH] https://github.com/w3c/manifest/labels/I18N-WG
[p-w-gh] https://lists.w3.org/Archives/Public/public-webapps-github/
[i18n] 
https://www.w3.org/Search/Mail/Public/search?keywords=hdr-1-name=subjecthdr-1-query=i18nindex-grp=Public_FULLindex-type=ttype-index=public-webapps-github





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

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


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


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


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


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


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


-Thanks, ArtB

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

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






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

2015-03-12 Thread Arthur Barstow

Hi All,

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


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


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


The following redirects will also be made:

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


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


-Regards, ArtB

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


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


a) Stop work on this spec

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

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

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


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


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


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


-Thanks, AB

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





FYI: IETF Token Binding Working Group formed (tokbind)

2015-03-11 Thread Arthur Barstow

FYI (the IETF formally started the Token Binding Working Group).

 Forwarded Message 
Subject: WG Action: Formed Token Binding (tokbind)
Date: Wed, 11 Mar 2015 15:13:05 -0700
From: The IESG iesg-secret...@ietf.org
Reply-To: i...@ietf.org
To: IETF-Announce ietf-annou...@ietf.org
CC: tokbind WG unbeara...@ietf.org

A new IETF working group has been formed in the Security Area. For
additional information please contact the Area Directors or the WG
Chairs.

Token Binding (tokbind)

Current Status: Proposed WG

Chairs:
  John Bradley ve7...@ve7jtb.com
  Leif Johansson le...@sunet.se

Assigned Area Director:
  Stephen Farrell stephen.farr...@cs.tcd.ie

Mailing list
  Address: unbeara...@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/unbearable
  Archive: http://www.ietf.org/mail-archive/web/unbearable/

Charter:


Web services generate various security tokens (e.g. HTTP cookies, OAuth
tokens, etc.) for web applications to access protected resources.
Currently these are bearer tokens, i.e. any party in possession of such
token gains access to the protected resource. Attackers export bearer
tokens from client machines or from compromised network connections,
present these bearer tokens to Web services, and impersonate
authenticated users. Token Binding enables defense against such attacks
by  cryptographically binding security tokens to a secret held by the
client.

The tasks of this working group are as follows:

1. Specify the Token Binding protocol v1.0.
2. Specify the use of the Token Binding protocol in combination with
HTTPS.

It is a goal of this working group to enable defense against attacks that
involve unauthorized replay of security tokens. Other issues associated
with the use of security tokens are out of scope. Another goal of this
working group is to design the Token Binding protocol such that it would
be also useable with application protocols other than HTTPS. Specifying
alternative application protocols is not a primary goal.

The main design objectives for the Token Binding protocol, in no
particular order:

1. Allow applications and services to prevent unauthorized replay of
security tokens.
2. Allow strong key protection, e.g. using hardware-bound keys.
3. Support both first-party (server generates a token for later use with
this server) and federation (server generates a token for use with
another server) scenarios.
4. Preserve user privacy.
5. Make the Token Binding protocol useable in combination with a variety
of application protocols.
6. Allow the negotiation of the Token Binding protocol without additional
round-trips.
7. Allow the use of multiple cryptographic algorithms, so that a variety
of securehardware modules with different cryptographic capabilities
could be used with Token Binding.
8. Propose Token Binding specification that can be implemented in Web
browsers (but is not limited to them). E.g. Web browsers require that the
same bound security token must be presentable over multiple TLS sessions
and connections.

The working group will use the following documents as a starting point
for its work:

- draft-popov-token-binding-00;
- draft-balfanz-https-token-binding-00.

This WG will collaborate with other IETF WGs, in particular with the TLS,
HTTPbis and Oauth WGs and with the W3C webappsec WG.


Milestones:
  Jan 2016 - HTTPS Token Binding to IESG.
  Jan 2016 - WG document for the Token Binding Protocol v1.0.
  Jan 2016 - WG document for HTTPS Token Binding.
  Jan 2016 - Token Binding Protocol v1.0 to IESG.







[admin] Registration for April 24 2015 Web Components f2f meeting; deadline April 10

2015-02-24 Thread Arthur Barstow
The registration page for the April 24 Web Components f2f meeting at 
Google's Mount View CA office is now open:


https://www.w3.org/2002/09/wbs/42538/webcomponents-042015/

The meeting/agenda page is: 
https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting.


Please register by April 10.

-Thanks, AB



Re: Web Components F2F in April 2015

2015-02-19 Thread Arthur Barstow

[ -  the easily recognizable p-webapps subscribers ]

On 2/18/15 12:50 PM, Dimitri Glazkov wrote:
Following Art's suggestion [1], I propose a Web Components-specific 
F2F with with the primary goal of reaching consensus on the Shadow DOM 
contentious bits [2].


When: Friday, April 24, 2015
Where: Google San Francisco or Mountain View (to be confirmed)
What: a one-day meeting


Thanks for organizing this meeting Dimitri!

When will you be able to confirm the location? Regardless, I think we 
should consider the meeting as confirmed.


-Thanks, ArtB


Tentative agenda:

1) Go over the contentious bits, discuss pros/cons
2) Brainstorm/present ideas on changes to current spec
3) Decide on changes to current spec
4) If we have time left, review custom elements bits [3]

I stubbed out the basics in 
https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting


:DG

[1]: 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0407.html
[2]: 
https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits

[3]: https://wiki.whatwg.org/wiki/Custom_Elements





Re: Staying on Topic [Was: Re: WebPortable/PlatformProprietary - An Established Concept]

2015-02-19 Thread Arthur Barstow

On 2/19/15 9:57 AM, Anders Rundgren wrote:
Where are you supposed to propose new APIs?  Can such proposal be made 
by non-W3C members?
This was a proposal for using Chrome Native Messaging as the 
foundation for a new standard.


Perhaps you should pursue the Community Group process 
https://www.w3.org/community/groups/.


-Thanks, AB





Re: CORS explained simply

2015-02-19 Thread Arthur Barstow

On 2/19/15 4:28 PM, henry.st...@bblfish.net wrote:

Hi,

   I find that understanding CORS is a really not easy.
It seems that what is missing is an general overview document,
that would start by explaining why the simplest possible method
won't work, in order to help the user understand then why more
complex method are needed.

For example the first thing one should start by explaining is for

  1) requests that do not require authentication
q1: why is the origin sent at all? And why are there still restictions?
q2: why does POSTing a url encoded form not require pre-flight? But why 
does POSTing other data do?

  2) On requests that do need authentication:
q3: Why are the pre-flight requests needed at all?

I know that the answer to q1 is that some servers have access control methods
based on ip address of the client. But it is worth stating clearly the 
requirement
in the specs so that this can be understood.

There is also the question as to why the server needs to make a decision as to
what the client can see. But why can't it be the client? After all the user 
could
decide to give more rights to some JS apps than to others, and that would work 
too.

I am not saying that these questions don't have answers. It is just that they
would help a developer understand why CORS has taken the shape it has, and so
understanding the reaons for the decisions taken, better be able to think about 
it.


Hi Henry,

I agree this type of info would be useful so a long time ago I started 
to bookmark related resources (f.ex. see [1]) but stopped as CORS became 
deployed and sites like enable-cors.org emerged. Maciej's deck [2] is 
still a real nice overview.


(BTW, public-webappsec might be a good place to send your e-mail.)

-Thanks, AB

[1] https://delicious.com/afbarstow/CORS
[2] 
https://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0468/CORS.pdf





  1   2   3   4   5   6   7   8   9   10   >