date:20110920

Hi all,

there have been two primary proposals for a Discovery API that would enable web 
pages to (shockingly enough) discover services (on the device, the local 
network, or possibly remote) through common mechanisms such as DNS-SD or UPnP.

One of them comes from Opera:

http://people.opera.com/richt/release/specs/discovery/Overview.html

And the other comes from Webinos:


http://dev.webinos.org/deliverables/wp3/Deliverable32/static$42d2e5ab28271945244cdeb7579c65fd.html

Ideally, we'd like to start with either of those and, if sensible, make sure it 
supports the use cases of the other. We're therefore calling for feedback from 
anyone interested in this topic.

Please direct replies towards public-device-a...@w3.org where the work is 
taking place. Thanks!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23

On Tuesday, September 20, 2011 at 12:07 AM, Arthur Barstow wrote:
 PLH says that ideally every spec ends as a WG Note or a Recommendation 
 but in practice groups need to consider other factors. In the case of 
 the Landscape doc, which was by definition (or at least by title) 
 transient, so let's just drop it (and not publish it as a WG Note).
Agreed. 
 So, the proposal for the Landscape doc is amended: the proposal is to 
 formally stop working on the Landscape document and to move it to 
 PubStatus' Specs NO Longer Active table:
 
 http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active
 
 If anyone objects to that, please reply by September 23 and understand 
 that it would mean that you must do the editing work to produce a WG Note.
Will prepare it from publication.

[Bug 14220] In reply to comment #0) Every browser that I know of can have two web pages open at once. Those 2 web pages both have a DOM, they don't share a DOM. Some browsers implement this

2011-09-20 Thread bugzilla

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14220

Simon Pieters sim...@opera.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #1 from Simon Pieters sim...@opera.com 2011-09-20 08:33:57 UTC ---
Please get a bugzilla account and use bugzilla correctly.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Adding Web Intents to the Webapps WG deliverables

2011-09-20 Thread Rich Tibbett


Ian Hickson wrote:

Why not just improve both navigator.registerContentHandler and
navigator.registerProtocolHandler?


http://groups.google.com/group/web-intents/browse_thread/thread/3dff7c2cdf5815b8

I tend to agree with rolling this in to RCH and RPH and seeing if we 
could refine the processing algorithms therein to satisfy the security 
issues highlighted in that thread (i.e. ensuring the cross document 
messaging channel setup from a window.open with a registered protocol 
handler is origin bound).

Re: RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]

2011-09-20 Thread Arthur Barstow


Yesterday, Hixie checked in a fix for 13777.

Bug 13104 (Enable keepalive on WebSocket API) was closed (WontFix) but 
reopened on September 18. Since various group members agree with not 
addressing this bug for v1, I will proceed with a CfC to publish a LC of 
the Web Socket API. (Perhaps this bug could be moved to the PostPoned 
state and (re-)considered for v2?).


Editorial bugs 12510 and 13700 will not block the LC (although it would 
be great if they were fixed ;-)).


If any new bugs are submitted after the RfC begins, we will consider 
those bugs as LC comments.


-AB

On 9/15/11 9:07 AM, Arthur Barstow wrote:
As an update on this RfC, note that ATM, 13777 is the only 
non-editorial bug that remains open:


http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777

I would appreciate it, if people would please provide input on this bug.

-AB


On 9/9/11 6:05 PM, ext Brian Raymor wrote:
  13777 - The WebSocket protocol draft (hybi-10) restricts the value 
of subprotocols as follows: The elements that comprise this value 
MUST be non- empty strings with characters in the range U+0021 to 
U+007E not including separator characters as defined

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in 
this bug.

Reminder: RfC: LCWD of Web Storage; deadline September 27

2011-09-20 Thread Arthur Barstow

Reminder: September 27 is the deadline for comments for this LCWD. The 
open bug list is:


http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Web%20Storage%20%28editor%3A%20Ian%20Hickson%29resolution=---

 Original Message 
Subject:RfC: LCWD of Web Storage; deadline September 27
Resent-Date:Tue, 6 Sep 2011 14:19:41 +
Resent-From:public-webapps@w3.org
Date:   Tue, 6 Sep 2011 10:19:03 -0400
From:   ext Arthur Barstow art.bars...@nokia.com
To: public-webapps public-webapps@w3.org



A new LCWD of Web Storage was published:

  http://www.w3.org/TR/2011/WD-webstorage-20110901/

Please send all comments to public-webapps@w3.org by September 27.

Fwd: RfC: LCWD of Web Workers; deadline September 27

2011-09-20 Thread Arthur Barstow

Reminder: September 27 is the deadline for comments for this LCWD. The 
open bug list is:


  
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Web%20Workers%20%28editor%3A%20Ian%20Hickson%29resolution=---


 Original Message 
Subject:RfC: LCWD of Web Workers; deadline September 27
Resent-Date:Tue, 6 Sep 2011 14:21:11 +
Resent-From:public-webapps@w3.org
Date:   Tue, 6 Sep 2011 10:20:49 -0400
From:   ext Arthur Barstow art.bars...@nokia.com
To: public-webapps public-webapps@w3.org



A new LCWD of Web Workers was published:

  http://www.w3.org/TR/2011/WD-workers-20110901/

Please send all comments to public-webapps@w3.org by September 27.

Re: Adding Web Intents to the Webapps WG deliverables

With all due respect, I think that if we have to re-charter or create a new
working group each time a new API comes up we are all doomed. The overhead
of creating and monitoring so many WGs is not appealing to many of us.

On Tue, Sep 20, 2011 at 6:55 AM, Robin Berjon ro...@berjon.com wrote:

 Hi James,

 thanks for bringing this forward, it is indeed a very interesting approach.

 On Sep 19, 2011, at 22:27 , James Hawkins wrote:
  I've read through the Webapps charter, and I believe Web Intents fits the
 goals and scope of the WG.

 It does fit the goal and scope, but then most web client technology does ;)
 Where you may run into issues is that it does not fit in the deliverables
 list. Since that is what members makes their IP commitment on, a new
 deliverable of non-negligible content might require rechartering. Last time
 we did that, it wasn't very pleasant.

 Thankfully, there is already a group that was chartered with Intents (or,
 in the poetic phrasing of charters, with an API that allows web
 applications to register themselves as handlers/providers based on data
 string identifiers and an API that enables other web applications to
 discover these handlers/providers and gain permission to interact with them
 — but Intents is what that means): the Device APIs group,
 http://www.w3.org/2011/07/DeviceAPICharter. It'd save a lot on the
 bureaucracy and allow us all to just go straight to work.

 We'd certainly be happy to accept your draft input. The new DAP is meant to
 be completely flexible in how it is organised. Notably, if you prefer to
 conduct work on this spec without necessarily getting all the email from the
 rest of the group we can setup a dedicated Task Force with its own mailing
 list and chair (if there's a volunteer, otherwise I'll do it). TFs can
 decide whether they want to have telcons or not.

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

