Re: CfC: publish WD of XHR; deadline November 29

[Arthur Barstow]

On 11/26/12 1:38 AM, ext Jungkee Song wrote:

I suggest we put the following wordings for Anne's work and WHATWG to be 
credited. If we make consensus, let me use this content for publishing the WD.


Please put your proposed text in a version of the spec we can review and 
send us the URL of that version.


-Thanks, AB

Re: CfC: publish WD of DOM; deadline December 2

[Arthur Barstow]

On 11/25/12 10:19 AM, ext Ms2ger wrote:

Same objections as to the XHR WD.


Are you talking about 
?


The DOM ED includes the following in the boilerplate:

[[
Living Standard:
  http://dom.spec.whatwg.org/
]]

What (else) are you looking for?

-Thanks, AB

CfC: publish WD of DOM; deadline December 2

[Arthur Barstow]

This is Call for Consensus to publish a  Working Draft of the DOM spec 
using #ED as the basis.


Please note Lachlan will continue to edit the ED during this CfC period.

Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by December 2 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal.


-Thanks, AB

#ED 

CfC: publish WD of Screen Orientation; deadline November 30

[Arthur Barstow]

Mounir prepared a new WD for The Screen  Orientation  API and this is a 
Call for Consensus to publish that 
WD.


Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by November 30 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal.


-Thanks, AB

[admin] XHR ED Boilerplate

[Arthur Barstow]

[ Sorry for the delayed response, I was choking on some turkey ... ]

Here's what I did for the URL spec re the boilerplate to help address 
the "attribution issue" re Anne and WHATWG:


[[


This Version:
   http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
Latest WHATWG Version:
   http://url.spec.whatwg.org/
Previous Versions:
   http://www.w3.org/TR/2012/ED-url-20120524/
Author:
   Anne van Kesteren 
Editor:
   Web Applications Working Group 
Former editors:
   Adam Barth 
   Erik Arvidsson 
   Michael[tm] Smith 
]]

In the case of XHR, the new Editors would be listed as Editors and if 
they made contributions to the spec, they would also be added to the 
Author list too.


If something like that would not be acceptable for the XHR ED, what 
specific change(s) do you request?


-Thanks, AB

CfC: publish WD of XHR; deadline November 29

[Arthur Barstow]

TheXHR Editors  would  like to publish a new WD of XHR and this is a 
Call for  Consensus to do so using the following ED (not yet using the 
WD template) as the basis 
.


Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by December 29 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal.


-Thanks, AB

[fyi] Minutes from Technical Plenary meeting at TPAC 2012

[Arthur Barstow]

On 11/20/12 10:15 AM, ext Coralie Mercier wrote:

> Minutes from TPAC 2012 [1] are now available: Plenary day (Public 
minutes)

> http://www.w3.org/2012/10/31-tpac-minutes
>
> Please let us know if any corrections are necessary.
>
>  [1] http://www.w3.org/2012/10/TPAC/

[admin] Publishing specs before EoY; CfC start deadline is December 2

[Arthur Barstow]

Hi Editors, All,

If we want to publish a WD or LCWDin #TR before the EoY, given the 
upcoming  publishing  blackout dates, the schedule and  deadlines  are:


* December 2 - deadline to start a (1-week) CfC

* December 9 - CfC end date

* December 11 - deadline for publication request

* December 13 - last day to publish

The above deadlines also apply for CRsand PRs but since those 
publications require some additional steps (e.g. a Director's call), the 
CfC will need to start earlier-> this week.


If a spec was last published as a FPWD  and new  features have been 
added, please consider a CfC for a new WD.


If a spec was last published as a WD, and it is feature complete and/or 
is getting implemented, please consider a CfC for LCWD.


Please let me know if you want me to start a CfC.

-Thanks, AB

#TR 

[admin] Publication Rules [Was Re: Call for Consensus: CORS to Candidate Recommendation]

[Arthur Barstow]

The W3C's process documents (e.g. #PubRules) define the policies for 
publications and this issue will be addressed if/when the CR is actually 
published.


WebApps is simply a user of the publication policy. If you want to 
discuss W3C processes such as PubRules, please use some other list - and 
not any of WebApps' lists - such as public-w3cprocess #ProcCG.


-Thanks, AB

#PubRules 
#ProcCG 

On 11/16/12 8:51 AM, ext Ms2ger wrote:

I object to making such a change.

On 11/16/2012 02:32 PM, Glenn Adams wrote:

Before going to CR, I believe the [HTML] entry in the references section
needs to be changed to reference an appropriate W3C specification. A
present, it reference a non-W3C document.

Re: Call for Consensus: CORS to Candidate Recommendation

[Arthur Barstow]

On 11/15/12 5:31 PM, ext Hill, Brad wrote:


I have placed a draft for review at:

http://www.w3.org/2011/webappsec/cors-draft/

And this is a Call for Consensus among the WebAppSec and WebApps WGs 
to take this particular text (with necessary additions to the Status 
of this Document section if approved) forward to Candidate Recommendation.




I support this CfC although I am wondering about the CR exit criteria.

Do you expect to re-use the CSP1.0 criteria:

[[
The entrance criteria for this document to enter the Proposed 
Recommendation stage is to have a minimum of two independent and 
interoperable user agents that implementation all the features of this 
specification, which will be determined by passing the user agent tests 
defined in the test suite developed by the Working Group.

]]

My preference is what WebApps has used in other CRs because I think it 
is clearer that a single implementation is not required to pass every 
test but that at least two implementations must pass every test. F.ex.:


   

-Thanks, AB

CfC: Selectors API Level 1 Test Suite; deadline November 23

[Arthur Barstow]

The RfR for the Selectors API Level 1 test suite passed WebApps' testing 
group's review (see below), and according to the agreed 
#Approvalprocess, this now means a group wide review should be done. As 
such, this is a CfC for this test suite:




If you have any comments, please send to public-webapps by November 23. 
If you review any set of the tests and find no issues, please state that 
as a reply to this RfR (so we can get a sense of "who reviewed what").


In the absence of any comments, these tests will be considered Approved.

Note: for all practical purposes, I suspect the set of people that will 
actually review our tests are already subscribed to the testsuite list, 
thus this extra CfC is unlikely to result in additional review. As such, 
if no one beats me to it ;-), I will (separately) start a thread about 
streamlining the testing process a bit (for example remove the separate 
group wide CfC for a test suite and include the test suite review in the 
CfC to move a spec from CR to PR). However, let's please not derail this 
CfC on testing process issues.


-Thanks, AB

#Approval 


 Original Message 
Subject:Re: RfR: Selectors API Level 1 Test Suite - deadline 14 November
Resent-Date:Thu, 15 Nov 2012 16:18:17 +
Resent-From:
Date:   Thu, 15 Nov 2012 17:17:42 +0100
From:   ext Charles McCathie Nevile 
Organization:   Yandex
To: 	, Lachlan Hunt 
, Charles McCathie Nevile 




On Sun, 11 Nov 2012 16:07:08 +0100, Charles McCathie Nevile
  wrote:


On Wed, 24 Oct 2012 14:28:41 +0200, Lachlan Hunt
  wrote:


This is a request for review of the Selectors API Level 1 test suite.


This is a formal resolution that the test suite has passed the review, and
is accepted.

Although the only review we are aware of is Opera's, there are 5 browsers
scoring 97-99% on the tests, and people seem to have checked the tests in
practice.

cheers

Chaals (as co-chair)

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru  Find more athttp://yandex.com

CfC: publish Candidate Recommendation of Server-Sent Events; deadline November 21

[Arthur Barstow]

The comment period for the October 23 LCWD of Server-Event Events ended 
yesterday. Since there were no comments submitted nor new bugs files, 
this is a Call for Consensus to publish a  Candidate Recommendation of 
this spec using #Draft-CR as the basis.


This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in the Process 
Document 
.


The CR Exit Criteria (#Exit) is identical to WebApps' last CR (WebSocket 
API) and the expected CR duration is two months.


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with the proposal. The deadline for 
comments is November 21 and all comments should be sent to 
public-webapps@w3.org.


-Thanks, AB

#Draft-CR 

#Exit 

Mail List Etiquette [Was: Re: Two years on and still no sensible web storage solutions exist]

[Arthur Barstow]

Todd - your e-mail fails the "respectful manner" requirement of the 
group's e-mail policy (#Mail-List-Etiqutte).


Please restrict the content of your e-mails to respectful technical 
comments.


If you continue to fail to abide with this policy, your posting rights 
to this list will be removed.


-Thanks, AB

#Mail-List-Etiqutte 



On 11/9/12 1:24 PM, ext Todd Blanchard wrote:

W3C document license [Was: Re: Call for Editor: URL spec]

[Arthur Barstow]

On 11/6/12 3:23 AM, ext Ms2ger wrote:

On 11/06/2012 08:02 AM, Adam Barth wrote:

Does the WebApps Working Group plan do either of these things?

A) Put in technical effort to improve the specification


Unlikely.


My expectation is that public-webapps will continue to be one venue for 
comments about the spec.


If a credible Editor does not commit to moving the spec along the REC 
track, then I believe one option is for the WG to publish the spec. That 
is, don't specifically identify an Editor. Regardless, as I stated 
previously, proper attribution is needed.


B) License the fork in such a way as to let me merge improvements 
into my copy


Definitely not.


I am not aware of any changes nor impending changes to the W3C's 
Document license policy WebApps follows.


-AB

Giving Credit Where Credit is Due [Was: Re: Call for Editor: URL spec]

[Arthur Barstow]

On 11/6/12 3:46 AM, ext Ian Hickson wrote:
  
the W3C does not generally give credit where credit is due.


This issue has been bothering me for a while, so thanks for raising it. 
I agree proper attribution is a problem that needs to be addressed in 
the WG's versions of these specs (URL, DOM4, etc.).


My sincere apologies to those Editors that are not getting appropriate 
credit for their contributions.


-Thanks, AB

Re: Call for Editor: URL spec

[Arthur Barstow]

On 11/5/12 5:47 PM, ext Tab Atkins Jr. wrote:
In the meantime, W3C is copying Anne's work in several specs, to 


It seems like W3C groups copying WHATWG's work has been ongoing for 
several years (so I think this is "old news", especially since, AFAIU, 
it is permissiable, perhaps even encouraged? via the WHATWG copyright) ;-).


I certainly appreciate Anne's contributions to open Web standards and 
hope he continues his great contributions.


-Thanks, AB

Re: Call for Editor: URL spec

[Arthur Barstow]

On 11/5/12 7:29 AM, ext Julian Reschke wrote:

On 2012-11-05 12:46, Arthur Barstow wrote:

Hi All,

We need an Editor(s) to move WebApps' URL spec towards Recommendation.
If you are interested in this Editor position, please contact me 
offlist.


-Thanks, AB

[URL] <http://dvcs.w3.org/hg/url/>


Is this about the URI above or about <http://url.spec.whatwg.org/>?


Yes, my expectation is WebApps will use the work Anne is doing.

-AB

Call for Editor: URL spec

[Arthur Barstow]

Hi All,

We need an Editor(s) to move WebApps' URL spec towards Recommendation. 
If you are interested in this Editor position, please contact me offlist.


-Thanks, AB

[URL] 

WebApps' File: Writer & File: D&S specs and SysApps' File System and Media Storage specs

[Arthur Barstow]

[ My apologies in advance for cross-posting but I'd like feedback from 
both the WebApps and SysApps communities ... ]


Hi Eric, Adam, WonSuk, All,