Hi Ian,

On Sep 20, 2011, at 16:04 , Ian Fette (イアンフェッティ) wrote:
 With all due respect, I think that if we have to re-charter or create a new 
 working group each time a new API comes up we are all doomed. The overhead of 
 creating and monitoring so many WGs is not appealing to many of us.

That's a recurring theme, with the following constraints:

   • people with IP don't want wildcard groups because the IP risks for them 
are hard to evaluate;
   • people who want to get work done don't want to have to jump through the 
bureaucratic hoops of creating new groups;
   • people who are focused on a single topic complain about monster groups 
that cover too many topics.

So there probably isn't an option that will make everyone happy, though 
improvements are being discussed.

Thankfully those problems don't apply here. There is an existing group so 
there's no need for bureaucratic hoops — those have been handled and everything 
is primed to go. The overhead involved in monitoring it involves clicking the 
form to join it and filtering the related list somewhere convenient — which can 
be the same mailbox as an existing one if there's too much overhead involved in 
reading from two mailboxes.

So can we quit the process discussion and just get to work?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

I don't get it. The overhead of getting all the other browsers to join the
WG you mention is just as high, especially when there's no indication that a
number of browsers intend to join that group. I don't think it's a random
process question, I think it's rather fundamental issue. If we agree that
the right way forward is to create a new WG for each API and we have to get
people to join each WG to get any IP considerations, it would be much more
effective just to do things in WHATWG and mail out a please sign this and
return letter. It would probably get the same number of responses and be a
hell of a lot lower overhead, while effectively offering as much (or rather,
as little) benefit as we get from being forced to start a new group for each
API.

-Ian

On Tue, Sep 20, 2011 at 7:21 AM, Robin Berjon ro...@berjon.com wrote:

 Hi Ian,

 On Sep 20, 2011, at 16:04 , Ian Fette (イアンフェッティ) wrote:
  With all due respect, I think that if we have to re-charter or create a
 new working group each time a new API comes up we are all doomed. The
 overhead of creating and monitoring so many WGs is not appealing to many of
 us.

 That's a recurring theme, with the following constraints:

   • people with IP don't want wildcard groups because the IP risks for
 them are hard to evaluate;
   • people who want to get work done don't want to have to jump through the
 bureaucratic hoops of creating new groups;
   • people who are focused on a single topic complain about monster
 groups that cover too many topics.

 So there probably isn't an option that will make everyone happy, though
 improvements are being discussed.

 Thankfully those problems don't apply here. There is an existing group so
 there's no need for bureaucratic hoops — those have been handled and
 everything is primed to go. The overhead involved in monitoring it involves
 clicking the form to join it and filtering the related list somewhere
 convenient — which can be the same mailbox as an existing one if there's too
 much overhead involved in reading from two mailboxes.

 So can we quit the process discussion and just get to work?

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

Hi Ian!

On Sep 20, 2011, at 16:26 , Ian Fette (イアンフェッティ) wrote:
 I don't get it. The overhead of getting all the other browsers to join the WG 
 you mention is just as high

Can you please detail what overhead that involves? There are only two cases 
here:

• You have IP concerns relevant to Web Intents. In that case you need IP 
portfolio review. That overhead is the same for joining and for rechartering an 
existing group (it's just politically higher in the rechartering case).
• You don't have IP concerns relevant to Web Intents. In that case you just 
join the group — zero overhead.

It's a simple solution that just involves clicking through a form. If you have 
a political mexican standoff of vendors not joining while the others aren't, it 
can hardly be blamed on the process, DAP, WebApps, W3C, or whatever else. I'm 
sure that it can be sorted out, though.

Intents were initially added to DAP's charter in good part because Google asked 
us to. It's a little annoying to be blamed for doing exactly what you were 
asked to do.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

2011-09-20 Thread Charles Pritchard


On 9/20/2011 7:55 AM, Robin Berjon wrote:

Hi Ian!

On Sep 20, 2011, at 16:26 , Ian Fette (イアンフェッティ) wrote:

I don't get it. The overhead of getting all the other browsers to join the WG 
you mention is just as high

Can you please detail what overhead that involves? There are only two cases 
here:

 • You have IP concerns relevant to Web Intents. In that case you need IP 
portfolio review. That overhead is the same for joining and for rechartering an 
existing group (it's just politically higher in the rechartering case).
 • You don't have IP concerns relevant to Web Intents. In that case you 
just join the group — zero overhead.

It's a simple solution that just involves clicking through a form. If you have 
a political mexican standoff of vendors not joining while the others aren't, it 
can hardly be blamed on the process, DAP, WebApps, W3C, or whatever else. I'm 
sure that it can be sorted out, though.

Intents were initially added to DAP's charter in good part because Google asked 
us to. It's a little annoying to be blamed for doing exactly what you were 
asked to do.


There is certainly some overlap between DAP and WebApps. Is that the 
issue here, Robin?


I don't have much of a solution for it: I've been looking at DAP as an 
incubator with a broad

scope and a good history of experimentation.


-Charles

Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23



On Tuesday, September 20, 2011 at 10:25 AM, Marcos Caceres wrote:

 On Tuesday, September 20, 2011 at 12:07 AM, Arthur Barstow wrote:
  PLH says that ideally every spec ends as a WG Note or a Recommendation 
  but in practice groups need to consider other factors. In the case of 
  the Landscape doc, which was by definition (or at least by title) 
  transient, so let's just drop it (and not publish it as a WG Note).
 Agreed. 
  So, the proposal for the Landscape doc is amended: the proposal is to 
  formally stop working on the Landscape document and to move it to 
  PubStatus' Specs NO Longer Active table:
  
  http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active
  
  If anyone objects to that, please reply by September 23 and understand 
  that it would mean that you must do the editing work to produce a WG Note.
 Will prepare it from publication. 
Done (pub rules checked, removed unused references, and fixed broken links). 

http://dev.w3.org/2006/waf/widgets-reqs/pub/

Set the publication date for the 27th. 

Publish away :) 

-- 
Marcos Caceres

Re: Adding Web Intents to the Webapps WG deliverables

Hi Charles,

On Sep 20, 2011, at 17:15 , Charles Pritchard wrote:
 There is certainly some overlap between DAP and WebApps. Is that the issue 
 here, Robin?

If you ask me, there isn't any issue at all :) James suggested that WebApps 
take over Intents. Since it isn't in WebApps's deliverables, this could require 
some process mongering which I think we can all agree is an annoying waste of 
time. As it happens however, DAP already has Intents in its charter, so getting 
to work right now rather than walking the bureaucratic path is a simple matter 
of doing the work there.

I'm advocating a JFDI approach over politicking and bureaucracy. That's all 
there is to it.

Put another way, I too would like there to be just one huge Web APIs group 
that would handle all of WebApps, DAP, Web Events, Geolocation, and a bunch of 
other groups. But we don't have that and there's opposition to the notion. So 
instead of lamenting that issue, let's just use the tools we have that in this 
case happen to be both in place and perfectly serviceable.

 I don't have much of a solution for it: I've been looking at DAP as an 
 incubator with a broad
 scope and a good history of experimentation.

Yeah, DAP has been very fluid in its approaches and is certainly a group in 
which this proposed spec can just hit the ground running. That's why I'm 
offering this solution over jumping through process hoops, which I really don't 
see the entertainment value in.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

2011-09-20 Thread Charles Pritchard


On 9/20/2011 8:57 AM, Robin Berjon wrote:

Hi Charles,

On Sep 20, 2011, at 17:15 , Charles Pritchard wrote:

There is certainly some overlap between DAP and WebApps. Is that the issue 
here, Robin?

If you ask me, there isn't any issue at all :) James suggested that WebApps 
take over Intents. Since it isn't in WebApps's deliverables, this could require 
some process mongering which I think we can all agree is an annoying waste of 
time. As it happens however, DAP already has Intents in its charter, so getting 
to work right now rather than walking the bureaucratic path is a simple matter 
of doing the work there.

I'm advocating a JFDI approach over politicking and bureaucracy. That's all 
there is to it.

Put another way, I too would like there to be just one huge Web APIs group 
that would handle all of WebApps, DAP, Web Events, Geolocation, and a bunch of other 
groups. But we don't have that and there's opposition to the notion. So instead of 
lamenting that issue, let's just use the tools we have that in this case happen to be 
both in place and perfectly serviceable.


I don't have much of a solution for it: I've been looking at DAP as an 
incubator with a broad
scope and a good history of experimentation.

Yeah, DAP has been very fluid in its approaches and is certainly a group in 
which this proposed spec can just hit the ground running. That's why I'm 
offering this solution over jumping through process hoops, which I really don't 
see the entertainment value in.



I've no objection to delivering it in DAP while discussing it on 
public-webapps.


-Charles

Re: Adding Web Intents to the Webapps WG deliverables

On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com wrote:

 Hi Charles,

 On Sep 20, 2011, at 17:15 , Charles Pritchard wrote:
  There is certainly some overlap between DAP and WebApps. Is that the
 issue here, Robin?

 If you ask me, there isn't any issue at all :) James suggested that WebApps
 take over Intents. Since it isn't in WebApps's deliverables, this could
 require some process mongering which I think we can all agree is an annoying
 waste of time. As it happens however, DAP already has Intents in its
 charter, so getting to work right now rather than walking the bureaucratic
 path is a simple matter of doing the work there.


There's process mongering to get relevant parties to join DAP. This is not
free. If you can guarantee me that the other browsers will join DAP then
let's talk (namely MSFT who just announced a similar spec for Metro, and it
would be very important to get their input here.)



 I'm advocating a JFDI approach over politicking and bureaucracy. That's all
 there is to it.

 Put another way, I too would like there to be just one huge Web APIs
 group that would handle all of WebApps, DAP, Web Events, Geolocation, and a
 bunch of other groups. But we don't have that and there's opposition to the
 notion. So instead of lamenting that issue, let's just use the tools we have
 that in this case happen to be both in place and perfectly serviceable.

  I don't have much of a solution for it: I've been looking at DAP as an
 incubator with a broad
  scope and a good history of experimentation.

 Yeah, DAP has been very fluid in its approaches and is certainly a group in
 which this proposed spec can just hit the ground running. That's why I'm
 offering this solution over jumping through process hoops, which I really
 don't see the entertainment value in.

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

On Tuesday, September 20, 2011 at 7:09 PM, Ian Fette (イアンフェッティ) wrote:
 On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com 
 (mailto:ro...@berjon.com) wrote:
   Hi Charles,
   
   On Sep 20, 2011, at 17:15 , Charles Pritchard wrote:
   There is certainly some overlap between DAP and WebApps. Is that the 
   issue here, Robin?
   
  If you ask me, there isn't any issue at all :) James suggested that WebApps 
  take over Intents. Since it isn't in WebApps's deliverables, this could 
  require some process mongering which I think we can all agree is an 
  annoying waste of time. As it happens however, DAP already has Intents in 
  its charter, so getting to work right now rather than walking the 
  bureaucratic path is a simple matter of doing the work there.
  
 There's process mongering to get relevant parties to join DAP. This is not 
 free. If you can guarantee me that the other browsers will join DAP then 
 let's talk (namely MSFT who just announced a similar spec for Metro, and it 
 would be very important to get their input here.)  
That presupposes that Microsoft would have anything to say even in this WG. 
Obviously, I can't speak for Microsoft (and I won't), but just because someone 
is part of the WG doesn't mean that they will say anything … or worst, they 
will just exclude patents willy-nilly like Apple did with Widgets. That's a 
much crappier situation, so careful for what you wish for :)

Re: Adding Web Intents to the Webapps WG deliverables

On Tue, Sep 20, 2011 at 10:15 AM, Marcos Caceres w...@marcosc.com wrote:

 On Tuesday, September 20, 2011 at 7:09 PM, Ian Fette (イアンフェッティ) wrote:
  On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com (mailto:
 ro...@berjon.com) wrote:
Hi Charles,
  
On Sep 20, 2011, at 17:15 , Charles Pritchard wrote:
There is certainly some overlap between DAP and WebApps. Is that the
 issue here, Robin?
  
   If you ask me, there isn't any issue at all :) James suggested that
 WebApps take over Intents. Since it isn't in WebApps's deliverables, this
 could require some process mongering which I think we can all agree is an
 annoying waste of time. As it happens however, DAP already has Intents in
 its charter, so getting to work right now rather than walking the
 bureaucratic path is a simple matter of doing the work there.
 
  There's process mongering to get relevant parties to join DAP. This is
 not free. If you can guarantee me that the other browsers will join DAP then
 let's talk (namely MSFT who just announced a similar spec for Metro, and it
 would be very important to get their input here.)
 That presupposes that Microsoft would have anything to say even in this WG.
 Obviously, I can't speak for Microsoft (and I won't), but just because
 someone is part of the WG doesn't mean that they will say anything … or
 worst, they will just exclude patents willy-nilly like Apple did with
 Widgets. That's a much crappier situation, so careful for what you wish for
 :)


While issuing a ton of patent exclusions for something like this would be
rather poor, I would frankly rather have that then a spec that doesn't get
any attention from a party that's clearly relevant only to have patents come
up /after/ the spec is published and implemented.

Re: Adding Web Intents to the Webapps WG deliverables

On Tuesday, September 20, 2011 at 7:17 PM, Ian Fette (イアンフェッティ) wrote:
 While issuing a ton of patent exclusions for something like this would be 
 rather poor, I would frankly rather have that then a spec that doesn't get 
 any attention from a party that's clearly relevant only to have patents come 
 up /after/ the spec is published and implemented.  
 Agreed, but for that we need to go through rechartering this group to include 
the new deliverable (i.e., to give everyone a fair chance to say if they are 
willing to give up their IPR around this). I think your concerns are fair.

Re: Adding Web Intents to the Webapps WG deliverables

On Tue, Sep 20, 2011 at 10:27 AM, Marcos Caceres w...@marcosc.com wrote:

 On Tuesday, September 20, 2011 at 7:17 PM, Ian Fette (イアンフェッティ) wrote:
  While issuing a ton of patent exclusions for something like this would be
 rather poor, I would frankly rather have that then a spec that doesn't get
 any attention from a party that's clearly relevant only to have patents come
 up /after/ the spec is published and implemented.
  Agreed, but for that we need to go through rechartering this group to
 include the new deliverable (i.e., to give everyone a fair chance to say if
 they are willing to give up their IPR around this). I think your concerns
 are fair.

 Why do we need to recharter? I don't get the point of having a WG that has
to recharter every single time that we develop a new API. Maybe we should
just stop developing new APIs? The W3C patent policy lets people exclude
things if they so wish, and I don't deny anyone that right. But if we go to
a world where we say Let's create a new WG for each API then we get no
benefit out of the W3C whatsoever. We aren't guaranteed wide review of the
APIs, most WGs probably won't have all the relevant people participating,
and so then we will still have all the worries about relevant patents not
being disclosed or licensed, and frankly at that point W3C offers nothing
that WHATWG does not except for a ton of process overhead. If we have to
create a new WG for each new API, I propose we just do it all in WHATWG.

RE: New tests submitted by Microsoft for WebApps specs

2011-09-20 Thread Travis Leithead

Thanks! We'll see about getting these updated...

From: David Levin [mailto:le...@google.com]
Sent: Monday, September 19, 2011 6:33 PM
To: Adrian Bateman
Cc: Web Applications Working Group WG (public-webapps@w3.org); Israel Hilerio; 
Travis Leithead; Brian Raymor; Kris Krueger
Subject: Re: New tests submitted by Microsoft for WebApps specs

On Tue, Sep 13, 2011 at 6:26 PM, Adrian Bateman 
adria...@microsoft.commailto:adria...@microsoft.com wrote:
WebWorkers (51 tests/assertions)
 Changeset: http://dvcs.w3.org/hg/webapps/rev/7b0ba70f69b6
 Tests: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/

* We believe the tests are all accurate but look forward to wider review from
 the group. IE10 PP3 does not pass all the tests and we are working to fix
 the bugs that cause failures.
Web Worker test issues:

issue 1:
WorkerGlobalScope_ErrorEvent_*.htm uses the onerror function and expected to 
get an error event but instead it should get 3 arguments.

See

http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html#runtime-script-errors-0
and

http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#report-the-error

issue 2:

postMessage_clone_port_error.htm expects to get INVALID_STATE_ERR but should 
expect to get DATA_CLONE_ERR.

http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages

Re: Adding Web Intents to the Webapps WG deliverables

2011-09-20 Thread Paul Kinlan

Hi Ian,

Here are some answers, I have worked closely with the team on getting this
ready so if I miss anything out they will be able to fill in the blanks.

Q: Why are the verbs URLs?

Verbs don't have to be URL's but a URL will allow us a point of reference to
documentation, versioning and namespacing allowing verbs with similar names
but by a different provider to not conflict with each other (thus allowing
developers to come up with their own schemes and APIs outside of
standardisation).

Q: Why are some verbs hard-coded into the API?

Convenience and ensuring there is a consistent use of the first set of
intents that cover the most common initial use cases.

Q: How are types matched?