During WebApps' Oct 29 discussion about the File: Writer (#Writer) and 
File: Directories and System (#D&S) specs (#Mins), someone mentioned 
SysApps was doing some related work. I just scanned SysApps' #Charter 
and noticed it includes these two related deliverables:


1. File System - I didn't notice any additional information in the 
charter other than a FPWD is expected in "Q3-Q6".


2. Media Storage - "An API to manage the device's storage of specific 
content types (e.g. pictures). Examples: Tizen Media Content (#Tizen), 
B2G Device Storage (#B2G)".


Would some please explain the relationship between these various specs?

In the case of SysApps' Media Storage spec, perhaps it is WebApps' IDB 
spec that is (more) relevant but that may depend on the UCs of Media 
Storage so clarification here is also welcome.


(I noticed a somewhat related thread this past summer in #public-sysapps 
but it appears that was mostly about the applicability (or not) of Web 
Intents vis-a-vis #1 and #2 above.)


-Thanks, AB

#Writer 
#D&S 
#Charter 
#Mins 
#Tizen 

#B2G 
#public-sysapps 

Re: FW: Draft Minutes: 29 October 2012

[Arthur Barstow]

On 10/29/12 8:15 PM, ext Travis Leithead wrote:

To clear up and potential confusion about IE's Shared Worker implementation 
status, I'd like to change this:

Travis: we don't support shared workers in any form
 ... with the possible exception of automatic GC

to:

Travis: we don't support shared workers in any form
 ... we also may not support automatic GC for regular Workers


FYI, Yves Lafon (WebApps Team Contact) made this change to the minutes. 
Thanks Yves. -AB

Re: ACTION-669: Work with PLH on an announcement seeking IRC fragments (Web Applications Working Group)

[Arthur Barstow]

FYI -the title of this action is not correct -> this action is about me 
working with Travis and Philippe to get "Web IDL fragments" to test Web 
IDL specper the Web IDL CR's exit criteria #exit.


(This action has _nothing_ to do with "IRC fragments [what ever that is 
;-)].)


-Thanks, AB

#exit <http://www.w3.org/TR/WebIDL/#cr-exit>


On 10/29/12 12:08 PM, ext Web Applications Working Group Issue Tracker 
wrote:

ACTION-669: Work with PLH on an announcement seeking IRC fragments (Web 
Applications Working Group)

http://www.w3.org/2008/webapps/track/actions/669

On: Arthur Barstow
Due: 2012-11-05

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings

Draft Minutes: 30 October 2012

[Arthur Barstow]

er of widget spec backers
... mutterings is
... given there's roundtripping between JSON and XML
... unifying that isn't really difficult
... wondering if people from those corners are interested in that as a 
workitem

... i don't think it's scope creep
... it's a fairly straightforward is a simple conversion of values
... just as mozilla-chrome is straightforward
... Q: what are the workitems we should take up
... do we think doing it here is the right place

 yes, it should be done, and here

ArtB:art barstow, nokia
... about venue
... i'm mostly indifferent about here, HTMLWG or a CG
... (which was already created)
... but in considering venue, we need producers/consumers of appcache to 
be comfortable to come in and give feedback

... i think a CG may be more comfortable for them
... hashing out multiple drafts there may be easier before a WG

paulc:interested in knowing if anyone is in this WG
... that isn't in HTML WG
... wants to do this work here
... HTML WG is about to be rechartered
... we'd like this to be clarified before we're rechartered
... if you don't clarify today
... before we meet Thu/Fri
... an AC question
... if we proposed Yes/No for doing AppCache in our charter
... will there be objections from Member companies in this room
... that aren't in our group?

sicking:i can't speak officially for mozilla
... i'm not sure we'd object for it to be in charter
... i'd personally prefer WebApps WG or a CG
... i feel so far
... we've had an easier time talking about these things on webapps ML
... i feel like this isn't super tied into HTML as a Markup Language
... scope wise, it makes as much sense here as HTML
... i don't think we'd object to it being in HTML WG

chaals:Yandex, first preference is doing it in Web Apps WG
... second preference is the Native WebApps CG
... which is dormant
... third preference is HTML
... if it doesn't work out like that, we're not going to object
... we have a strong preference, but won't spend our life arguing about it

adrianba:Adrian, Microsoft
... i proposed to continue this discussion in the HTML WG
... because it's already in the spec
... MS has no objection for doing it here
... we had the data-cache discussion
... we prefer one WG or the other
... [i.e. not a CG]

chaals:how many people feel we shouldn't do this work anywhere

mjs:stop trolling the WG

chaals:how many people couldn't care less where the work takes place
... how many people have a preference for where the work takes place?
... i'll pass the mic around, and ask you to state your preference

pbakaus:Zynga, web apps because i believe most of the apis should be in js

hsivonen:XXX, webapps, good track record of WG

adrianba:MS, i gave my preference, but guess it'll be in WebApps

darobin:HTML, because i think we'll fix that group, and it'll rock

[ laughter ]

SimonPieters:Opera, WebApps because it's a functional group and HTML 
currently isn't


sicking:first preference is "Fix AppCache CG"
... second preference is WebApps WG

smaug:WebApps, what hsivonen said

rafaelw:Google, WebApps it makes sense here

chaals:this is the side that doesn't care

odinho_:Opera, WebApps

 webapps, because we see this as related to app packaging and 
synergistic with the webapps experience with widgets, and other APIs 
that webapps may consider (e.g. offline webapp support in general)


bryan:AT&T, WebApps, we see this related to webapp packaging, 
synergistic w/ widgets

... and offline in general

chaals:ignoring darobin (good idea)
... there's a strong preference here to do it here
... for the people who care
... if we said, hey paulc, we think we'll do it here
... tell HTML WG that WebApps wants to do it here, and themselves
... will we have a turf war?

paulc:i don't know the answer, we'll find out on thursday

chaals:message to HTML WG is "we want it here, if that's ok with you guys"

paulc:chairs should take an action to send a message to the html wg

 wasn't mjs's comment earlier that he didn't expect that to be a 
particular problem?


paulc:the question applies to html wg too
... is there anyone in html and not in webapps who'd object to it not 
being in html

... i took the silence as "no one objected to it being in html"

sicking:i'll object to do it in the html wg on the main ML

*ACTION:*barstow respond to HTMLWG's question re WebApps has a 
strong preference to work on AppCache in WebApps WG [recorded 
inhttp://www.w3.org/2012/10/30-webapps-minutes.html#action02]


 Created ACTION-674 - Respond to HTMLWG's question re WebApps 
has a strong preference to work on AppCache in WebApps WG [on Arthur 
Barstow - due 2012-11-06].


sicking:but wouldn't object to it being its own ML

 npdoty, I don't expect it to be a problem but paul is correct 

RfC: LCWD of Server-sent Events; deadline November 13

[Arthur Barstow]

This is a Request for Comments for the October  23 Last Call Working 
Draft of WebApps' Server-sent Events spec:




The comment deadline is November 13 and all comments should be sent to 
the public-webapps@w3.org list with a Subject: prefix of "[eventsource]".


-Thanks, AB

Re: CfC: publish WD - NOT LCWD of File API; deadline October 22

[Arthur Barstow]

All - today, Arun reported hewould like to do make some additional 
changes to the File API spec before it is ready for a LC to be 
published. I understand reflecting 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554 is one issue, and 
Arun may expand on this or other issues.


Anyhow, please consider this CfC as hereby amended to "publish a new WD 
- and NOT a LCWD".


-Thanks, AB

On 10/16/12 9:29 PM, ext Arthur Barstow wrote:
All - this is a Call for Consensus to publish a Last Call Working 
Draft of the File API spec <http://dev.w3.org/2006/webapi/FileAPI/>. 
Note bug 17125 ([1] below) is open and Arun proposes it be postponed 
for v.next. Additionally, Arun notes below bug 19554 ([2] below) is a 
related feature request for HTML and he proposes the LC comment period 
be used to gather input on that bug.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a 
LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 4 weeks.

If you have any comments or concerns about this CfC, please send them 
to public-webapps@w3.org by October 22 at the latest. Positive 
response is preferred and encouraged and silence will be considered as 
agreement with the proposal.


-Thanks, AB

 Original Message 
Subject: Re: [admin] Publishing specs before TPAC: CfC start 
deadline is Oct 15

Date: Tue, 16 Oct 2012 17:29:17 -0700
From: ext Arun Ranganathan 
To: Arthur Barstow 
CC: 


- Original Message -

On 10/9/12 4:13 PM, ext Arun Ranganathan wrote:
> On Sep 26, 2012, at 10:27 AM, Arthur Barstow wrote:
>
>> * File API - Arun can you get this spec ready for LC by October
>> 15?
>
> Yes.

ATM, File API has 8 open bugs [1].



I've rationalized these down to 2 bugs.

1. Bug 17125[1] is a feature that we should mark v.next; it calls for 
the ability to retroactively "unselect" an erroneous selection that is 
present in FileList.  I don't think this is a pressing feature.


2. Bug 19554[2] is a spec. request feature in WHATWG/HTML5, especially 
useful for autoRevoke semantics for Blob URLs.  I'm not sure whether 
autoRevoke is at risk because of this bug, since implementations have 
shown that stable state (what the spec. uses now) is problematic for 
autoRevoke.  But I'll let this be discussed in LC commentary or in 
upcoming TPAC discussions.



P.S. Dom's WebIDL checker reports a bug in the Blob constructor


Thanks for catching that :)  I think that particular bug is fixed.

And I'm sorry this is a day late (e.g. not ready by Oct. 15). I've 
gotten it PubReady, using a "push out" date of Oct. 18.  Hope that works:

http://dev.w3.org/2006/webapi/FileAPI/


-- A*

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554

[widgets] Does anyone still care about Widget Updates?

[Arthur Barstow]

For various reasons, a Candidate Recommendation of Widget Updates was 
never published, although the CfC to do so passed and the ED is prepared 
as such [widget-updates].


Since no one has raised this as an issue, I would like feedback on what 
we should do with this spec. The main options are: 1) to stop work (and 
publish a WG Note); 2) to move forward with the CR.


I don'tthink it makes much sense to move the spec to CR if we do not 
have  commitments for at least two independent implementations of the 
CR. Therefore, Implementors should please speak up if they willcommit to 
implementing this CR.


-Thanks, AB

[widget-updates] <http://dev.w3.org/2006/waf/widgets-updates/>

 Original Message 
Subject: 	CfC: publish Candidate Recommendation of Widget Updates; 
deadline May 2

Resent-Date:Thu, 26 Apr 2012 16:42:00 +
Resent-From:
Date:   Thu, 26 Apr 2012 12:41:34 -0400
From:   ext Arthur Barstow 
To: public-webapps 
CC: 



The comment deadline for the Widget Updates LCWD ended April 19. No
comments were submitted for that document so this is a Call for
Consensus to publish a Candidate Recommendation of the spec using the LC
as the basis <http://www.w3.org/TR/2012/WD-widgets-updates-20120322/>.

The Exit Criteria for the CR will be the same as that used for the other
widget specs, namely that two or more implementations must pass each
test case.

This CfC satisfies: a) the group's requirement to "record the group's
decision to request advancement" to CR; and b) "General Requirements for
Advancement on the Recommendation Track" as defined in the Process Document:

http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs

Positive response is preferred and encouraged and silence will be
considered as agreeing with the proposal. The deadline for comments is
May 2 and all comments should be sent to public-webapps at w3.org.

-Thanks, AB

[widgets] XML Digital Signatures for Widgets REC Delayed until at least January 2013

[Arthur Barstow]

Hi All- a couple of FYIs re the "XML Digital Signatures for Widgets" 
Proposed Recommendation [widgets-digsig]...


* You may recall widgets-digsig has a normative dependency on "XML 
Signature Syntax and Processing Version 1.1" [xmldigsig-core1] andthe 
"Elliptic Curve PAG" was created because of RIM's patent disclosure 
against xmldigsig-core1. This PAG is now closed and its report is 
availableat [Report].


* For various reason (see below for details), xmldigsig-core1has moved 
from CR back to LCWD. Consequently, the earliest a widgets-digsig REC 
can be published is January 2013(the delay caused by both the LC's new 
Call for Exclusions period plus the end of the year publishing blackout).


-AB

[widgets-digsig] 
[xmldigsig-core1] 
[Report] 

 Original Message 
Subject: 	Last Call working drafts of XML Signature 1.1 and XML 
Encryption 1.1 published

Date:   Fri, 19 Oct 2012 17:13:54 -0400
From:   Hirsch Frederick (Nokia-CIC/Boston) 
To: W3C XML Coordination 
CC: 	Hirsch Frederick (Nokia-CIC/Boston) , 
Barstow Art (Nokia-CIC/Boston) 




The XML Security WG has published Last Call working drafts of XML Signature 1.1 
and XML Encryption 1.1:

XML Signature Syntax and Processing Version 1.1 - 
http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/

XML Encryption Syntax and Processing Version 1.1 - 
http://www.w3.org/TR/2012/WD-xmlenc-core1-20121018/

Please share the drafts for review of the latest changes (outlined in the 
status sections of the documents) and please let the XML Security WG know of 
any concerns (to the address listed in the documents).

These documents were previously published as CR drafts.  The reason for the 
return to Last Call is outlined in the following message to the chairs list [1]:

[[

XML Signature 1.1 was previously published as a Candidate Recommendation and then 
returned to Last Call since an item not marked as "at risk" was removed from 
the specification due to lack of interoperability testing (OCSPResponse), changes were 
made to references and language related to Elliptic Curve algorithms at the 
recommendation of the XML Security PAG [2], missing algorithm identifiers noted during 
interoperability testing were added for the SHA224 family of algorithms, the Exclusive 
C14N omits comments algorithm was added as required to implement, reflecting existing 
practice, and a correction was made by changing the KeyInfoReference implementation 
requirement to should instead of RetrievalMethod. There were also updates to references 
and some editorial improvements. Given the normative changes as a result of 
interoperability testing and review the working group agreed to another Last Call 
progressing then to PR.

XML Encryption 1.1 was previously published as a Candidate Recommendation and then 
returned to Last Call since some normative material that had not been marked as 
"at-risk" was moved to an informative appendix (AES-128/192/256-pad symmetric 
key wrap algorithm), AES192-GCM was added as an optional to implement block encryption 
algorithm after noted as missing during interoperability, and the requirement for the RSA 
1.5 key transport algorithm was changed from required to optional to address security 
concerns recently noted in the research literature. The working group agreed to another 
Last Call progressing then to PR.

...

[2] https://lists.w3.org/Archives/Member/w3c-ac-members/2012OctDec/0020.html

]]

The intent of the XML Security WG is to go to PR as soon as possible for these 
documents (and XML Signature Properties draft) after LC completes. Interop has 
already been completed. The documents include links to documents summarizing 
changes since the previous Recommendation - these explanation documents were 
published as W3C Notes in conjunction with the Last Call publication.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1] https://lists.w3.org/Archives/Member/chairs/2012OctDec/0030.html

Begin forwarded message:


From: "Hirsch Frederick (Nokia-CIC/Boston)" 
Date: October 19, 2012 3:34:05 PM EDT
To: XMLSec WG Public List 
Cc: "Hirsch Frederick (Nokia-CIC/Boston)" 
Subject: Last Call working drafts of XML Signature 1.1 and XML Encryption 1.1 
published

Last Call working drafts of XML Signature 1.1 and XML Encryption 1.1 have been 
published:

XML Signature 1.1:  http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/

XML Encryption 1.1:  http://www.w3.org/TR/2012/WD-xmlenc-core1-20121018/

The Last Call ends 8 November 2012.

The corresponding "Functional Explanation of Changes" documents were published 
as W3C Notes:

Functional Explanation of Changes in XML Signature 1.1: 
http://www.w3.org/TR/2012/NOTE-xmldsig-core1-explain-20121018/

Functional Explanation of Changes in XML Encryption 1.1: 
http://www.w3.org/TR/2012/NOTE-xmlenc-core1-explain-20121018/

Than

CfC: publish LCWD of File API; deadline October 22

[Arthur Barstow]

All - this is a Call for Consensus to publish a Last Call Working Draft 
of the File API spec <http://dev.w3.org/2006/webapi/FileAPI/>. Note bug 
17125 ([1] below) is open and Arun proposes it be postponed for v.next. 
Additionally, Arun notes below bug 19554 ([2] below) is a related 
feature request for HTML and he proposes the LC comment period be used 
to gather input on that bug.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 4 weeks.

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by October 22 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

 Original Message 
Subject: 	Re: [admin] Publishing specs before TPAC: CfC start deadline 
is Oct 15

Date:   Tue, 16 Oct 2012 17:29:17 -0700
From:   ext Arun Ranganathan 
To: Arthur Barstow 
CC: 


- Original Message -

On 10/9/12 4:13 PM, ext Arun Ranganathan wrote:
> On Sep 26, 2012, at 10:27 AM, Arthur Barstow wrote:
>
>> * File API - Arun can you get this spec ready for LC by October
>> 15?
>
> Yes.

ATM, File API has 8 open bugs [1].



I've rationalized these down to 2 bugs.

1. Bug 17125[1] is a feature that we should mark v.next; it calls for the ability to 
retroactively "unselect" an erroneous selection that is present in FileList.  I 
don't think this is a pressing feature.

2. Bug 19554[2] is a spec. request feature in WHATWG/HTML5, especially useful 
for autoRevoke semantics for Blob URLs.  I'm not sure whether autoRevoke is at 
risk because of this bug, since implementations have shown that stable state 
(what the spec. uses now) is problematic for autoRevoke.  But I'll let this be 
discussed in LC commentary or in upcoming TPAC discussions.


P.S. Dom's WebIDL checker reports a bug in the Blob constructor


Thanks for catching that :)  I think that particular bug is fixed.

And I'm sorry this is a day late (e.g. not ready by Oct. 15).  I've gotten it PubReady, 
using a "push out" date of Oct. 18.  Hope that works:
http://dev.w3.org/2006/webapi/FileAPI/


-- A*

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554

Call for Editor: Progress Events REC track spec

[Arthur Barstow]

Hi All,

Since the Invited Expert route didn't work out for Anne, we need an 
Editor(s) to move the Progress Events spec - last published as a 
Candidate Recommendation [ProgEv] - towards Recommendation. If you are 
interested in this Editor position, please contact me offlist.


Also, if anyone has implementation data for this spec, please let us know.

(Ms2ger submitted some test cases 
).


-Thanks, AB

[ProgEv] 

[admin] New public IRC server refuses passwords

[Arthur Barstow]

[ bcc public-webevents ]

FYI, the W3C's IRC server was upgraded recently. It was supposed to be 
100% transparent to users but it turned out differently. FMI see 
.


 Original Message 
Subject:New public IRC server refuses passwords
Resent-Date:Mon, 15 Oct 2012 15:10:36 +
Resent-From:
Date:   Mon, 15 Oct 2012 11:10:29 -0400
From:   ext Brett Smith 
To: 



[This issue affects *non-Team* connecting to the IRC server.  I'm
sending this out primarily for the benefit of Team liaisons and others
who need to help collaborators who connect to the public IRC server.]

We've received a few reports that W3C collaborators have been having
trouble connecting to the new public IRC server.  In each case, this has
happened because their client was configured to send a server password.
 Passwords are not necessary to connect to the public IRC server.  The
old server software would ignore this extraneous password; the new
server software rejects connections that provide it.

Public IRC server passwords are not encrypted in any way and can easily
be sniffed by malicious third parties.  Anyone who has an IRC client
configured to connect to the public IRC server with a password should
remove that password to avoid leaking sensitive information.

People with clients configured to send a W3C account password should
change their password using the form at
.

As always, anyone with questions about this change should contact us at
.

Best regards,

--
Brett Smith

Re: CfC: publish FPWD of Push API; deadline October 12

[Arthur Barstow]

On 10/5/12 7:38 AM, ext Arthur Barstow wrote:
The Push API Editors would like to publish a First Public Working 
Draft of their spec and this is a Call for Consensus to do so, using 
the following spec as the basis 
<http://dvcs.w3.org/hg/push/raw-file/default/index.html>.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to 
begin reviewing the document. The FPWD reflects where the group is on 
this spec at the time of publication; it does _not_ necessarily mean 
there is consensus on the spec's contents.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by October 12 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


Although there were no objections to this CfC, Jonas raised a number of 
concerns in 
<http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0042.html>. 
Although we will have an opportunity to discuss these comments in Lyon, 
I would like the spec Editors to add an "Issue Block" in the Security 
and Privacy concerns section and include a link to Jonas' comment.


Bryan, Eduardo - I will contact you off-list about preparing the spec 
for FPWD. (See <http://www.w3.org/wiki/Webapps/SpecEditing> if you are 
unfamiliar with the W3C's TR publication process.)


-Thanks, AB

Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15

[Arthur Barstow]

On 10/9/12 4:13 PM, ext Arun Ranganathan wrote:

On Sep 26, 2012, at 10:27 AM, Arthur Barstow wrote:


* File API - Arun can you get this spec ready for LC by October 15?


Yes.


ATM, File API has 8 open bugs [1]. Are you going to fix all of them by 
October 15 or will you propose some set of them remain open (and hence 
postponed to v.next)? Also, are any features going to be marked as "at 
risk"?


-Thanks, Art

P.S. Dom's WebIDL checker reports a bug in the Blob constructor [2]. I 
think you want to s/)>)/)>/.


[1] 
<https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=File%20API&resolution=---&list_id=186>
[2] 
<http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org%2F2006%2Fwebapi%2FFileAPI%2F&output=html>

CfC: publish LCWD of Server-sent Events; deadline Oct 18

[Arthur Barstow]

Ian has now closed the last substantive bugs for the Server-sent Events 
spec so this is a Call for Consensus to publish a new Last Call Working 
Draft of this spec using the following ED as the basis 
.


Two non-substantive editorial bugs remain open ([16070] and [18653]) and 
I will ask the person that prepares the spec for publication to fix 
those bugs in the LC version.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 3 weeks.

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by October 18 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

[16070] 
[18653] 

[announce] WebPlatform Docs: community resource for Web developers and designers

[Arthur Barstow]

Hi All,

On October 8 the W3C announced the alpha release of a new WebPlatform 
Docs initiative . From the home wiki:


[[


Web Platform Docs is a new community-driven site that aims to become a 
comprehensive and authoritative source for web developer documentation. 
Even though Web Platform Docs is still in alpha, you can already find 
lots of valuable content on the site, including information on:


* How to use features of the open web, with syntax and examples

* What platforms and devices you can use various technologies on

* What is the current standardization, stability and implementation 
status of each technology specification


In the future, Web Platform Docs will include even more content for you 
to explore such as live code examples, resources for educators and much 
more. To get there faster, we’d like to invite you to also contribute 
your knowledge. We hope you will join us!

]]

WebApps' scope clearly intersects the scope of this initiative (links to 
IndexedDB and File API information are already included in 
) and contributions from All are welcome 
(not just W3C Members).


For more information start, with the links above and/or subscribe to the 
initiative's new public-webplatf...@w3.org list <>.


-AB

Reminder: F2F meeting Oct 29-30 in Lyon France; registration deadline Oct 16

[Arthur Barstow]

Reminder: the registration deadline for WebApps' Oct 29-30 meeting is 
October 16 <http://www.w3.org/2012/10/TPAC/#Registration>.


WebApps' agenda page is 
<http://www.w3.org/wiki/Webapps/TPAC2012Meeting>. Please propose agenda 
topics on the list or add them to this page.


(The current list of registrants is in the following but note the access 
is Member-only 
<https://www.w3.org/2002/09/wbs/35125/TPAC2012/registrants#Webap>).


-Thanks, AB

 Original Message 
Subject: 	F2F meeting Oct 29-30 in Lyon France; registration deadline 
Oct 16

Resent-Date:Tue, 31 Jul 2012 11:47:57 +
Resent-From:
Date:   Tue, 31 Jul 2012 07:47:28 -0400
From:   ext Arthur Barstow 
To: public-webapps 



Hi All,

As announced earlier, WebApps will have a f2f meeting October 29-30 as
part of the W3C's annual Technical Plenary Week
<http://www.w3.org/2012/10/TPAC/>  in Lyon France.

WebApps' meeting page is
<http://www.w3.org/wiki/Webapps/TPAC2012Meeting>. We will again
preallocate some time slots for specific agenda topics and use an
unconference style meeting to determine the remainder of agenda topics.
Proposed agenda topics are welcome at any time, via e-mail or updating
the meeting page.

Registration for the meeting is required and there is a €45 per day fee
<http://www.w3.org/2012/10/TPAC/#Registration>  that increases to €135
per day on October 17.

The "Technical Plenary" meeting is all day Wednesday October 31. This
meeting (now mostly an unconference style) is often a good way to learn
about and discuss more general topics. See the 2011 TPAC agenda for more
info<http://www.w3.org/wiki/TPAC2011#Session_Grid>.

NOTE: the TPAC meeting page includes the following warning "*It is
strongly recommended to make hotel reservations as soon as possible as
there will be other meetings at the conference center.*"

-Thanks, AB

[admin] Publish Early, Publish Often [Was: Re: publish WD of Shadow DOM; deadline Oct 10]

[Arthur Barstow]

On 10/5/12 1:41 PM, ext Carr, Wayne wrote:

People often don't know to look at the editor's draft and they wind up looking 
at docs the WG has gone beyond.  So, we should publish regular WDs where the 
editor's draft has changed as often as possible.


I agree WDs should be published if the ED has had what I'll call 
"relatively substantial" changes (since its previous publication in 
/TR/). However, I generally don't support publishing new WDs if changes 
are only non-substantive.


I don't closely monitor the progress of all of WebApps' specs (~40 if 
widget specs are included). My expectation is that group members will 
contribute to their priority specs and if/when someone (and not just 
Editors) thinks a new WD should be published, they should propose so on 
this list. At the same time, we must also acknowledge our Editors have 
other priorities besides editing thus non-Editors that want a new WD 
published should be willing to help out if some minor editorial work is 
needed (e.g. updating the Status of the Document section).


-Thanks, AB

[admin] Some points about WebApps' Work Mode [Was: Re: CfC: publish LCWD of Pointer Lock; deadline Oct 4]

[Arthur Barstow]

On 10/5/12 1:21 PM, ext Vincent Scheib wrote:

Done,
May user agents apply additional restrictions on entering pointer
lock? [1] created and added to status section of specification.


Thanks Vincent.

Some FYIs for All regarding the process-related points ...

* Given WebApps' distributed and asynchronous [WorkMode], we have agreed 
to precede all first CfCs for Last Call with a 1-2 week "pre-LC review 
period". It's been a while since we have done one of those, thus I had 
forgotten to start that review and I'm sorry about that.


* Re the link to the bug database, I think all of our specs (from EDs 
on) should  include a link to their bug db so I will ask other Editors 
to that too [I wasn't picking on Vincent ;-)].


-Thanks, Art

[WorkMode] 

Re: CfC: publish LCWD of Pointer Lock; deadline Oct 4

[Arthur Barstow]

On 9/27/12 8:26 AM, ext Arthur Barstow wrote:
This is a Call for Consensus to publish a LCWD of Pointer Lock using 
the following document as the basis for the LC 
<http://dvcs.w3.org/hg/pointerlock/raw-file/tip/index.html>.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a 
LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 4 weeks.

If you have any comments or concerns about this CfC, please send them 
to public-webapps@w3.org by October 4 at the latest. Positive response 
is preferred and encouraged and silence will be considered as 
agreement with the proposal.


Hi All - given the discussion in the "Is Pointer Lock feature complete 
i.e. LC ready?" thread (see f.ex. [1] and follow-ons), it appears we 
don't yet have consensus the spec is ready for LCWD.


As such, I recommend we work toward consensus on the issues raised in 
this thread before proceeding with the LCWD. To help people track the 
issues raised, perhaps it would be helpful to create a related bug [2] 
(and to add a link to [2] in Status of the Document section).


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html
[2] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Pointer%20Lock&resolution=---

CfC: publish FPWD of Push API; deadline October 12

[Arthur Barstow]

The Push API Editors would like to publish a First Public Working Draft 
of their spec and this is a Call for Consensus to do so, using the 
following spec as the basis 
.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to 
begin reviewing the document. The FPWD reflects where the group is on 
this spec at the time of publication; it does _not_ necessarily mean 
there is consensus on the spec's contents.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by October 12 at the latest. Positive response is preferred 
and encouraged and silence will be considered as agreement with the 
proposal.


-Thanks, AB

Re: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Arthur Barstow]

On 10/5/12 7:06 AM, ext Bryan Sullivan wrote:

- more info on serverProtocols


It still seems like the set of valid strings will need to be defined. 
Perhaps at this point, it would be sufficient if a related Issue Block 
was added. (I'll ask Mike to create a Bugzilla component for the spec.)



- additional references (I still need to update the respec biblio)


Yes, please do as this must be fixed before the FPWD is actually 
published in /TR/. (Robin provided some related info in [1].)



I would like to request a CFC for FPWD publication, if there are no more
substantive comments on the updated version.


I will start a CfC for the FPWD.

(If you haven't prepared a doc for publication as a TR, please see 
 for some information about 
the PubRules and such.)


-Thanks, AB

[1] 



* serverProtocols - what are the expectations for the "valid" set of
values; where are they specified?


Good question. We need some means of registration of well-known services
so the protocols can be recognized.

CfC: publish WD of Shadow DOM; deadline Oct 10

[Arthur Barstow]

Dimitri would like to publish a new Working Draft of Shadow DOM and this 
is a Call for Consensus to do so, using the following document as the 
basis 
.


Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by October 10 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean  agreement with the proposal.


-Thanks, AB

Re: [admin] Call for Editor for XHR REC track doc

[Arthur Barstow]

On 9/25/12 7:00 PM, ext Arthur Barstow wrote:

If you are interested in this Editor position, please contact me offlist.


Thanks to those that expressed interest in helping move the XHR spec 
along the Recommendation track.


We selected three co-Editors for this spec: Julian Aubourg (jQuery), 
Jungkee Song (Samsung) and Hallvord Steen (Opera).


-Regards, Art and Chaals


[XHR] <http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html>

[widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation

[Arthur Barstow]

Earlier today the W3C announced:

[[
... the advancement of "Packaged Web Apps (Widgets) - Packaging and XML 
Configuration (Second Edition)" to Proposed Edited Recommendation 



This second edition incorporates all known errata as of the publication 
date. The main change is the folding or 'white space' and 'Unicode white 
space' as only 'white space'. The document still reference the Unicode 
specification as the authoritative source of white space definition, all 
the white space references in the previous specification were including 
a reference to Unicode white space. No conformance issues are foreseen 
with this change.


This edition, once it becomes a Recommendation, will supersede the 
previous edition of 27 September 2011.

]]

W3C Advisory Committee members are asked to "Please review the 
specification and indicate whether you endorse it as W3C Recommendation 
or object to its advancement by completing the following questionnaire 
".


-AB

[admin] Call for Editor for DOM4 REC track spec

[Arthur Barstow]

Hi All,

The current Editors of the DOM4 spec are not interested in moving that 
spec toward Recommendation (in the context of WebApps WG). Consequently, 
we need an Editor(s) to work on the DOM4 Recommendation track document.


If you are interested in this Editor position and have relevant 
experience, please contact me offlist.


-Thanks, ArtB

[DOM4] 

CfC: publish LCWD of Pointer Lock; deadline Oct 4

[Arthur Barstow]

This is a Call for Consensus to publish a LCWD of Pointer Lock using the 
following document as the basis for the LC 
.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 4 weeks.

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by October 4 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

[push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Arthur Barstow]

On 9/26/12 1:49 PM, ext SULLIVAN, BRYAN L wrote:

We've previously called for any comments to the current Push API draft [1], and 
would like to promote it to FPWD before TPAC. We haven't received any 
substantive comments as far as I know, which tells me that it could be in good 
shape for publication. With the addition of Telefonica (Eduardo) as co-editor 
and simplification / better alignment with proposals for B2G / Firefox OS, I 
believe we are in shape for FPWD now. So if I could request a CFC for 
publication as FPWD before Oct 15, that would be our preference.

Alternatively we can put this on the agenda for TPAC and discuss/promote it 
then as possible. But in the absence of substantive comments (which tells me we 
have addressed most of the comments on the first ED), I think we should be 
ready for FPWD.

[1] http://dvcs.w3.org/hg/push/raw-file/default/index.html


The requirements for FPWD are relatively loose but because the 
publication of a FPWD starts a Call for (IP) Exclusions, it is helpful 
for some reviewers if the breath of the spec is mostly complete, 
although the depth can certainly be lacking.


What is your view on the set of features/scope? Is the ED covering most 
of the scope? If there are any high priority features missing, what are 
they?


Based on a very quick scan, I noticed:

* The Privacy and Security section is empty and I think it would be 
helpful if some additional informational was added before FPWD.


* The Specific Service Bindings section is empty. It seems like this 
should have some information before FPWD, especially if it is going to 
be a normative section. (Are some of these "bindings" specified outside 
the W3C?)


* Push Framework - it appears this section should be marked as 
non-normative. I think it would be helpful if some type of flow diagram 
was included as well as example application code to use the API 
(although this non-normative info is not necessarily a blocker for FPWD).


* serverProtocols - what are the expectations for the "valid" set of 
values; where are they specified?


Some editorial comments ...

* Define "Web Intent Push Service provider", "Push server" and "webapp" 
or add a link to the definitions.


* Update the references that are out of date (e.g. HTML5).

* Not clear what onopen event is since it isn't part of the PushService API

-Thanks, Art

[pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Arthur Barstow]

On 9/26/12 11:46 AM, ext Vincent Scheib wrote:

On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow  wrote:

* Pointer Lock - Vincent - what's the status of the spec and its implementation?

Firefox 14 and Chrome 22 shipped Pointer Lock implementations to
stable channel users recently. (Check out this Mozilla demo
https://developer.mozilla.org/en-US/demos/detail/bananabread, using
either.)

Pointer Lock specification did have minor adjustments (inter-document
and iframe sandbox security issues, pending state and mouse movement
clarifications). diffs:
http://dvcs.w3.org/hg/pointerlock/log/default/index.html

So, I'm happy to prepare an updated working draft.


Thanks for the update Vincent!

Do you and/or the implementers consider the spec feature complete, which 
is a major factor to determine if the spec is "Last Call ready" (other 
considerations are documented at [1])?


(Bugzilla reports "Zarro Boogs found" [2] and I didn't notice any 
"issue/bug" blocks in the latest ED).


-Thanks, Art

[1] <http://www.w3.org/2005/10/Process-20051014/tr.html#last-call>
[2] 
<https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Pointer%20Lock&resolution=---> 

[admin] Publishing specs before TPAC: CfC start deadline is Oct 15

[Arthur Barstow]

The upcoming TPAC meeting week (Oct 29-Nov2) provides an opportunity for 
joint WG meetings and lots of informal information sharing. As such, it 
can be useful to make new publications before TPAC.


There is a publication "blackout period" around TPAC and Oct 23 is the 
last day to request publication before TPAC. Given our 1-week CfC for 
new publications, weekends, etc., Oct 15 is the last day to start a CfC 
to publish a document before TPAC. However, a lot of groups publish 
documents at this time so starting the CfC earlier is highly recommended.


Scanning [PubStatus], here are some potential candidates to publish 
before TPAC. It would be good to re-publish our newer specs, especially 
if the spec has had some relatively significant changes (since FPWD) 
and/or it is getting some implementation/deployment:


* File API - Arun can you get this spec ready for LC by October 15?

* Gamepad - Scott, Ted - what's the status of the spec and its 
implementation?


* Indexed Database API - Jonas, Eliot - what's the status of LC#1 
comment processing? Is a new LC going to be necessary?


* Pointer Lock - Vincent - what's the status of the spec and its 
implementation?


* Screen Orientation - Mounir - what's the status of the spec and its 
implementation?


* Server-sent Events - Hixie - can you give a rough guestimate on when 
bugs 15495 and 18796 will be fixed? (It looks to me like those are the 
only two bugs blocking CR.)


If any other Editors want to publish a spec before TPAC, that would be 
great so please let us know and I'll start a CfC to publish.


-Thanks, AB

[PubStatus] 

[admin] Call for Editor for XHR REC track doc

[Arthur Barstow]

Hi All,

As you may know, Anne left Opera a few months ago and since the Invited 
Expert route didn't work out, we need an Editor(s) to move the XHR spec 
[XHR] towards Recommendation.


If you are interested in this Editor position, please contact me offlist.

-Thanks, AB

[XHR] 

Re: [xbl] "status of this document" section could use work

[Arthur Barstow]

On 9/20/12 8:24 PM, ext Samuel Bronson wrote:
This does not make it clear why the specification was abandoned, or 
say where more recent efforts in this area are focused; I suggest 
changing it to something more like:


Thanks for the suggestion. If/when we publish that document again, I 
will propose some additional context re the rationale be added.


-Thanks, AB

[WebSockets] Call for Implementations

[Arthur Barstow]

A new Candidate Recommendation of the WebSocket API was published on 
September 20 and that resulted in a Call for Implementations [CfI]:


http://www.w3.org/TR/2012/CR-websockets-20120920/

The root of the test suite for this spec follows. Currently, the test 
suite consists of submissions from Microsoft and Ms2Ger but none of the 
tests have been approved.


http://w3c-test.org/webapps/WebSockets/tests/

Separately, on public-webapps-testsuite [p-w-t], I will start a thread 
re this test suite, e.g. status, plans for approving the submitted 
tests, etc.


-Thanks, AB

[CfI] http://www.w3.org/News/2012#entry-9569
[p-w-t] http://lists.w3.org/Archives/Public/public-webapps-testsuite/

Reminder: Mail List Etiquette [Was: Re: localStorage]

[Arthur Barstow]

On 9/11/12 9:03 PM, ext Sean McHugh wrote:
I submitted a proposal yesterday. I don't want to spam you so this is 
the last time I will make this suggestion directly.


This is the first email I have seen from you on this list.

Please note we have a mail list usage and etiquette policy 
 
we expect _everyone_ to follow. As such ...



I think websql and idb are very bad.


Please refrain from such unqualified judgements and use the list for 
_technical_ discussions about the group's specs.


-Thanks, AB

Re: Call for Review of Content Security Policy 1.0

[Arthur Barstow]

On 9/7/12 12:05 PM, ext Hill, Brad wrote:


The Web Application Security Working Group at the W3C is planning to 
advance Content Security Policy 1.0 to Candidate Recommendation – a 
final set of features and syntax – and is seeking wide review of the 
document at this time. We would especially value the input of members 
of the WebApps WG.


http://www.w3.org/TR/2012/WD-CSP-20120710/



Brad - I noticed the above LCWD says the comment deadline is August 24. 
What is the (extended) deadline?


If there is a document that is being used to "track" this LCWD's 
comments, please let us know its URI.


-Thanks, AB

Re: [EventSource] Feedback Comments

[Arthur Barstow]

On 9/6/12 3:05 PM, ext Karl Dubost wrote:

Hi,

I was ready to send a comment about the spec using the Feedback Comments form
http://dev.w3.org/html5/eventsource/


If you wish to make comments regarding this document in a manner that is 
tracked by the W3C, please submit them via using our public bug database.

— https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG

But there is no component for EventSource spec.


Julian already reported this bug 
.


Please use 
 with 
component of Server-sent Events.


-Thanks, AB

Please don't SPAM our mail list [Was: Re: Social Networking and Elections]

[Arthur Barstow]

On 9/5/12 11:16 AM, ext Adam Sobieski wrote:

Web Applications Working Group,


The subject matter of this mail list is the WG's specifications. Please 
use this list accordingly.


If anyone wants to reply to Adam's e-mail, please use some other mail 
list (such as www-t...@w3.org).


-Thanks, AB

CfC: publish FPWD of DOM Parsing and Serialization; deadline Sept 11

[Arthur Barstow]

This is a Call for Consensus to publish a First Public Working Draft of 
the DOM Parsing and Serialization spec using the following ED as the 
basis .


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to 
begin reviewing the document. The FPWD reflects where the group is on 
this spec at the time of publication; it does not necessarily mean there 
is consensus on the spec's contents.


If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by September 11 at the latest. Positive response 
is preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

Re: Editor's draft created of DOM Parsing and Serialization Spec

[Arthur Barstow]

On 8/29/12 7:55 PM, ext Travis Leithead wrote:


Folks, following up on my action item from TPAC 2011 (yeah, I know…), 
the DOM Parsing and Serialization Editor’s Draft specification has 
been created!


http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html



Thanks for creating this ED!

BTW, what changes (if any) do we want to make before we start a CfC for 
First Public Working Draft?



A list of active bugs against the spec are being maintained against 
this component in the Bug tracking system:


https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM%20Parsing%20and%20Serialization&resolution=---



OK, and I see that Mike created a separate component under the WHATWG 
product for Ms2ger's DOM P&S version at html5.org [1].


-AB

[1] 

CfC: publish Candidate Recommendation of WebSocket API; deadline September 7

[Arthur Barstow]

The comment period for the August 9 LCWD of The WebSocket API [LCWD] 
ended on August 30. During that time, two bugs were submitted against 
the LCWD ([18623] and [18509]). Both of these bugs requested 
non-normative changes and fixes for both of these bugs are included in 
the version of the spec I created as a Draft CR [CR-Draft].


As such, this is a Call for Consensus to publish a Candidate 
Recommendation of WebSocket API using [CR-Draft] as the basis (see 
[Diff] for a difference between [LCWD] and [CR-Draft]).


As noted in the CfC to publish the LCWD [CfC-LCWD], bugs [15209], 
[15210], and [17264] remain open (and are not addressed in this version 
of the spec).


This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in the Process 
Document 
.


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with the proposal. The deadline for 
comments is September 7 and all comments should be sent to 
public-webapps at w3.org.


Thanks, AB

[CR-Draft] 


[LCWD] 
[Diff] 

[CfC-LCWD] 


[18509] 
[18623] 
[15209] 
[15210] 
[17264] 

CfC: publish LCWD of DOM 3 Events; deadline August 31

[Arthur Barstow]

[ cross-posting to www-dom and public-webapps -> please reply just to 
www-dom ]


All - Travis has the D3E spec down to Zarro Bugs [1] and as such this is 
a Call for Consensus (CfC) to publish a LCWD of the spec 
.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 3 weeks.

If you have any comments or concerns about this CfC, please send them to 
www-...@w3.org by August 31 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

[1] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---

CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 28

[Arthur Barstow]

Marcos would like to publish a "Proposed Edited Recommendation" [PER] of 
the Widget Packaging and XML Configuration spec [REC] to incorporate the 
spec's errata and this is a Call for Consensus to do so.


The [Errata] has already been reflected in the [Proposed-PER] (see 
[Diff]) and it includes a new title of "Packaged Web Apps (Widgets) - 
Packaging and XML Configuration (Second Edition)".


Please send all comments regarding this CfC to the public-webapps@w3.org 
mail list by August 28 and note silence will be considered as agreement 
with the proposal. If you support this CfC, a positive response is 
preferred and encouraged.


-Thanks, AB

[PER] 
[REC] 
[Errata] 
[Proposed-PER] 
[Diff] 

Re: [admin] using Bugzilla's "component tracking feature"? [Was: [webcomponents]-ish: Visibility of work in Bugzilla

[Arthur Barstow]

On 8/20/12 5:05 PM, ext Michael[tm] Smith wrote:

Arthur Barstow , 2012-08-20 08:11 -0400:

On Thu, Aug 16, 2012 at 10:00 AM, Kang-Hao (Kenny) Lu 
 wrote:
We have public-webapps-bugzilla[1] already, but I have no idea why 
we can't just turn on the component watching feature at the W3C 
Bugzilla instance. 

I agree following public-webapps-bugzilla is a bit like a `fire hose` so
turning on component-level watching would be useful.

Mike - can Bugzilla's "component watching feature" be turned on (for at
least WebApps' components)?

What "component watching feature"?


I quoted what Kenny said so he may be able to elaborate.


I'm not aware of any such feature and I
don't find any config parameters in our bugzilla instance that would seem
to be related to such a feature.


OK.

-Thanks, AB

Re: RfC: LCWD of WebSocket API; deadline August 30

[Arthur Barstow]

On 8/10/12 12:34 AM, ext Takeshi Yoshino wrote:

No technical comments.

A few editorial comments.

> CLOSING (numeric value 2)
> The connection is going through the closing handshake.

The readyState can enter CLOSING also when close() is called before 
establishment. In that case, it's not going through closing handshake.


>  // networking
>   attribute EventHandleronopen;

insert an SP between EventHandler and onopen
(already fixed on the editor's draft)

> When the user agent validates the server's response during the 
"establish a WebSocket connection" algorithm, if the status code 
received from the server is not 101 (e.g. it is a redirect), the user 
agent must fail the websocket connection.


websocket -> WebSocket

> If the user agent was required to fail the websocket connection or 
the WebSocket connection is closed with prejudice, fire a simple event 
named error at the WebSocket object. [WSP]


websocket -> WebSocket

> interface CloseEvent : Event {
>   readonly attribute boolean wasClean;
>   readonly attribute unsigned short code;
>   readonly attribute DOMString reason;
> };

missing anchor on reason to its description


Hi Takeshi - please file a bug 
() for your comments 
(). 



-Thanks, AB

[admin] using Bugzilla's "component tracking feature"? [Was: [webcomponents]-ish: Visibility of work in Bugzilla

[Arthur Barstow]

On 8/16/12 1:29 PM, ext Dimitri Glazkov wrote:

That's a great point. It's already tracking all of the Web Components
work (it looks like I am by far the spammiest -- not the best of
honors, but I'll take it). Perhaps we could just encourage people to
listen to that?

:DG<

On Thu, Aug 16, 2012 at 10:00 AM, Kang-Hao (Kenny) Lu
 wrote:

(12/08/17 0:36), Dimitri Glazkov wrote:

Another idea is to have a separate mailing list for this. At least,
there will be some opt-in step that will give other
public-webapps-nauts at choice.

We have public-webapps-bugzilla[1] already, but I have no idea why we
can't just turn on the component watching feature at the W3C Bugzilla
instance.


I agree following public-webapps-bugzilla is a bit like a `fire hose` so 
turning on component-level watching would be useful.


Mike - can Bugzilla's "component watching feature" be turned on (for at 
least WebApps' components)?


-Thanks, Art

Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8

[Arthur Barstow]

Chaals, Marcos,

Based on this discussion, I concluded this CfC has failed to show we 
have consensus. As such, after you two have agreed on a version of the 
spec that satisfies all of Chaals' concerns, my recommendation is we 
start a new CfC.


-Thanks, AB

On 7/26/12 9:52 AM, ext Chaals McCathieNevile wrote:
On Wed, 25 Jul 2012 22:17:42 +0200, Marcos Caceres  
wrote:



On Wednesday, 25 July 2012 at 19:02, Chaals McCathieNevile wrote:

On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow 
mailto:art.bars...@nokia.com)>

wrote:

> Marcos would like to publish a "Proposed Edited Recommendation" 
[PER] > of the Widget Packaging and XML Configuration spec [REC] to

> incorporate the spec's errata and this is a Call for Consensus to do
> so.

Currently I object. I would support the publication if:

1. It restored the pointer to an external errata document (Marcos is
clever, but there may still be errata) and


Not sure what you mean here (and not just about being clever!:) )? 
There is a pointer to errata…

http://dev.w3.org/2006/waf/widgets/errata.html
It's right at the top of the document? What am I missing?


The new version says that it incorporates the errata there, but 
removes the statement that any further errata might be found at the 
same place. I suggest reinstating the text that was taken out, since 
there may be a need for errata on this document (personally I would 
prefer to see a new version, allowing for example internationalisation 
of more elements)


2. It restored the status of the document to cover patent policy and 
where to send feedback and


Ah, sorry… SoTD was from the editor's draft. I need to find a 
boilerplate for a PER. I'm going to copy the one from XML 5th Ed., 
but it's a bit of work so I'll do it RSN.


OK, please do.


3. It fixes the normative references to include authors and point to
stable versions.


I will only link to "stable" versions for normative references - 
informative references don't matter.


I can live with that. However I note that it is useful to know what 
version of something that you used as an informative reference was the 
one you actually read. HTML5 is different from what it was when P&C 
was published. For most cases it doesn't matter (it is useful to have 
a link to the latest and greatest version with all the brilliant ideas 
the editor had after a saturday-night binge included), but for careful 
use of the documents it can actually make a material difference.


Re editors: can't find anything in the process document that requires 
them to be added.


1. It is a generally accepted convention that assists in recognising a 
reference, particularly from a printed version (yes, people still 
print specifications, often. There are sound reasons why this is 
likely to continue for some years).
2. Many of these publications are essentially volunteer work. The 
efforts of the editors (or the money of their employers that supports 
them taking on the work) are often motivated in part by the fact that 
their name is cited by convention. I don't see the use case for 
breaking this convention, and the small benefit that it provides to 
those who edit specifications.



Of course, you are more than invited to add them yourself to the
spec if you really want.


Sure, I can do that.

They were in the REC, so you can copy/paste them from there (or email 
me the markup and I'll paste them in for you). However, I see no use 
case for including them given that there is a hyperlink to their spec 
(which already lists them).


Cheers

Chaals

Re: IndexedDB and RegEx search

[Arthur Barstow]

On 7/31/12 2:17 PM, ext Michael Brooks wrote:
I like IndexedDB and non-relational databases.  One feature that is 
very useful is the ability to search by regular expression:

http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-RegularExpressions

By not having this feature,  I can't port my application to IndexedDB 
from WebSQL because it relies upon LIKE statements for text search.  
Text search could easily be replaced by a RegEx search,  however this 
feature is unfortunately not apart of IndexedDB.  It seems like this 
feature was just forgotten when writing the spec of IndexedDB.


FYI, I added RegEx search to the IDB "feature list" i.e. features for 
v1+ .


-AB

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

[Arthur Barstow]

On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote:

Sorry for my late comment.

While I think it's fine to publish LCWD Selectors API as it is, it would
be nice if it can address my comment in [1]. By "address", I mean either
define the desired behavior or explicitly mark it as undefined (which I
think is better than not saying anything because an explicit "undefined"
tells a spec reader that relevant discussions can be found in the list).

[1]
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518


Lachlan, Kenny - what is the status of this comment (f.ex. does the spec 
need to be changed)?


-Thanks, Art

F2F meeting Oct 29-30 in Lyon France; registration deadline Oct 16

[Arthur Barstow]

Hi All,

As announced earlier, WebApps will have a f2f meeting October 29-30 as 
part of the W3C's annual Technical Plenary Week 
 in Lyon France.


WebApps' meeting page is 
. We will again 
preallocate some time slots for specific agenda topics and use an 
unconference style meeting to determine the remainder of agenda topics. 
Proposed agenda topics are welcome at any time, via e-mail or updating 
the meeting page.


Registration for the meeting is required and there is a €45 per day fee 
 that increases to €135 
per day on October 17.


The "Technical Plenary" meeting is all day Wednesday October 31. This 
meeting (now mostly an unconference style) is often a good way to learn 
about and discuss more general topics. See the 2011 TPAC agenda for more 
info .


NOTE: the TPAC meeting page includes the following warning "*It is 
strongly recommended to make hotel reservations as soon as possible as 
there will be other meetings at the conference center.*"


-Thanks, AB

CfC: publish LCWD of WebSocket API; deadline August 6

[Arthur Barstow]

This is a Call for Consensus to publish a LCWD of WebSocket API using 
the following document as the basis for the LC 
.


Note that besides the ArrayBuffer patch ([r1.272] which fixes bug 17263 
as discussed in [1]), to reduce fragmentation with the latest ED, the 
Draft LC also includes [r1.271] (adds a Warning) and [r1.273] 
(editorial). The Draft LC also includes the bug fixes noted in the July 
18 CfC to publish a CR of this spec [2].


[Bugz] shows five open bugs: 12510, 15209, 15210, 15829 and 17264 and 
the Draft LC includes fixes for 12510 (Julian's patch) and 15829.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 3 weeks.

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by August 6 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0229.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0096.html
[r1.271] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.270;r2=1.271;f=h
[r1.272] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.271;r2=1.272;f=h
[r1.273] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.272;r2=1.273;f=h
[Bugz] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=WebSocket%20API%20%28editor%3A%20Ian%20Hickson%29&resolution=---

Re: [websockets] ArrayBuffer added back to the ED

[Arthur Barstow]

On 7/26/12 8:41 AM, ext Takashi Toyoshima wrote:

Hi,

Thank you for handling this topic.
I support this change [r1.272] is applied to v1 spec.


OK, thanks for being clear.

Anyone else, especially those that added a comment to bug 17263, have 
any feedback on whether or not we should block the WebSocket API CR and 
first publish a new LC with Hixie's fix for this bug?


In the absence of any additional feedback, I will start a new CfC for LC 
(and stop the request to publish a CR).


-Thanks, AB



On Thu, Jul 26, 2012 at 5:01 AM, Arthur Barstow  wrote:

Hi All,

Earlier today, Hixie added ArrayBuffer back to the WebSocket API ED (see
[r1.272]) as requested in bug [17263] which ATM is Resolved/WontFix.

Since the CfC to move this spec to CR passed on July 18 (but the CR has not
yet been published), I would appreciate it you would please Raise Your Hand
if you support this fix for v1.

If there is consensus for this fix to be included in v1, it would mean the
next step on the REC track would be to return the spec to LCWD.

-Thanks, AB

[r1.272]
<http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.271;r2=1.272;f=h>
[17263] <https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263>

[websockets] ArrayBuffer added back to the ED

[Arthur Barstow]

Hi All,

Earlier today, Hixie added ArrayBuffer back to the WebSocket API ED (see 
[r1.272]) as requested in bug [17263] which ATM is Resolved/WontFix.


Since the CfC to move this spec to CR passed on July 18 (but the CR has 
not yet been published), I would appreciate it you would please Raise 
Your Hand if you support this fix for v1.


If there is consensus for this fix to be included in v1, it would mean 
the next step on the REC track would be to return the spec to LCWD.


-Thanks, AB

[r1.272] 


[17263] 

CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8

[Arthur Barstow]

Marcos would like to publish a "Proposed Edited Recommendation" [PER] of 
the Widget Packaging and XML Configuration spec [REC] to incorporate the 
spec's errata and this is a Call for Consensus to do so.


The [Errata] has already been reflected in the [Proposed-PER] (see 
[Diff]) and it includes a new title of "Packaged Web Apps (Widgets) - 
Packaging and XML Configuration".


Please send all comments regarding this CfC to the public-webapps@w3.org 
mail list by August 8 and note silence will be considered as agreement 
with the proposal. If you support this CfC, a positive response is 
preferred and encouraged.


-Thanks, AB

[PER] 
[REC] 
[Errata] 
[Proposed-PER] 
[Diff] 



 Original Message 
Subject: 	Re: [widgets] Request to publish is P&C as Proposed Edited 
Recommendation

Date:   Tue, 24 Jul 2012 12:49:34 +0100
From:   ext Marcos Caceres 
To: 
CC: Barstow Arthur 



On Tuesday, 24 July 2012 at 12:27, Marcos Caceres wrote:


Earlier this year I corrected a bunch of things in P&C (see [errata]), so I think it would be good 
to republish the spec. Also, with the name of the spec still being cited as an "issue", I've 
changed the name of the specification to "Packaged Web Apps (Widgets) - Packaging and XML 
Configuration". Hopefully that new coat of paint will stick to the bikeshed. I would kindly 
request a CFC to republish.

Kind regards,
Marcos



[errata] http://dev.w3.org/2006/waf/widgets/errata.html

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Arthur Barstow]

On 7/12/12 8:06 AM, ext Julian Reschke wrote:

On 2012-07-12 13:47, Arthur Barstow wrote:

I agree with Hixie that ideally the fix would apply to the original
source rather than 1-off versions in dev.w3. However, if that isn't
worked out, I will apply Julian's patch to the CR version.


Sounds good.


FYI, your patch was applied to this document that will be used as the 
basis for the CR 
<http://dev.w3.org/html5/websockets/publish/CR-websockets-Aug-2012.html>.



What do we do about the normative reference to a non-W3C-part of the 
WhatWG spec? ("decoded as UTF-8, with error handling")


What about using <http://dev.w3.org/html5/spec/single-page.html#utf-8>?

-Thanks, AB

[Server-sent Events] Status of 26-April-2012 LC comments

[Arthur Barstow]

Hi All,

The comment deadline for the April 26 SSE LC [LC] ended May 17. Since 
the LC was published, I noted 2 comments, 1 bug report (see below) and 5 
ED updates (see below).


The comments are:

1. 17-Apr-2012; Odin Hørthe Omdal (Opera); 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0226.html 
; [Server-Sent Events] Infinite reconnection clarification.


Odin Hørthe, Hixie, All, - I don't see a clear conclusion/consensus and 
no bug was filed. As such, please indicate - via a reply to the 
_original_ thread - your take on this comment and please file a bug if 
applicable.


2. 29-Apr-2012; Neil Jenkins (Opera); [Server-Sent Events] Network 
connection clarification ; 10-July-2012 Hixie suggests error handling 
could be supported for v2 
. 
Additionally, Chaals indicated in 
 this 
could be considered a v1 bug.


Neil, Hixie, Chaals, All, - I don't see a clear conclusion/consensus and 
no bug was filed. As such, please indicate - via a reply to the 
_original_ thread - your take on this comment and please file a bug if 
applicable.


(If these two comments do not require substantive changes for v1, it 
appears the spec is ready for a CfC to publish as a Candidate 
Recommendation.)


-Thanks, Art

[LC] http://www.w3.org/TR/2012/WD-eventsource-20120426/

= Bug report: only 16866 
; 26-Apr-2012 
filed by ann...@opera.com; FIXED on 10-July-2012 ; Fix: 
. 
I consider this a non-substantive change


= ED Updates (the LC was based on 1.215)

* 216 
. 
Non-substantive (stylesheet update)


* 217 
. 
Non-substantive(change "event name" to "event type")


* 218 
. 
Non-substantive (one additional change of "event name" to "event type")


* 219 
.Non-substantive 
(remove "[TreatNonCallableAsNull]" WebIDL qualifier from attributes)


* 220 
. 
Non-substantive (fixes bug 16866)


= Bugs Open when CfC for LC was started: 14900, 15495, 16070, hence an 
indication the group does not consider them mandatory for v1

Reminder: RfC: LCWD of Selectors API Level 1; deadline July 19

[Arthur Barstow]

 Original Message 
Subject:RfC: LCWD of Selectors API Level 1; deadline July 19
Resent-Date:Thu, 28 Jun 2012 14:59:09 +
Resent-From:
Date:   Thu, 28 Jun 2012 10:58:36 -0400
From:   ext Arthur Barstow 
To: public-webapps 



This is a Request for Comments for the June 28 Last Call Working Draft
of Selectors API Level 1:

<http://www.w3.org/TR/2012/WD-selectors-api-20120628/>

The comment deadline is July 19 and all comments should be sent to the
public-webapps@w3.org list with a Subject: prefix of " [selectors-api]".

-Thanks, AB

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Arthur Barstow]

On 7/11/12 7:52 PM, ext Ian Hickson wrote:

On Wed, 11 Jul 2012, Julian Reschke wrote:


OK; the amount of work is ~45 minutes (and probably can be automated
for future publication cycles).

See attachments; an edited version of the current editor's draft, and
the diffs. ...

..and the diff was reversed; new version attached.


Thanks, I do appreciate this patch Julian!


Applying that diff to the spec on dev.w3.org


I agree with Hixie that ideally the fix would apply to the original 
source rather than 1-off versions in dev.w3. However, if that isn't 
worked out, I will apply Julian's patch to the CR version.


-Thanks, AB

RfC: Content Security Policy 1.0 Last Call; deadline Aug 24

[Arthur Barstow]

WebApps has been asked to review the July 10 LCWD of WebAppSec's Content 
Security Policy 1.0 spec .


Individual WG members are encouraged to provide individual feedback 
directly to the Web Perf WG. If you have comments, please send them to 
the following list by August 24:


public-webapp...@w3.org
http://lists.w3.org/Archives/Public/public-webappsec/

If anyone in WebApps wants to propose an official WG response, please do 
so ASAP, in reply to this email so the Working Group can discuss it.


-Thanks, AB

CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

[Arthur Barstow]

Yesterday Hixie closed several of the Web Sockets bugs mentioned in the 
e-mail below and he updated others. I think this now provides a basis to 
determine if we have consensus to publish a Candidate Recommendation. As 
such, this is a Call for Consensus to publish a Candidate Recommendation 
of Web Sockets.


I propose the CR be based on the May 24 LC [1] plus include:

1. The editorial patch for 17224 [2]

2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some 
attributes. If anyone considers this change as substantive, please speak 
up. Cameron - what's your opinion on this?


Additionally:

* 12510 - as Hixie indicated in the bug, if anyone is willing to create 
a patch, please contact Hixie privately and please let me know of your 
intent


* 15829 - the CR will include a fix for this as was done for the LC

* 16927 - the CR will include a fix for this as was done for the LC

* Other bugs to remain open for v.next: 15209, 15210, 17073, 17264, 17685

* The CR's exit criteria be identical to the December 2011 CR.

This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in the Process Document:


http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs

Positive response is preferred and encouraged and silence will be 
considered as agreeing with the proposal. The deadline for comments is 
July 18 and all comments should be sent to public-webapps at w3.org.


-Thanks, AB

[1] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.269;r2=1.270;f=h
[2] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.268;r2=1.269;f=h

[3] http://www.w3.org/TR/2012/WD-websockets-20120524/


 Original Message 
Subject: 	[websockets] Seeking comments on moving back to CR; deadline 
June 28

Resent-Date:Thu, 21 Jun 2012 14:29:06 +
Resent-From:
Date:   Thu, 21 Jun 2012 10:28:31 -0400
From:   ext Arthur Barstow 
To: public-webapps 



Hi All,

I created a tracking document for the two comments and five bugs that
were submitted against the 24 May LCWD of Web Sockets (or in the
approximate time frame of that publication):
<http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-24May2012>.

Below is my "take" on these bugs and comments. It would be good to get
this spec back to CR and hence closer toward the IP commitments that
will only be final when the spec reaches Recommendation.

Bugs:

* 17073 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073> - marked
as an Enhancement; don't include in the v1 CR

* 17224 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224> - this
looks like an Editorial bug to me as I stated in the bug. Assuming there
is consensus the text should be "unsolicited pongs", if Hixie can't fix
this before the v1 CR copy is created, I'll make this change in the v1 CR.

* 17262 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262> - Jonas'
view as expressed in
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262#c13> seems
reasonable so I propose closing this with a resolution of WorksForMe.

* 17263 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263> -
send(ArrayBuffer), which was included in the December 2011 CR, has been
implemented and presumably must be supported by some browsers (e.g.
bc/legacy reasons). As such, it seems reasonable to fix this bug and
perhaps we could argue a new LCWD is not needed since it has already
been implemented.

* 17264 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264> - this
bug appears to be a rehash of bug 13104 which was Fixed in October 2011
so I propose closing this with a resolution of Duplicate.

Comments:

* LC-1
<http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0807.html> -
The 28-May-2012 reply by Takeshi Yoshino notes this is a Chrome bug and
not a spec bug. The 1-June-2012 reply by Simon Pieters indicates the
Protocol spec needs to be updated. As such, I don't think any changes
are needed for v1 of the spec.

* LC-2
<http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html> -
This is an editorial bug and is already captured in Bug 12510. Ideally,
this bug would be fixed before the v1 CR branch is created. However, if
Hixie can't fix it before then and if no one else creates an acceptable
patch for Hixie, I don't support blocking the v1 CR for this.

Please send all comments by June 28.

-Thanks, AB

Re: [websockets] Seeking comments on moving back to CR; deadline June 28

[Arthur Barstow]

On 6/21/12 4:53 PM, ext Julian Reschke wrote:

On 2012-06-21 16:28, Arthur Barstow wrote:

...
<http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html> 
-

This is an editorial bug and is already captured in Bug 12510. Ideally,
this bug would be fixed before the v1 CR branch is created. However, if
Hixie can't fix it before then and if no one else creates an acceptable
patch for Hixie, I don't support blocking the v1 CR for this.
...


I disagree that this is editorial. 


Yes I agree that "editorial" wasn't a particularly good characterization 
of bug 12510.




Without proper references the spec simply is incomplete.



Now that we have the URL spec in /TR/, it seems like that spec just 
needs to be added as a reference.


-AB

[websockets] Seeking comments on moving back to CR; deadline July 9

[Arthur Barstow]

Hi All,

Since this was a busy week for some group members and I will be offline 
for several days, let's extend the deadline for comments until July 9.


If you have any feedback, please reply by July 9.

-Thanks, Art

 Original Message 
Subject:[websockets] Seeking comments on moving back to CR; 
deadline June 28

Resent-Date:Thu, 21 Jun 2012 14:29:06 +
Resent-From:<mailto:public-webapps@w3.org>
Date:   Thu, 21 Jun 2012 10:28:31 -0400
From:   ext Arthur Barstow 
<mailto:art.bars...@nokia.com>

To: public-webapps <mailto:public-webapps@w3.org>



Hi All,

I created a tracking document for the two comments and five bugs that
were submitted against the 24 May LCWD of Web Sockets (or in the
approximate time frame of that publication):
<http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-24May2012><http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-24May2012>.

Below is my "take" on these bugs and comments. It would be good to get
this spec back to CR and hence closer toward the IP commitments that
will only be final when the spec reaches Recommendation.

Bugs:

* 17073 
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073><https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073> 
- marked

as an Enhancement; don't include in the v1 CR

* 17224 
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224><https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224> 
- this

looks like an Editorial bug to me as I stated in the bug. Assuming there
is consensus the text should be "unsolicited pongs", if Hixie can't fix
this before the v1 CR copy is created, I'll make this change in the v1 CR.

* 17262 
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262><https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262> 
- Jonas'

view as expressed in
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262#c13><https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262#c13> 
seems

reasonable so I propose closing this with a resolution of WorksForMe.

* 17263 
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263><https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263> 
-

send(ArrayBuffer), which was included in the December 2011 CR, has been
implemented and presumably must be supported by some browsers (e.g.
bc/legacy reasons). As such, it seems reasonable to fix this bug and
perhaps we could argue a new LCWD is not needed since it has already
been implemented.

* 17264 
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264><https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264> 
- this

bug appears to be a rehash of bug 13104 which was Fixed in October 2011
so I propose closing this with a resolution of Duplicate.

Comments:

* LC-1
<http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0807.html><http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0807.html> 
-

The 28-May-2012 reply by Takeshi Yoshino notes this is a Chrome bug and
not a spec bug. The 1-June-2012 reply by Simon Pieters indicates the
Protocol spec needs to be updated. As such, I don't think any changes
are needed for v1 of the spec.

* LC-2
<http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html><http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html> 
-

This is an editorial bug and is already captured in Bug 12510. Ideally,
this bug would be fixed before the v1 CR branch is created. However, if
Hixie can't fix it before then and if no one else creates an acceptable
patch for Hixie, I don't support blocking the v1 CR for this.

Please send all comments by June 28.

-Thanks, AB

RfC: LCWD of Selectors API Level 1; deadline July 19

[Arthur Barstow]

This is a Request for Comments for the June 28 Last Call Working Draft 
of Selectors API Level 1:




The comment deadline is July 19 and all comments should be sent to the 
public-webapps@w3.org list with a Subject: prefix of " [selectors-api]".


-Thanks, AB

CfC: publish new WD of File API; deadline July 3

[Arthur Barstow]

Hi All - Arun is back to actively editing the File API spec and this is 
a Call for Consensus to publish a new WD of the spec. Please note that 
Arun will be committing some changes during this CfC and that the ED 
does not yet use the WD template:




Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by July 3 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean  agreement with the proposal.


-Thanks, AB

[websockets] Seeking comments on moving back to CR; deadline June 28

[Arthur Barstow]

Hi All,

I created a tracking document for the two comments and five bugs that 
were submitted against the 24 May LCWD of Web Sockets (or in the 
approximate time frame of that publication): 
.


Below is my "take" on these bugs and comments. It would be good to get 
this spec back to CR and hence closer toward the IP commitments that 
will only be final when the spec reaches Recommendation.


Bugs:

* 17073  - marked 
as an Enhancement; don't include in the v1 CR


* 17224  - this 
looks like an Editorial bug to me as I stated in the bug. Assuming there 
is consensus the text should be "unsolicited pongs", if Hixie can't fix 
this before the v1 CR copy is created, I'll make this change in the v1 CR.


* 17262  - Jonas' 
view as expressed in 
 seems 
reasonable so I propose closing this with a resolution of WorksForMe.


* 17263  - 
send(ArrayBuffer), which was included in the December 2011 CR, has been 
implemented and presumably must be supported by some browsers (e.g. 
bc/legacy reasons). As such, it seems reasonable to fix this bug and 
perhaps we could argue a new LCWD is not needed since it has already 
been implemented.


* 17264  - this 
bug appears to be a rehash of bug 13104 which was Fixed in October 2011 
so I propose closing this with a resolution of Duplicate.


Comments:

* LC-1 
 - 
The 28-May-2012 reply by Takeshi Yoshino notes this is a Chrome bug and 
not a spec bug. The 1-June-2012 reply by Simon Pieters indicates the 
Protocol spec needs to be updated. As such, I don't think any changes 
are needed for v1 of the spec.


* LC-2 
 - 
This is an editorial bug and is already captured in Bug 12510. Ideally, 
this bug would be fixed before the v1 CR branch is created. However, if 
Hixie can't fix it before then and if no one else creates an acceptable 
patch for Hixie, I don't support blocking the v1 CR for this.


Please send all comments by June 28.

-Thanks, AB

Re: CfC: publish FPWD of Fullscreen spec; deadline May 24

[Arthur Barstow]

On 6/21/12 5:16 AM, ext Anne van Kesteren wrote:

On Tue, Jun 19, 2012 at 10:48 PM, fantasai
  wrote:

You could just work in the explanation I sent in
  http://www.w3.org/mid/4fc64100.3060...@inkedblade.net

Added a note.

The reason this is not very elaborated is that this really belongs in
a CSS specification that defines the layout box model and painting
order etc. in detail. As part of that you would have the top layer
concept and ways to hook into it via pseudo-elements, such as
::backdrop. And some non-normative description around it to aid people
new to the material.

Having this in Fullscreen is just patching holes in the CSS 2.1
specification, which is not a great way to do things.


Daniel, Fantasai - please confirm whether or not Anne's latest changes 
([1],[2]) address the "#2 issue" ([3]) that is blocking FPWD:




-Thanks, AB

[1] https://dvcs.w3.org/hg/fullscreen/rev/41052063ef66
[2] https://dvcs.w3.org/hg/fullscreen/rev/23f36a1db497
[3] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1252.html

Re: CfC: publish FPWD of Fullscreen spec; deadline May 24

[Arthur Barstow]

On 6/19/12 3:49 AM, ext Daniel Glazman wrote:

Le 19/06/12 09:41, Anne van Kesteren a écrit :
On Tue, Jun 19, 2012 at 1:45 AM, 
fantasai  wrote:

It looks like you missed #2.


I think ::backdrop is clear enough. Not entirely sure what you would
expect seeing there more than what it already says.

Well, the spec says how it's named, where it is created and still lacks
a description of *WHAT IT IS*, functionnally speaking... It would help
really a lot to have such an explanation.


Anne, Tantek, please work Daniel, Fantasai, et al. to address their 
concern(s).


(AFAIK, this is the only issue blocking FPWD.)

-Thanks, AB

Re: CfC: publish FPWD of Fullscreen spec; deadline May 24

[Arthur Barstow]

On 6/19/12 3:52 AM, ext Daniel Glazman wrote:

Le 18/06/12 13:09, Arthur Barstow a écrit :

On 5/30/12 10:38 AM, ext Daniel Glazman wrote:

Le 30/05/12 14:43, Arthur Barstow a écrit :

Chris, Daniel, Peter - when will the CSS WG make a decision on the 
FPWD?


We'll try to make one today during our weekly conf-call. Please note
that we're going to review the bits of this document falling under CSS
WG's wings. In particular section 6. Peter and I already have 
discovered

a few things :

1. "position: center" in section 6.1 refers to an Editor's Draft 
that is

not actively discussed at this time. Only normative references
should be made to CSS specs or the Fullscreen draft will have to wait
until that ED becomes a REC to itself become a REC.

2. the ::backdrop pseudo-element is not explained in the document
outside of section 6.2. It's unclear to me why it is needed, what
it represents, etc.

3. the parenthesis in section 6.2 seems to me to contain a copy/paste
error "above the element below the element"

4. "layer" and "layer 10" in section 6.1 are unclear. "Layer" is used
nowhere in CSS references used in this spec. This must be clarified.


Does the latest ED
<http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html> address
the above concerns?


No, item 2 above is still not addressed, and I guess most readers
of the document won't understand what functionally represents
::backdrop.


1. the definition of requestFullScreen() says what are the steps it
should run but it does not even say what feature it provides. I think
a sentence saying "The requestFullScreen() method sends a request for
the Element to go fullscreen. Please see section 7 for the Security
Considerations attached to this method." is needed.

2. allowfullscreen and iframe in section 7 should be hyperlinks. I note
the reference is at WHATWG while it should be at W3C.


These two points are still unaddressed too.


My interpretation of your comments is the first set (#1-#4 above) are 
considered FPWD Showstoppers by the CSS WG and the second set of 
comments (#1-#2) were your personal comments (since they are related to 
the API and process) and as such, Not FPWD Showstoppers.


Given this interpretation - and of course, please correct it if it is 
wrong - it appears the only remaining FPWD Showstopper is #2 in the 
first set of comments. Is that correct?


(FYI, before the FPWD is published in /TR/, the HTML reference will use 
a link to the W3C's HTML5 spec.)


-Thanks, AB

Re: CfC: Publish FPWD of Web Intents spec; deadline June 12

[Arthur Barstow]

On 5/29/12 2:45 PM, ext James Hawkins wrote:

Dave Raggett (d...@w3.org) made a call [1] on April 10 to publish a
first public working draft, and this is a Call for Consensus to do so,
using the following document as the basis:



I included public-webapps and public-device-apis on this CfC since Web
Intents is a joint-deliverable [2][3] between these two groups.

By publishing this FPWD, the group sends a signal to the community to
begin reviewing the document. The FPWD reflects where the group is on
this spec at the time of publication; it does not necessarily mean
there is consensus on the spec's contents.

Positive response to this CfC is preferred and encouraged and silence
will be considered as agreement with the proposal. The deadline for
comments is June 12. Please send all comments to:


Dave - it appears this CfC passed. Unless I hear otherwise from you, I 
will assume DAP will take care of the Transition Request and Publication 
Request.


-Thanks, AB




  public-web-inte...@w3.org

Thanks,
James Hawkins

[1] http://lists.w3.org/Archives/Public/public-web-intents/2012Apr/0016.html
[2] http://www.w3.org/2012/webapps/charter/
[3] http://www.w3.org/2011/07/DeviceAPICharter

Fwd: IndieUI Call For Proposals

[Arthur Barstow]

The "Independent User Interface" WG (aka IndieUI) was started a few 
weeks ago [Charter] and they now have a CfP for the group's two 
specifications: IndieUI Events, and IndieUI User Context. Details below.


-AB

[Charter] http://www.w3.org/2012/05/indie-ui-charter

 Original Message 
Subject:IndieUI Call For Proposals
Resent-Date:Tue, 19 Jun 2012 01:44:24 +
Resent-From:
Date:   Mon, 18 Jun 2012 21:43:56 -0400
From:   ext Janina Sajka 
To: Independent User Interface Task Force 



  Call for Proposals: Use Cases, Requirements and Specification Inputs
 Independent User Interface Task Force
   World Wide Web Consortium
  18 June 2012

The WAI Independent User Interface (IndieUI) Working Group and the Web Events
Working Group are now seeking proposals from W3C members for their  two joint
deliverables:

1.) Indie UI: Events 1.0, an abstraction between device-specific user
interaction events and inferred user intent such as scroll, activate, etc. This
provides an intermediate layer between device- and modality-specific user
interaction events, and the basic user interface functionality used by Web
applications. Indie UI: Events focuses on granular user interface interactions
such as scrolling the view, canceling an action, changing the value of a user
input widget, selecting a range, placing focus on an object, etc.  Implementing
platforms will take modality-specific user input, user idiosyncratic heuristics
to determine the specific corresponding Indie UI event, and send that to the
Web application (along with details of the modality-specific input such as
mouse or keyboard events should applications wish to process it).

2.) Indie UI: User Context 1.0, a set of properties and methods related to
the environmental context of a specific user, and a vehicle to access them to
facilitate a Web application's ability to adapt to the user's needs. This is
meant to provide information about whether a user is using a screen reader,
screen magnifier, or other Assistive Technology, and to expose relevant user
settings, allowing optimal adaptation of the Web application's user interface.

In addition to inputs for the above deliverables, we also welcome and encourage
Use Cases and Requirements for these deliverables. Please see the related wiki
that includes some initial Use Case inputs:
http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements

Proposals received will be evaluated for use as initial starting points in the
creation of these deliverables by the IndieUI Task Force, which is the locus of
joint work on these deliverables for the WAI_IndieUI WG and the Web Events WG.

Proposals should be submitted by 15 July 2012, and should be submitted to the
IndieUI Task Force's email list (public-indie...@w3.org).  Proposals submitted
after that date are still welcome but may not be included in First Public
Working Drafts.

More information concerning the work of the IndieUI Task Force, including
instructions on how to participate, is available on the IndieUI Task Force Home
Page:
http://www.w3.org/WAI/IndieUI/IUITF

The WAI Independent User Interface (IndieUI) Working Group Home Page is at:
http://www.w3.org/WAI/IndieUI/

The Web Events Working Group Home Page is at:
http://www.w3.org/2010/webevents/


--

Janina Sajka,   Phone:  +1.443.300.2200
sip:jan...@asterisk.rednote.net
Email:  jan...@rednote.net

The Linux Foundation
Chair, Open Accessibility:  http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,  Protocols&  Formats http://www.w3.org/wai/pf
Indie UIhttp://www.w3.org/WAI/IndieUI/

CfC: publish a LCWD of Selectors API Level 1; deadline June 25

[Arthur Barstow]

Lachlan has made some changes to the Selectors API Level 1 spec (last 
published as a CR) and we consider the changes sufficient to require the 
spec be published as a Working Draft (see the [1] thread). As such, this 
is a Call for Consensus to publish a new LCWD of this spec using the 
following document as the basis 
.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by June 25 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


The proposed LC review period is 3 weeks.

-Thanks, AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1189.html

CfC: publish WD of Selectors API Level 2; deadline June 25

[Arthur Barstow]

Lachlan would like to publish a new Working Draft of the Selectors API 
Level 2 spec and this is a Call for Consensus to do so using the 
following Editor's Draft as the basis 
.


Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by June 25 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean  agreement with the proposal.


-Thanks, AB

Re: Updates to Selectors API

[Arthur Barstow]

On 6/18/12 8:34 AM, ext Lachlan Hunt wrote:

On 2012-06-18 13:57, Arthur Barstow wrote:

In the process, I also made a few minor editorial changes to v2 just
to tidy it up.

At this stage, we should be able to publish v1 as a revised CR, or
possibly move it up to PR.


I like the changes Lachlan, especially the new section 6.4.

Although I have argued to the Advisory Committee and Advisory Board the
process should (under certain circumstances) permit a CR to be directly
re-published as a CR, that currently is not possible. Nevertheless, I
think it could be a bit tricky to argue to the Director in this case
that there were no substantive changes (e.g. the new 6.4) so my
recommendation is that we publish a new LCWD with the minimum 3-week
review period (and make sure all of the changes can be reviewed).


OK. Let's get started on that process.


OK, I'll start the CfC for LC today.



Do you or Chaals have the interop data now (and if so, where is it)?
What do you think about going the LC->PR route?


Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline 
(HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests.


Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 
tests. Opera only passes 99.2% of these and IE only passes 67.7% of 
these. However, these are additional tests that are not required to 
declare interoperability of the API, as the failures relate more to 
XHTML and Selectors support, rather than any particular bug with the API.


http://dev.w3.org/2006/webapi/selectors-api-testsuite/

Do I need to prepare some kind of formal testsuite report with the 
results for each test?


Yes, we do need to document the spec has interoperable implementations 
(and that is typically called the "interop report"). I think we have 
considerable flexibility on the format of the data. Here are a couple of 
examples:


* Cam's Element Traversal
<http://www.w3.org/2008/webapps/ElementTraversal/index.html>

* Marcos' widget spec
<http://dev.w3.org/2006/waf/widgets/imp-report/>

However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this 
test suite will need to be updated with new tests, so this will likely 
delay PR for a little bit longer.


OK, that's good to know. The LC's status section should include the URI 
of the interop report although that document can be empty when the LC is 
published. (I think the status section should also mention the group 
expects to skip CR and go directly to PR.)




We can also publish v2. as a new WD.


If you want me to start a CfC to publish a new WD of v2, just let me 
know.


Yes please.


Will do.

-Thanks, Art

Re: Updates to Selectors API

[Arthur Barstow]

On 6/14/12 10:11 AM, ext Lachlan Hunt wrote:

Hi,
I have updated the specification for Selectors API Level 1, which is 
currently in CR.


Most of it was editorial in nature, to bring it in line with Selectors 
API Level 2, except without adding any of the new features like 
findAll() or or matches().


Importantly, the IDL has now been updated to comply with the most 
recent WebIDL specificiation.  This was basically to split it up into 
3 partial interfaces, just like what was previously done in v2.


Some of the prose was rewritten, but none of the changes should 
adversely affect implementation requirements. This was mostly done by 
back porting the content from v2, but while ensuring that all the 
normative references still refer to the older, stable specs. (e.g. 
DOM3Core instead of using DOM4, as is used in the v2 draft.)  This now 
makes v1 a proper subset of v2.


In the process, I also made a few minor editorial changes to v2 just 
to tidy it up.


At this stage, we should be able to publish v1 as a revised CR, or 
possibly move it up to PR. 


I like the changes Lachlan, especially the new section 6.4.

Although I have argued to the Advisory Committee and Advisory Board the 
process should (under certain circumstances) permit a CR to be directly 
re-published as a CR, that currently is not possible. Nevertheless, I 
think it could be a bit tricky to argue to the Director in this case 
that there were no substantive changes (e.g. the new 6.4) so my 
recommendation is that we publish a new LCWD with the minimum 3-week 
review period (and make sure all of the changes can be reviewed).


At the end of the LC review period, if no substantive changes are 
needed, and we already have sufficient interop data (i.e. the 2009 CR 
exit criteria is already met), we could skip a new CR and directly 
publish a PR.


Do you or Chaals have the interop data now (and if so, where is it)? 
What do you think about going the LC->PR route?



We can also publish v2. as a new WD.


If you want me to start a CfC to publish a new WD of v2, just let me know.

-Thanks, Art

Alternatively, we could forgo any further progress with v1 and let v2 
supersede it entirely, at which point I could simply rename it back to 
"Selectors API" without a version number and move on.  (This is my 
preferred approach).


http://dev.w3.org/2006/webapi/selectors-api/
http://dev.w3.org/2006/webapi/selectors-api2/

Re: CfC: publish FPWD of Fullscreen spec; deadline May 24

[Arthur Barstow]

On 5/30/12 10:38 AM, ext Daniel Glazman wrote:

Le 30/05/12 14:43, Arthur Barstow a écrit :


Chris, Daniel, Peter - when will the CSS WG make a decision on the FPWD?


We'll try to make one today during our weekly conf-call. Please note
that we're going to review the bits of this document falling under CSS
WG's wings. In particular section 6. Peter and I already have discovered
a few things :

1. "position: center" in section 6.1 refers to an Editor's Draft that is
   not actively discussed at this time. Only normative references
   should be made to CSS specs or the Fullscreen draft will have to wait
   until that ED becomes a REC to itself become a REC.

2. the ::backdrop pseudo-element is not explained in the document
   outside of section 6.2. It's unclear to me why it is needed, what
   it represents, etc.

3. the parenthesis in section 6.2 seems to me to contain a copy/paste
   error "above the element below the element"

4. "layer" and "layer 10" in section 6.1 are unclear. "Layer" is used
   nowhere in CSS references used in this spec. This must be clarified.


Does the latest ED 
<http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html> address 
the above concerns?


-Thanks, AB


I note that these 4 points should have been resolved long ago but nobody
ever pinged the CSS WG about this document between beginning of february
and now. I request that "joint efforts" become really joint efforts,
thanks.

Outside of the direct scope of the CSS WG, I would personnally add:

1. the definition of requestFullScreen() says what are the steps it
   should run but it does not even say what feature it provides. I think
   a sentence saying "The requestFullScreen() method sends a request for
   the Element to go fullscreen. Please see section 7 for the Security
   Considerations attached to this method." is needed.

2. allowfullscreen and iframe in section 7 should be hyperlinks. I note
   the reference is at WHATWG while it should be at W3C.

Re: Browser Payments API proposal

[Arthur Barstow]

On 6/16/12 8:16 PM, ext Alex MacCaw wrote:
The blog article link has changed to: 
http://blog.alexmaccaw.com/preview/Pc1LYBw4xDT95OPWZGihod7z8WhrnfAdXMjQxMDg3MTc5NDIaXNjA1p


Alex - perhaps this API will be of interest to the Web Payments 
Community Group . -AB

Reminder: RfC: LCWD of Indexed Database; deadline June 21

[Arthur Barstow]

 Original Message 
Subject:RfC: LCWD of Indexed Database; deadline June 21
Resent-Date:Thu, 24 May 2012 17:21:06 +
Resent-From:
Date:   Thu, 24 May 2012 13:20:20 -0400
From:   ext Arthur Barstow 
To: public-webapps 



This is a Request for Comments re the 24-May-2012 LCWD version of
Indexed Database:

http://www.w3.org/TR/2012/WD-IndexedDB-20120524/

The comment deadline is June 21 and all comments should be sent to the
public-webapps@w3.org list.

-Thanks, AB

[DOM4] Mutation algorithm imposed order on document children

[Arthur Barstow]

Elliott, All - please use the www-...@w3.org list for DOM4 discussions 
.


(Elliott, since that spec is still in the draft phase, you should 
probably use the latest Editor's Draft 
 instead of 
the version in w3.org/TR/)


-Thanks, AB

 Original Message 
Subject:[DOM4] Mutation algorithm imposed order on document children
Resent-Date:Tue, 12 Jun 2012 01:01:51 +
Resent-From:
Date:   Mon, 11 Jun 2012 16:39:36 -0700
From:   ext Elliott Sprehn 
To: 



I'm working on places where Webkit doesn't follow the DOM4 mutation 
algorithm and one of the bugs is not throwing an exception when a 
doctype node is inserted after an element in a document (or other 
permutations of the same situation).


https://bugs.webkit.org/show_bug.cgi?id=88682
http://www.w3.org/TR/domcore/#mutation-algorithms

After discussing this with some other contributors there were questions 
on why we're enforcing the order of the document child nodes. 
Specifically since inserting a doctype node doesn't actually change the 
doctype so this situation is very unlikely (possibly never happens) in 
the wild. Not implementing this keeps the code simpler for a case that 
developers likely never see.


Can we leave the behavior when your document is out of order unspecified?

- Elliott

Reminder: RfC: LCWD of WebSocket API; deadline June 14

[Arthur Barstow]

 Original Message 
Subject:RfC: LCWD of WebSocket API; deadline June 14
Resent-Date:Thu, 24 May 2012 17:21:24 +
Resent-From:
Date:   Thu, 24 May 2012 13:20:50 -0400
From:   ext Arthur Barstow 
To: public-webapps 
CC: h...@ietf.org 



This is a Request for Comments re the 24-May-2012 LCWD version of the
WebSocket API:

http://www.w3.org/TR/2012/WD-websockets-20120524/

The comment deadline is June 14 and all comments should be sent to the
public-webapps@w3.org list. The Bugzilla component for the API is [Bugz].

I Cc'ed the hybi list as an FYI and comments from that list's
subscribers are of course welcome. The Bugzilla component for the API is
[Bugz].

-Thanks, AB

[Bugz]
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=WebSocket%20API%20%28editor%3A%20Ian%20Hickson%29&resolution=---

Re: [Process] Publishing use cases and requirements as official docs

[Arthur Barstow]

On 6/6/12 1:55 PM, ext Tobie Langel wrote:

Hi,

I recently stumbled upon a number of use case and requirements docs (such
as MediaStream Capture Scenarios[1] or HTML Speech XG[2]) that were
published as officially looking W3C documents (for whatever that means, at
least, it's not a page on a Wiki).

I think that's tremendously useful, especially for authors who can have a
much better understanding of the purpose of a specification that way (and
therefore use it the right way and for the right purpose).

It's also a smart way to get authors involved without corrupting them into
thinking like spec writers or implementors.

What are the WebApps WG's plans with regards to that (if any)?


I think our [Charter] sets a clear expectation that our new specs will 
have some type of requirements and use cases and as a spec transitions 
to Last Call, the group should identify the requirements the spec addresses.


There a number of ways to document the UCs and reqs. For example, Bryan 
is using a wiki for the Push API. Anne included requirements and use 
cases directly in the CORS spec (although I think they were moved out 
before CR). Marcos took the higher overhead route of publishing widget 
requirements as a TR. I don't think anyone has done so but a text file 
in Hg could also be sufficient as would be an email (thread).


Which mechanism is used largely depends on how much time the 
protagonists are willing to spend. If anyone wants to go the TR route, 
we can certainly do that and we'd use the normal CfC process to gauge 
consensus.


-Thanks, AB

[Charter] http://www.w3.org/2012/webapps/charter/#others

CfC: publish FPWD of Quota Management API; deadline June 13

[Arthur Barstow]

Having seen no negative responses to the "Is the Quota Management API 
spec ready for FPWD?" thread [1], this is a Call for Consensus (CfC) to 
publish a First Public Working Draft (FPWD) of the Quota Management API 
using the following ED as the basis of the FPWD:




This CfC satisfies the group's requirement to "record the group's  
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to 
begin reviewing the document. The FPWD reflects where the group is on 
this specification at the time of publication; it does not necessarily 
mean there is consensus on the specification's contents.


Please send all comments regarding this CfC to the public-webapps@w3.org 
mail list by June 13. Please note silence will be considered as 
agreement with the proposal. If you support this CfC, a positive 
response is preferred and encouraged.


-Thanks, AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0940.html

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Arthur Barstow]

On 5/30/12 2:36 PM, ext Arthur Barstow wrote:
What are people's thoughts on whether or not the Quota Management API 
spec is ready for First Public Working Draft (FPWD)?


(Ooops, c&p error above: s/Quota Management/Webapp Manifest/)

A "rule of thumb" for FPWD is that the ED's scope should cover most of 
the expected functionality although the depth of some functionality 
may be very shallow, and it is OK if the ED has some open bugs/issues.


In addition to the above, one of the side effects of the publication of 
a FPWD is that it starts the spec's first Call for (patent) Exclusions 
(see [CfE] for details). Consequently, the FPWD should contain enough 
information regarding its scope to facilitate a patent search.


I mention this because Adam (and others) raised concerns the ED "makes 
some implicit assumptions about the security model". I don't think that 
concern is necessarily a showstopper for the FPWD. However, such 
comments indicate to me the spec's scope isn't quite fleshed out yet, at 
least regarding security considerations. It would be useful for the ED 
to be more explicit about the concerns that have raised. For example, 
the ED could contain some type of Issue block and point to this thread.


I don't recall the group discussing the UCs and requirements the spec 
addresses. Perhaps it would also be useful to step back a bit and try to 
get agreement on some high level requirements before proceeding. 
(Marcos' requirements document for widgets could provide some useful 
info [Widget-Reqs].)


WDYT?

-AB

[CfE] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
[Widget-Reqs] http://www.w3.org/TR/widgets-reqs/

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Arthur Barstow]

On 5/31/12 5:23 PM, ext Adam Barth wrote:

Is anyone besides Mozilla interested in implementing this specification?


I don't recall anyone else committing to an implementation (although it 
could be a bit early).


All - please speak up both on a) Adam's question; and b) the question in 
the Subject: header.


-Thanks, AB

[manifest] Is the Webapp Manifest spec ready for FPWD?

[Arthur Barstow]

Hi All,

Besides the thread below that Anant started a few weeks re the Webapp 
Manifest spec, Marcos also started a few threads on this spec ...


What are people's thoughts on whether or not the Quota Management API 
spec is ready for First Public Working Draft (FPWD)?


A "rule of thumb" for FPWD is that the ED's scope should cover most of 
the expected functionality although the depth of some functionality may 
be very shallow, and it is OK if the ED has some open bugs/issues.


-Thanks, AB

On 5/12/12 2:02 PM, ext Anant Narayanan wrote:

Hi everyone,

I recently joined the webapps working group and I'd like to introduce 
myself! I work at Mozilla and for the past year or so have been 
working on our Apps initiative [1]. Our goal has been to make it very 
easy for developers to build apps using web technologies that can go 
above and beyond what one might achieve using "native" SDKs on 
platforms like iOS and Android. We're also trying to make it really 
easy for users to find and acquire these apps, and use them on any 
device they happen to own regardless of platform.


As part of this work we have devised a simple JSON based manifest 
format to describe an installable web app, in addition to a few DOM 
APIs to install and manage these apps. We have a working 
implementation of the entire system in our latest Nightly builds.


The manifest and corresponding APIs are described in an early draft at:
http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html

We'd like to propose using that draft as the basis for a FPWD on this 
topic. I look forward to your feedback!



FAQs
--
There are a few questions I anticipate in advance, which I will try to 
answer here, but we can definitely go in more depth as necessary on 
the list:


Q. Why not simply reuse the widgets spec [2]?

A. Aside from naming (we're talking about apps, the word "widget" 
seems to imply an artificial limitation), and replacing XML with JSON; 
the other fundamental difference is that the widget spec describes 
packaged apps, whereas our manifest describes hosted apps.


We think hosted apps have several interesting and unique web-like 
properties that are worth retaining. Hosted apps can be made to work 
offline just as well as packaged apps with AppCache (which is in need 
of some improvement, but can be made to work!). Packaged apps do have 
their own advantages though, which we acknowledge, and are open to 
extending the spec to support both types of apps.



Q. Why is the DOM API in the same spec as the manifest?

A. One success condition for us would be standardize the DOM APIs so 
that users will be able to visit any app marketplace that publishes 
web apps conforming to the manifest spec in any browser and be able to 
install and use them.


We understand there might be other platforms on which a JS API may not 
be feasible (for eg: A Java API to install and manage these apps is 
equally important), but that shouldn't preclude us from standardizing 
the DOM API in browsers. The manifest and the API go hand-in-hand, as 
we think each of them is dramatically less useful without the other.



Q. Why only one app per origin?

A. We originally placed this restriction for security reasons. In 
Firefox (and most other browsers), the domain name is the primary 
security boundary - cookie jars, localStorage, XHRs are all bound to 
the domain. For supporting multiple apps per domain we would have to 
do some extra work to ensure that (potentially sensitive) permissions 
granted to one app do not leak into another app from the same domain. 
Additionally, this lets us use the origin of the domain as a globally 
unique identifier. Note that app1.example.org and app2.example.org are 
two different origins under this scheme.


That said, we've received a lot of developer feedback about the 
inconvenience of this restriction, and we are actively looking to lift 
it [3]. We cannot do this without a few other changes around 
permissions and enforcing specific UA behavior in "app mode" (as 
opposed to "browser mode"), but is something we can work towards.



Q. Apps are just web pages, why bother "installing" them?

A. This has been previously discussed on the list [4]. There are clear 
differences in perception between an app and a website for most users. 
Most web content is expected to be free, but the same content wrapped 
in an app is something people seem to be willing to pay for. 
Monetization is important to encourage a thriving web developer 
community.


Additionally, treating certain "installed" websites as apps gives us a 
context separate from loading pages in a browser, which allows us to 
provide privileged APIs to such trusted apps, APIs we would normally 
not give to untrusted web content.



Thanks for reading!

Regards,
-Anant

[1] https://mozilla.org/apps/
[2] https://www.w3.org/TR/widgets/
[3] 
https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9482dcd34fa8c1a4
[4] 
http://lists.w3.org/Archives/Public/pu