I don't know the best phrase, mime-typedness.  A direct
string comparison unless there is a * after the / (image/*) which then means
every image.

Q: Why not just improve both navigator.registerContentHandler and
navigator.registerProtocolHandler?

WI encompasses aspects of both of these API's - but more importantly there
are some paradigms we wish to bring that will not fit in to either directly.
 We want one consistent way of delivering data to applications, we want it
to be a client-side delivery mechanism, and we want applications to be able
to tell the action it supports and the data types it can handle.

For instance WI can have application success and failure semantics that are
proxied via the UA so it can respond.  It has a much more succinct syntax
for processing data and establishing channels of communication.  Launching
an app via RPH whilst in its simplest form can be embedded in an anchor has
many complexities for setting up and managing communication across windows.

WI's data delivery is entirely driven on the client, registering a protocol
handler requires a URL substitution which forces the developer to either
require a server to process the response (via querystring) or to have a
complex postMessage dance to deliver data, or to manage data with the hash
parameter; the latter is troublesome because of limits in URL sizes as well
as the extra burden to the developer if they are already extensively using
hash and onhashchange; the former is troublesome because it will not work
offline; and the 2nd point, we strongly believe that client and service in
all but the simplest scenarios should not have to tell each other they are
ready before they deliver each other the data - the current situation for
web developers is that the receiving app needs to tell the calling app that
it is ready for data which leads to trying to come up with a standard
message processing code that all apps agree on.  We want to get to a
scenario that allows developers not to have to think of the three different
ways they may need send data to any one particular app.

Q: How does an already-open page get to handle an action? e.g. say GMail
wants to handle the share intent, and the user already has GMail open,
and the user clicks a share button on Flickr. How does the existing
GMail instance get the notification?

If it was a share, we would envisage the UI to open the compose email
function rather than the full interface.  The context in this case wouldn't
make sense to open the full app up.  However it is entirely up to the app
what it does and in the case of it opening the full UI, it would open a new
instance because we only deliver the data once and it is placed on the
intent object.

Q: In particular, why are intents registered via a new HTML element rather
than an API? How do you unregister? How do you determine if the intent was
registered or not? How do you conditionally register (e.g. once the user
has paid for the service)?

External discoverability, indexing and scraping is a very important part of
the intent tag, understanding the API points of an application is very
powerful to external systems - via an API we lose this ability, or at least
make it fiendishly hard to discover. Flexibility for the UA; the UA gets a
much richer understanding of the capabilities of an application, allowing it
to have more control of how it presents and manages the intents and
registration to the user.  If it is available as a tag it
allows screen-readers or other accessibility tools to be able to indicate
that A) and intent might need to be installed, or that B) the application is
a handler for something at load time rather than at some point in the
applications lifecycle.

Developer experience is another important reason for the tag: We didn't want
the developers to have to think too hard about enabling their apps
to receive data; questions developers ask often of an API is when should I
call the code, should it be in onload, before, after?  Given our experience
working with developers, the more steps or potential questions that are
raised in a developers head about implementing functionality, the more
likely they are to de-prioritise the work in favor of other work.  We
considered the cases of the Notifications API, where there is a

Re: Adding Web Intents to the Webapps WG deliverables

2011-09-20 Thread James Hawkins

Hi Robin,

On Tue, Sep 20, 2011 at 7:55 AM, Robin Berjon ro...@berjon.com wrote:

 Hi Ian!

 On Sep 20, 2011, at 16:26 , Ian Fette (イアンフェッティ) wrote:
  I don't get it. The overhead of getting all the other browsers to join
 the WG you mention is just as high

 Can you please detail what overhead that involves? There are only two cases
 here:

* You have IP concerns relevant to Web Intents. In that case you need IP
 portfolio review. That overhead is the same for joining and for rechartering
 an existing group (it's just politically higher in the rechartering case).
* You don't have IP concerns relevant to Web Intents. In that case you
 just join the group ― zero overhead.

 It's a simple solution that just involves clicking through a form. If you
 have a political mexican standoff of vendors not joining while the others
 aren't, it can hardly be blamed on the process, DAP, WebApps, W3C, or
 whatever else. I'm sure that it can be sorted out, though.

 Intents were initially added to DAP's charter in good part because Google
 asked us to. It's a little annoying to be blamed for doing exactly what you
 were asked to do.


I'm the TL of the Intents team at Google, but this is a large company and
I've only been involved with the larger Open Web Platform team for ~6
months.  I'm not familiar with the details surrounding Google asking DAP to
add Intents to the charter.  Can you fill me in on the details?

To clarify on my end, the current draft of the Web Intents API is entering a
cluttered namespace; there are several proposals with similar names/ideas
that are not directly tied to this API:
* Web Introducer/Web-send (Tyler Close, published early 2010)
* Web Intents (Paul Kinlan, published in Nov 2010)

If my hunch is right, you're referring to Tyler's Introducer proposal; note
that while Tyler does work at Google, his work on Introducer was not tied to
the Chrome team.  The Web Intents proposal of this thread has the backing of
the Chrome team which has agreed that Intents is the way to move forward in
this problem space.

Thanks,
James

RE: publish a LCWD of Web Socket API; deadline September 27

2011-09-20 Thread Adrian Bateman

Microsoft supports this call.

On Tuesday, September 20, 2011 4:05 AM, Arthur Barstow wrote:
 This is a Call for Consensus to publish a Last Call Working Draft of the
 Web Socket API using the following document as the basis:
 
http://dev.w3.org/html5/websockets/
 
 As noted in [1], this spec has two editorial bugs and one bug that some
 group members do not want to address for this version of the spec.
 
 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.
 ]]
 
 Positive response to this CfC is preferred and encouraged and silence
 will be assumed to mean agreement with the proposal. The deadline for
 comments is September 27. Please send all comments to:
 public-webapps@w3.org.
 
 If any new bugs are submitted before this CfC completes and the LC is
 published, those bugs will be will be considered as LC comments.
 
 -Art Barstow
 
 [1] http://lists.w3.org/Archives/Public/public-
 webapps/2011JulSep/1484.html

Re: Adding Web Intents to the Webapps WG deliverables

HI Ian,

On Sep 20, 2011, at 19:38 , Ian Fette (イアンフェッティ) wrote:
Why do we need to recharter? I don't get the point of having a WG that has to
recharter every single time that we develop a new API.

I can't begin to tell you how sympathetic I am to this feeling, and the
frustration that goes with. As a freelance web hacker I have no IP to care for,
and I very much wish that all companies with IP portfolios had the same
attitude that you have. But that's hardly under my control and I'm merely
pointing out that pushing this through WebApps risks bureaucratic overhead
whereas there is an option that involves no bureaucracy.

Note that if your primary concern is Microsoft providing feedback, if they so
wish they always can. They've provided extensive feedback to DAP in the past,
e.g.
http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#capture_api_extensions

But if we go to a world where we say Let's create a new WG for each API
then we get no benefit out of the W3C whatsoever.

Hear, hear. Thankfully in this case it's a WG that's already created, and has
~15 deliverables. Still smaller than WebApps, but better than 15 WGs!

Note that a complicating factor is that the feedback we got from others (e.g.
Mozilla) was the opposite: they'd rather have seen DAP be several smaller WGs.
It's hard to please everyone, which is precisely why I'm so keen to avoid
pushing this into process-space, getting to work where it's process-easiest,
and ensuring reviews in every way we know. If people want to review they will
no matter which group it's in; if they don't it won't happen even if they are
in the group.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

2011-09-20 Thread Bjoern Hoehrmann

* Ian Fette wrote:
I don't get it. The overhead of getting all the other browsers to join the
WG you mention is just as high, especially when there's no indication that a
number of browsers intend to join that group. I don't think it's a random
process question, I think it's rather fundamental issue. If we agree that
the right way forward is to create a new WG for each API [...]

The idea is to record in charters what working groups are expected to
deliver to allow proper review, planning, allocation of resources, and
so on. A coarse characterization will make those things difficult, and
a very narrow characterization will make taking up new work difficult.
Surprising new requirements come with more overhead than things that
have been anticipated well in advance; but that's not one WG per API.

I note that these processes are not designed to minimize hurdles for a
handful of browser vendors, but for broad consensus and high quality
deliverables that arrive reasonably predictably. That requires parties
to synchronize. Removing synchronization pressure leads to what we have
with the Web Applications Working Group, which after six years has a
XMLHttpRequest test suite consisting of nothing but There is a good
chance a test suite for XMLHttpRequest will be placed around here and
no XMLHttpRequest specification to show.

There are drafts and submissions, but it would seem people regard this
state of affairs as good enough and so there is little pressure to pull
things together and push out a proper release. And I note the same goes
for earlier stages aswell, the process being largely unpredictable as
it is driven by when one or more of a handful people feel like it, it
becomes very difficult for out-of-the-loop parties to meaningfully en-
gage in the process. If you mostly want to sanity-check reasonably com-
plete documents, which should you review? The first Last Call? Second?
Third? Fourth? Fith Last Call? Third Candidate Recommendation? When can
we expect a reasonable test suite to verify everything is interoperable
enough to remove vendor prefixes? Seven years? Oh there is a couple of
Webkit specific tests somewhere in the source tree, we think this is
good enough so we just throw it out there with no proper test suite?

It's not a matter of this has more overhead than that, but a matter
of what we, all of us, want to get out of the standards process, and
what of that can reasonably be achieved within constraints we have. It
may be for instance that we are moving too fast, and should not work
at this point on Web Intents and instead use what limited resources
there are to finish some of the pending work first. It may also be we
don't care about this silly business with Recommendations and Tests so
this can easily be added. Or we might find that we need to invest more
resources so we can do more things in parallel. Or something else. But
without an understanding what the process should produce and support,
which we quite clearly lack, at least collectively, there is no point
in arguing that process A is better than process B.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
 On 5/23/11 6:14 PM, Arun Ranganathan wrote:

 On 5/23/11 1:20 PM, Kyle Huey wrote:

 To close the loop a bit here, Firefox 6 will make the change to
 FileReader.abort()'s throwing behavior agreed upon here.
 (https://bugzilla.mozilla.org/show_bug.cgi?id=657964)

 We have not changed the timing of the events, which are still dispatched
 synchronously.

 The editor's draft presently does nothing when readyState is EMPTY, but if
 readyState is DONE it is specified to set result to null and fire events
 (but flush any pending tasks that are queued).

 http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort

 Also note that we're NOT firing *both* error and abort; we should only fire
 abort, and *not* error.

 I should change the spec. to throw.  Eric, you might change the spec. (and
 Chrome) to NOT fire error and abort events :)

 Sorry, to be a bit clearer: I'm talking about Eric changing
 http://dev.w3.org/2009/dap/file-system/file-writer.html#widl-FileSaver-abort-void
 to match http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort

 -- A*




Sorry about the long delay here--a big release and a new baby absorbed
a lot of my time.  I'm going through the abort sequence right now, and
it turns out that there are a number of places in various algorithms
in FileWriter that should match FileReader more closely than they do.
However, there a couple of edge cases I'm unsure about.

1) Do you expect there to be an event called progress that indicates a
complete read, before the load event?
user agents MUST return at least one such result while processing
this read method, with the last returned value at completion of the
read -- Does that mean during onprogress, or would during onloadend
be sufficient?  What if the whole blob is read in a single backend
operation--could there be no calls to onprogress at all?

[Side note--the phrasing there is odd.  You say that useragents MUST
return, but the app's not required to call for the value, and it
can't return it if not asked.  Did you want to require the useragent
to make at least one onprogress call?]

2) The load and loadend events are queued When the data from the blob
has been completely read into memory.  If the user agent fires an
onprogress indicating all the data's been loaded, and the app calls
abort in that event handler, should those queued events be fired or
not?  If there are any tasks from the object's FileReader task source
in one of the task queues, then remove those tasks. makes it look
like no, but I wanted to make sure.  If #1 above is no or not
necessarily, then this might not ever come up anyway.

Thanks,

Eric

Re: Adding Web Intents to the Webapps WG deliverables

2011-09-20 Thread Ian Hickson

On Tue, 20 Sep 2011, Rich Tibbett wrote:
 Ian Hickson wrote:
  Why not just improve both navigator.registerContentHandler and
  navigator.registerProtocolHandler?
 
 http://groups.google.com/group/web-intents/browse_thread/thread/3dff7c2cdf5815b8
 
 I tend to agree with rolling this in to RCH and RPH and seeing if we 
 could refine the processing algorithms therein to satisfy the security 
 issues highlighted in that thread (i.e. ensuring the cross document 
 messaging channel setup from a window.open with a registered protocol 
 handler is origin bound).

I'm not sure it necessarily makes sense to use registerProtocolHandler() 
itself, but something based on it seems like it would work, rather than 
reinventing the wheel entirely.


On Tue, 20 Sep 2011, Paul Kinlan wrote:
 
 Q: Why are the verbs URLs?
 
 Verbs don't have to be URL's but a URL will allow us a point of 
 reference to documentation, versioning and namespacing allowing verbs 
 with similar names but by a different provider to not conflict with each 
 other (thus allowing developers to come up with their own schemes and 
 APIs outside of standardisation).

If they're just arbitrary strings, this should be made clearer.


 Q: Why are some verbs hard-coded into the API?
 
 Convenience and ensuring there is a consistent use of the first set of 
 intents that cover the most common initial use cases.

If the strings are inconvenient enough that you feel the need to provide a 
constant for them, maybe that's a sign that the strings should be changed!

Rather than 'http://webintents.org/share', why not just 'share' for the 
share intent, for example?


 Q: How are types matched?
 
 I don't know the best phrase, mime-typedness.  A direct string 
 comparison unless there is a * after the / (image/*) which then means 
 every image.

This needs to be defined much more precisely. e.g. what happens to MIME 
parameters? Does */* match foo/*? What syntax checking is done on the 
inputs here?


 Q: Why not just improve both navigator.registerContentHandler and
 navigator.registerProtocolHandler?
 
 WI encompasses aspects of both of these API's - but more importantly 
 there are some paradigms we wish to bring that will not fit in to either 
 directly.

I'm not saying to actually use navigator.registerContentHandler and 
navigator.registerProtocolHandler, but why not base something on that API 
rather than reinventing the wheel?


 We want one consistent way of delivering data to applications

Soemthing based on navigator.register*Handler() would give you that. 
Inventing something new wouldn't, since then you'd have two mechanisms 
(the register*Handler() methods, and Web Intents).


 we want it to be a client-side delivery mechanism

If it's going to be entirely client-side, I would recommend using 
MessagePorts, so that the communication isn't just one-post, one-response. 
For example, consider an intent where the provider needs to take the 
submitted data, encrypt it, then hand it back to the original site for a 
signature, then needs to take the result and send it somewhere. With a 
mechanism that just consists of post/response, there's no good way to get 
the data back (you'd have to do it on the server end). If we provide ports 
to communicate back and forth, you wouldn't have a problem.


 and we want applications to be able to tell the action it supports and 
 the data types it can handle.

That doesn't seem hard to do if we just work on an extension to 
register*Handler(). No need for a completely different API.


 Q: How does an already-open page get to handle an action? e.g. say GMail 
 wants to handle the share intent, and the user already has GMail open, 
 and the user clicks a share button on Flickr. How does the existing 
 GMail instance get the notification?
 
 If it was a share, we would envisage the UI to open the compose email 
 function rather than the full interface. 

Sure, but what if the full interface is already open? Maybe Google+ is a 
better example: you could envisage the Share dialog appearing on the 
open Google+ page rather than opening an entirely new page just to share a 
post.

I think this is an important case to support.


 Q: In particular, why are intents registered via a new HTML element 
 rather than an API? How do you unregister? How do you determine if the 
 intent was registered or not? How do you conditionally register (e.g. 
 once the user has paid for the service)?
 
 External discoverability, indexing and scraping is a very important part 
 of the intent tag understanding the API points of an application is very 
 powerful to external systems - via an API we lose this ability, or at 
 least make it fiendishly hard to discover.

Could you elaborate on this need? What use case does it address?

Adding new elements (especially to head) is a high-cost affair and 
should be avoided unless there are really good reasons for it.


 Flexibility for the UA; the UA gets a much richer understanding of the 
 capabilities of

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Tue, Sep 20, 2011 at 3:36 PM, Eric U er...@google.com wrote:
 On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
 On 5/23/11 6:14 PM, Arun Ranganathan wrote:

 On 5/23/11 1:20 PM, Kyle Huey wrote:

 To close the loop a bit here, Firefox 6 will make the change to
 FileReader.abort()'s throwing behavior agreed upon here.
 (https://bugzilla.mozilla.org/show_bug.cgi?id=657964)

 We have not changed the timing of the events, which are still dispatched
 synchronously.

 The editor's draft presently does nothing when readyState is EMPTY, but if
 readyState is DONE it is specified to set result to null and fire events
 (but flush any pending tasks that are queued).

 http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort

 Also note that we're NOT firing *both* error and abort; we should only fire
 abort, and *not* error.

 I should change the spec. to throw.  Eric, you might change the spec. (and
 Chrome) to NOT fire error and abort events :)

 Sorry, to be a bit clearer: I'm talking about Eric changing
 http://dev.w3.org/2009/dap/file-system/file-writer.html#widl-FileSaver-abort-void
 to match http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort

 -- A*




 Sorry about the long delay here--a big release and a new baby absorbed
 a lot of my time.  I'm going through the abort sequence right now, and
 it turns out that there are a number of places in various algorithms
 in FileWriter that should match FileReader more closely than they do.
 However, there a couple of edge cases I'm unsure about.

 1) Do you expect there to be an event called progress that indicates a
 complete read, before the load event?

On further reflection, another requirement prevents this in some
cases.  If you've made a non-terminal progress event less than 50ms
before completion, you're not permitted to make another at completion,
so I think you'd go straight to load and loadend.  However, if the
entire load took place in a single underlying operation that took less
than 50ms, do you have your choice of whether or not to fire
onprogress once before onload?

 user agents MUST return at least one such result while processing
 this read method, with the last returned value at completion of the
 read -- Does that mean during onprogress, or would during onloadend
 be sufficient?  What if the whole blob is read in a single backend
 operation--could there be no calls to onprogress at all?

 [Side note--the phrasing there is odd.  You say that useragents MUST
 return, but the app's not required to call for the value, and it
 can't return it if not asked.  Did you want to require the useragent
 to make at least one onprogress call?]

 2) The load and loadend events are queued When the data from the blob
 has been completely read into memory.  If the user agent fires an
 onprogress indicating all the data's been loaded, and the app calls
 abort in that event handler, should those queued events be fired or
 not?  If there are any tasks from the object's FileReader task source
 in one of the task queues, then remove those tasks. makes it look
 like no, but I wanted to make sure.  If #1 above is no or not
 necessarily, then this might not ever come up anyway.

 Thanks,

    Eric

Notes from a component model pow-wow

2011-09-20 Thread Dominic Cooney

Context: Last week some Bay Area/visiting Bay Area browser hackers met
to discuss the component model
http://wiki.whatwg.org/wiki/Component_Model This is my unedited
transcript. I am not much of a stenographer so no doubt there are
gaps.

Cast of characters:
boris--Boris Zbarsky
dg--Dimitri Glazkov
dpc--Dominic Cooney (me)
hyatt--Dave Hyatt
jamesr--James Robinson
maciej--Maciej Stachowiak
rs--Roland Steiner
sam--Sam Weinig
sicking--Jonas Sicking
slightlyoff--Alex Russell
plus others who I failed to log--sorry

dg: wanted to implement XBL2, 2 years later, slightlyoff (dojo) had
different proposal--simple web components. 1 yr ago post to webkit-dev
about components. XBL2 seems nice because it is a written spec. What's
the shape of the problem? See whatwg wiki Component_Model (MSFT
indicated some interest at least)

GOAL: Make sure everyone understands the problem we're trying to solve.
GOAL: Get feedback on the way to solve the problem.
GOAL: Get specific ideas.

Methodology:
1. Come up with a set of use cases that capture what you want to accomplish.
2. Study use cases come up with a set of properties.
3. Design building blocks that cohere with desired properties.
... see the wiki ... Component_Model_Methodology

Our use cases: Let the things that are happening on the web already
and in web browsers already happen in a more natural fashion. A lot of
JS frameworks do a lot wrong (a lot of crap

sam: what is success?

dg: can accomplish the use cases. Flow from use cases to
properties. Properties are orthogonal to each other. Building blocks
satisfy properties.

use cases: layout manager, can't use components from one library in a
layout manager for another ... see the wiki
... Component_Model_Use_Cases


maciej: what happens if you attach a shadow root to an element that
has a shadow root? dg: we throw--no use cases needed multiple shadow
roots

maciej: shadow root has a constructor, but the constructor has a huge
side effect--it should be a method on element

boris+: programattically building up a shadow tree looks clunky

hyatt: if there is one thing to really look at in XBL2, it is shadow tree stuff
like basic inheritance chain and the concept of explicit children and
insertion points in the shadow tree

maciej: most use cases need a declarative template that describes how
your template is structured based on your children

sam: this is based on use cases from existing widget libraries. The
underlying problem is creating a library. Widget libraries have
imperative code, hence they are imperative. dg: it is not possible to
know until you're running what your shape can be. sicking/hyatt: form
controls or video know their shape.

dg: people will still want an imperative way to build trees--so build
the declarative version using imperative code.

boris: this relies on the component to not leak the shadow tree. It
would be easier if the script is not in the document.

hyatt: you might have script that runs on the shadow root that needs to
be structured

maciej: programmatically building can be the primitive or you could
build the template mechanism on top; if you imagine the template is
the common case, then sometimes you need the script to attach event
handlers or mutate the dom the template created. So it depends what
you think the common case is before you design your primitives.

dg: this is just like DOM--you can add methods to existing DOM tree,
you can programatically build a tree; you can declaratively build a
tree

dpc: so if you had both that would be no bad thing hyatt: but we only
see the programmatic way here

dg: content element--insertion point inside the shadow tree, content
element lets you control how the shadow tree is flattened.

maciej + apple: need to see details boris: devil is in the details

dg: constructable DOM types

sam: is this just slightlyoff's proposal on script-coord? dg: no, that
is just say new ...(), this is about making subtypes

maciej: three parts 1. create existing built-in types, 2. if you have
a custom element that is logically a subclass of some element you need
to be able to construct that as well (dg: that is the one!) either by
defining its own way of getting constructed or hooking into some
common mechanism. 3. you need that subclassing mechanism to let
elements get privileged access to it. Maybe the primitives are
designed in such a way that you don't need it, but just #2 doesn't let
you override behavior.

dg: you can do that (#2) today with swizzling the prototype chain, boris:
you can't create a subtype with a different tag name--there is no real
reason that has to be the case.

maciej: ... so you need to create something that subclasses div and
has its own tag name.

dg: garden-o-matic uses constructable DOM types. But when you get them
back out of the DOM tree, your proto is gone.

hyatt: that (subclassing) seems natural

boris: seems like a good idea, lets not rathole on the details just yet

dg: so how does this interact with parsing? if I round trip

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Tue, Sep 20, 2011 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Tue, Sep 20, 2011 at 4:28 PM, Eric U er...@google.com wrote:
 On Tue, Sep 20, 2011 at 3:36 PM, Eric U er...@google.com wrote:
 On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
 On 5/23/11 6:14 PM, Arun Ranganathan wrote:

 On 5/23/11 1:20 PM, Kyle Huey wrote:

 To close the loop a bit here, Firefox 6 will make the change to
 FileReader.abort()'s throwing behavior agreed upon here.
 (https://bugzilla.mozilla.org/show_bug.cgi?id=657964)

 We have not changed the timing of the events, which are still dispatched
 synchronously.

 The editor's draft presently does nothing when readyState is EMPTY, but if
 readyState is DONE it is specified to set result to null and fire events
 (but flush any pending tasks that are queued).

 http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort

 Also note that we're NOT firing *both* error and abort; we should only fire
 abort, and *not* error.

 I should change the spec. to throw.  Eric, you might change the spec. (and
 Chrome) to NOT fire error and abort events :)

 Sorry, to be a bit clearer: I'm talking about Eric changing
 http://dev.w3.org/2009/dap/file-system/file-writer.html#widl-FileSaver-abort-void
 to match http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort

 -- A*




 Sorry about the long delay here--a big release and a new baby absorbed
 a lot of my time.  I'm going through the abort sequence right now, and
 it turns out that there are a number of places in various algorithms
 in FileWriter that should match FileReader more closely than they do.
 However, there a couple of edge cases I'm unsure about.

 1) Do you expect there to be an event called progress that indicates a
 complete read, before the load event?

 On further reflection, another requirement prevents this in some
 cases.  If you've made a non-terminal progress event less than 50ms
 before completion, you're not permitted to make another at completion,
 so I think you'd go straight to load and loadend.  However, if the
 entire load took place in a single underlying operation that took less
 than 50ms, do you have your choice of whether or not to fire
 onprogress once before onload?

 This is a spec-bug. We need to make an exception from the 50ms rule
 for the last onprogress event.

 From the webpage point of view, the following invariants should hold
 for each load:

 1. onloadstart fires exactly once
 2. There will be one onprogress event fired when 100% progress is reached
 3. Exactly one of onabort, onload and onerror fires
 4. onloadend fires exactly once.
 6. no onprogress events fire before onloadstart
 5. no onprogress events fire after onabort/onload/onerror
 6. no onabort/onoad/onerror events fire after onloadend

 The reason for 2 is so that the page always renders a complete
 progress bar if it only does progressbar updates from the onprogress
 event.

 Hope that makes sense?

It makes sense, and in general I like it.  But the sequence can get
more complicated [specifically, nested] if you have multiple read
calls, which is the kind of annoyance that brought me to send the
email.

I have a read running, and at some point I abort it--it could be in
onprogress or elsewhere.  In onabort I start another read.  In
onloadstart I abort again.  Repeat as many times as you like, then let
a read complete.  I believe we've specced that the event sequence
should look like this:

loadstart
[progress]*
--[events from here to XXX happen synchronously, with no queueing]
abort
loadstart
abort
loadstart
abort
loadstart
loadend
loadend
loadend
--[XXX]
[progress]+
load
loadend

Does that look like what you'd expect?  Am I reading it right?  Yes,
this is a wacky fringe case.  But it's certainly reasonable to expect
someone to start a new read in onabort, so you have to implement at
least enough bookkeeping for that case.  And UAs will want to defend
against stack overflow, in the event that a bad app sticks in an
abort/loadstart loop.

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

2011-09-20 Thread Glenn Maynard

On Tue, Sep 20, 2011 at 8:01 PM, Eric U er...@google.com wrote:

 I have a read running, and at some point I abort it--it could be in
 onprogress or elsewhere.  In onabort I start another read.  In
 onloadstart I abort again.  Repeat as many times as you like, then let
 a read complete.  I believe we've specced that the event sequence
 should look like this:

 loadstart
 [progress]*
 --[events from here to XXX happen synchronously, with no queueing]
 abort
 loadstart

abort
 loadstart


XHR handles this by not allowing a new request to be opened until the
abort() method terminates.  Could that be done here?  It seems like an
important thing to be consistent about.

http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-abort-method

-- 
Glenn Maynard

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

2011-09-20 Thread Jonas Sicking

On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Sep 20, 2011 at 8:01 PM, Eric U er...@google.com wrote:

 I have a read running, and at some point I abort it--it could be in
 onprogress or elsewhere.  In onabort I start another read.  In
 onloadstart I abort again.  Repeat as many times as you like, then let
 a read complete.  I believe we've specced that the event sequence
 should look like this:

 loadstart
 [progress]*
 --[events from here to XXX happen synchronously, with no queueing]
 abort
 loadstart

 abort
 loadstart

 XHR handles this by not allowing a new request to be opened until the
 abort() method terminates.  Could that be done here?  It seems like an
 important thing to be consistent about.

 http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-abort-method

Ooh, that's a good idea.

/ Jonas

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors