[Bug 14677] New: Hey, There! =D My name is Felipe. And I'm looking around this new tecnology. I'm really enjoying it.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14677 Summary: Hey, There! =D My name is Felipe. And I'm looking around this new tecnology. I'm really enjoying it. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/workers/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Hey, There! =D My name is Felipe. And I'm looking around this new tecnology. I'm really enjoying it. Posted from: 189.105.98.210 User agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2 -- 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.
[Bug 14677] Hey, There! =D My name is Felipe. And I'm looking around this new tecnology. I'm really enjoying it.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14677 Simon Pieters sim...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- 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.
[Bug 13786] Drop the charset parameter or made it non-conforming. Other MIME types introduced by this specification do not allow the charset parameter.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13786 Anne ann...@opera.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #13 from Anne ann...@opera.com 2011-11-02 14:18:37 UTC --- We should ignore the other parameters too. Name one format that is similar to text/event-stream. -- 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.
[Bug 14199] IDBVersionChangeEvent still uses DOMString for version
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14199
Eliot Graff eliot...@microsoft.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
--- Comment #3 from Eliot Graff eliot...@microsoft.com 2011-11-02 15:01:09
UTC ---
Fixed in the 1 November Editor's Draft:
interface IDBVersionChangeEvent : Event {
readonly attribute unsigned long long oldVersion;
readonly attribute unsigned long long newVersion;
void initIDBVersionChangeEvent (DOMString typeArg, boolean canBubbleArg,
boolean cancelableArg, long long oldVersion, long long newVersion);
};
I think newVersion should be long long rather than any. The only time it is
null is when it is deleted.
Thanks,
Eliot
--
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.
[Bug 14412] IDBFactorySync should have .cmp too
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14412 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Eliot Graff eliot...@microsoft.com 2011-11-02 15:04:35 UTC --- Added cmp() to IDBFactorySync in the Nov 1 Editor's Draft. Thanks for the bug! -- 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.
[Bug 14488] [IDBObjectStore|IDBIndex].count description should specify optional argument behavior a little better
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14488 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Eliot Graff eliot...@microsoft.com 2011-11-02 15:09:24 UTC --- I changed the wording just a little bit to overtly state that the param is optional: If the optional key parameter is not a valid key or a key range, this method throws a DOMException of type DataError. The change is published in the 1 November Editor's Draft. Thanks for the feedback. -- 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.
[Bug 14384] upgradeneeded event should set request.readyState to DONE
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14384 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #4 from Eliot Graff eliot...@microsoft.com 2011-11-02 15:13:11 UTC --- 4.8 VERSION_CHANGE transaction steps now states in step 9.3: Fire a upgradeneeded event targeted at request. The event must use the IDBVersionChangeEvent interface and have the oldVersion property set to old version and have the newVersion property set to version. The readyState on the request is set to DONE. Published in 1 November Editor's Draft. Thanks for catching this. -- 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.
[Bug 14199] IDBVersionChangeEvent still uses DOMString for version
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14199
Ms2ger ms2...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||ms2...@gmail.com
Resolution|FIXED |
--- Comment #5 from Ms2ger ms2...@gmail.com 2011-11-02 15:48:39 UTC ---
(In reply to comment #4)
(In reply to comment #3)
Fixed in the 1 November Editor's Draft:
interface IDBVersionChangeEvent : Event {
readonly attribute unsigned long long oldVersion;
readonly attribute unsigned long long newVersion;
void initIDBVersionChangeEvent (DOMString typeArg, boolean canBubbleArg,
boolean cancelableArg, long long oldVersion, long long newVersion);
};
I think newVersion should be long long rather than any. The only time it is
null is when it is deleted.
It should be nullable (unsigned long long?) then, right?
Yes.
--
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: Spec changes for LCs and later maturity levels [Was: Re: RfC: LCWD of Web Socket API; comment deadline October 21]
On 2011-10-14 15:14, Julian Reschke wrote: On 2011-10-11 00:30, Ian Hickson wrote: On Sun, 9 Oct 2011, Arthur Barstow wrote: On 10/7/11 8:32 AM, ext Julian Reschke wrote: As far as I recall, we agreed in the IETF WG that parsing of web socket URIs should work exactly the same way as for any other URI scheme. It appears that the API spec now tries to override this, and this looks problematic to me. On 10/7/11 9:30 AM, ext Arthur Barstow wrote: In [1], Julian asks about Web Socket API rev 1.247 [2], the change that adds the Parsing WebSocket URLs section (CVS comment Revert the part of r5409 that removed the URL parsing algorithms, since it's no longer defined in the protocol spec. (whatwg r6632)). Would you please elaborate on this change? On 10/7/11 11:28 AM, ext Ian Hickson wrote: Elaborate in what way? Why is the override in 1.247 needed, given what Julian indicates above? There's no override. It's just defining how you do it because nothing else defines it. As far as I can tell, it's a mix of things repeated from https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-3, things that may be useful, and things that do not make sense at all. In particular: Resolve the url string, with the URL character encoding set to UTF-8. [RFC3629] Resolve is undefined as far as I can tell, in particular it's not clear at all what URL character encoding means in this context. Best regards, Julian So can anybody explain (1) why this text is in the spec, and (2) what it means? Thanks, Julian
Re: Spec changes for LCs and later maturity levels
On Wed, 02 Nov 2011 09:33:00 -0700, Julian Reschke julian.resc...@gmx.de wrote: So can anybody explain (1) why this text is in the spec, and (2) what it means? It just moved from the protocol to the API. It was in the protocol before: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-01#section-3 -- Anne van Kesteren http://annevankesteren.nl/
Re: Spec changes for LCs and later maturity levels
On 2011-11-02 17:39, Anne van Kesteren wrote: On Wed, 02 Nov 2011 09:33:00 -0700, Julian Reschke julian.resc...@gmx.de wrote: So can anybody explain (1) why this text is in the spec, and (2) what it means? It just moved from the protocol to the API. It was in the protocol before: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-01#section-3 Yes, and the Working Group removed it because it didn't make sense. It duplicates something that was somewhere else earlier on may be an explanation of what happened process-wise, but doesn't explain why it's the right thing to do. Best regards, Julian
Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors
On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote: 1. Make loadend not fire in case a new load is started from onabort/onload/onerror. Thus loadend and loadstart isn't always paired up. Though there is always a loadend fired after every loadstart. 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also leaves the problem unsolved for XHR. Are there other options I'm missing? Or do both, improving XHR as much as backwards-compatibility allows and don't try to match other APIs to it exactly. I'd much prefer weirdness be isolated to XHR than be perpetuated through every PE-based API. So what exactly are you proposing we do for XHR and for FileReader/FileWriter? I'm still not convinced that it's better for authors to require them to use setTimeout to start a new load as opposed to let them restart the new load from within an event and cancel all following events. I agree that this introduces some inconsistency, but it only does so when authors explicitly reuses a FileReader/XHR/FileWriter for multiple requests. And it only weakens the invariant, not removes it. So instead of * There's exactly one 'loadend' event for each 'loadstart' event. we'll have * There's always a 'loadend' event fired after each 'loadstart' event. However there might be other 'loadstart' events fired in between. I'm for this. It lets FileReader and FileWriter match XHR, avoids [in the odd case] long strings of stacked-up loadend events, and users can avoid all the issues either by creating a new FileReader or by wrapping nested calls in timers if they care. I believe Jonas is in favor of this as well. Can we put this one to bed? Eric
Re: [File API] Calling requestFileSystem with bad filesystem type
On Fri, Oct 7, 2011 at 12:02 PM, Mark Pilgrim pilg...@google.com wrote: What should this do? requestFileSystem(2, 100, successCallback); // assume successCallback is defined properly requestFileSystem doesn't throw, so you should get an errorCallback call. You haven't provided an errorCallback, so you should get a silent failure. It does seem like an error we could identify quickly enough to throw, though, and in general I favor fail-fast for obviously bad parameters. Opinions? Eric
Re: Spec changes for LCs and later maturity levels
On Wed, 02 Nov 2011 09:49:08 -0700, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-02 17:39, Anne van Kesteren wrote: On Wed, 02 Nov 2011 09:33:00 -0700, Julian Reschke julian.resc...@gmx.de wrote: So can anybody explain (1) why this text is in the spec, and (2) what it means? It just moved from the protocol to the API. It was in the protocol before: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-01#section-3 Yes, and the Working Group removed it because it didn't make sense. Citation needed. -- Anne van Kesteren http://annevankesteren.nl/
Re: Spec changes for LCs and later maturity levels
On 2011-11-02 19:17, Anne van Kesteren wrote: On Wed, 02 Nov 2011 09:49:08 -0700, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-02 17:39, Anne van Kesteren wrote: On Wed, 02 Nov 2011 09:33:00 -0700, Julian Reschke julian.resc...@gmx.de wrote: So can anybody explain (1) why this text is in the spec, and (2) what it means? It just moved from the protocol to the API. It was in the protocol before: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-01#section-3 Yes, and the Working Group removed it because it didn't make sense. Citation needed. The mail thread that lead to the change starts here: https://www.ietf.org/mail-archive/web/hybi/current/msg07377.html How about following up on http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0244.html? Best regards, Julian
Re: Spec changes for LCs and later maturity levels
On Wed, 02 Nov 2011 11:32:30 -0700, Julian Reschke julian.resc...@gmx.de wrote: The mail thread that lead to the change starts here: https://www.ietf.org/mail-archive/web/hybi/current/msg07377.html I clicked through that thread and could not find anything where a decision was made and on what grounds. How about following up on http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0244.html? If you are confused about the terms, they are defined in HTML. -- Anne van Kesteren http://annevankesteren.nl/
Re: Spec changes for LCs and later maturity levels
On Wed, 02 Nov 2011 11:59:14 -0700, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-02 19:46, Anne van Kesteren wrote: If you are confused about the terms, they are defined in HTML. But they aren't linked, as far as I can tell. It would be good if they were, and then we can review that text again. They are in http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#parsing-websocket-urls so you can use that for review. We are still looking for volunteers to make this work for specifications generated separately. For now they have a note at the top that indicates the terminology comes from other specifications. -- Anne van Kesteren http://annevankesteren.nl/
Re: Spec changes for LCs and later maturity levels
On 2011-11-02 19:46, Anne van Kesteren wrote: On Wed, 02 Nov 2011 11:32:30 -0700, Julian Reschke julian.resc...@gmx.de wrote: The mail thread that lead to the change starts here: https://www.ietf.org/mail-archive/web/hybi/current/msg07377.html I clicked through that thread and could not find anything where a decision was made and on what grounds. How about following up on http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0244.html? If you are confused about the terms, they are defined in HTML. But they aren't linked, as far as I can tell. It would be good if they were, and then we can review that text again. Best regards, Julian
[Bug 14660] [Editorial] Clarification for CLOSING in Garbage Collection
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14660 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WORKSFORME --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-11-02 20:46:36 UTC --- This has already been fixed. -- 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: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors
On Wed, Nov 2, 2011 at 9:56 AM, Eric U er...@google.com wrote: On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote: 1. Make loadend not fire in case a new load is started from onabort/onload/onerror. Thus loadend and loadstart isn't always paired up. Though there is always a loadend fired after every loadstart. 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also leaves the problem unsolved for XHR. Are there other options I'm missing? Or do both, improving XHR as much as backwards-compatibility allows and don't try to match other APIs to it exactly. I'd much prefer weirdness be isolated to XHR than be perpetuated through every PE-based API. So what exactly are you proposing we do for XHR and for FileReader/FileWriter? I'm still not convinced that it's better for authors to require them to use setTimeout to start a new load as opposed to let them restart the new load from within an event and cancel all following events. I agree that this introduces some inconsistency, but it only does so when authors explicitly reuses a FileReader/XHR/FileWriter for multiple requests. And it only weakens the invariant, not removes it. So instead of * There's exactly one 'loadend' event for each 'loadstart' event. we'll have * There's always a 'loadend' event fired after each 'loadstart' event. However there might be other 'loadstart' events fired in between. I'm for this. It lets FileReader and FileWriter match XHR, avoids [in the odd case] long strings of stacked-up loadend events, and users can avoid all the issues either by creating a new FileReader or by wrapping nested calls in timers if they care. I believe Jonas is in favor of this as well. Can we put this one to bed? So the proposal here is to allow new loads to be started from within abort/error/load event handlers, and for loadend to *not* fire if a new load has already started by the time the abort/error/load event is done firing. And the goal is that XMLHttpRequest, FileReader and FileWriter all behave this way. Is this correct? If so, I agree that this sounds like a good solution. / Jonas
Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors
On Wed, Nov 2, 2011 at 3:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Nov 2, 2011 at 9:56 AM, Eric U er...@google.com wrote: On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote: 1. Make loadend not fire in case a new load is started from onabort/onload/onerror. Thus loadend and loadstart isn't always paired up. Though there is always a loadend fired after every loadstart. 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also leaves the problem unsolved for XHR. Are there other options I'm missing? Or do both, improving XHR as much as backwards-compatibility allows and don't try to match other APIs to it exactly. I'd much prefer weirdness be isolated to XHR than be perpetuated through every PE-based API. So what exactly are you proposing we do for XHR and for FileReader/FileWriter? I'm still not convinced that it's better for authors to require them to use setTimeout to start a new load as opposed to let them restart the new load from within an event and cancel all following events. I agree that this introduces some inconsistency, but it only does so when authors explicitly reuses a FileReader/XHR/FileWriter for multiple requests. And it only weakens the invariant, not removes it. So instead of * There's exactly one 'loadend' event for each 'loadstart' event. we'll have * There's always a 'loadend' event fired after each 'loadstart' event. However there might be other 'loadstart' events fired in between. I'm for this. It lets FileReader and FileWriter match XHR, avoids [in the odd case] long strings of stacked-up loadend events, and users can avoid all the issues either by creating a new FileReader or by wrapping nested calls in timers if they care. I believe Jonas is in favor of this as well. Can we put this one to bed? So the proposal here is to allow new loads to be started from within abort/error/load event handlers, and for loadend to *not* fire if a new load has already started by the time the abort/error/load event is done firing. And the goal is that XMLHttpRequest, FileReader and FileWriter all behave this way. Is this correct? I think I may have missed something important. XHR2 specs just this behavior w.r.t. abort [another open will stop the abort's loadend] but /doesn't/ spec that for error or load. That is, an open() in onerror or onload does not appear to cancel the pending loadend. Anne, can you comment on why? If so, I agree that this sounds like a good solution. / Jonas
Component Model f2f: Actionable things
You can see the minutes here: http://www.w3.org/2011/11/02-webapps-minutes.html First of all, thank you all for coming and participating. It was exhausting, and we just ran out of time. Stupid time! There was also a great conversation post-meeting, but unfortunately no minutes :( Things to act on as I see them, in random order -- please add your own: PROBLEM: Peeps hate constructable DOM elements. I saw uniform allergic reaction to HTMLElement.call across the browser- and spec-folk. ACTION: sugar this up as a declarative syntax and lead with that. PROBLEM: There is a strong desire for a simple answer to the consumer use case: I like your component library and would like to use it. How do I do that? ACTION: come up with a strong declarative proposal which explains that, build consensus and turn it into a spec. PROBLEM: Cross-origin components are a big deal and should not be waved off as something to do later. ACTION: Write confinement/isolation proposal, build consensus and turn it into a spec. PROBLEM: Currently, decorators are not part the component model. There's a strong desire to satisfy at least some use cases that decorators enable (binding with CSS, dynamic attachment/detachment) ACTION: Come up with a decorator proposal - consensus - spec. PROBLEM: I want to play with this before I can tell if it's good. ACTION: provide an experimental build to play with as soon as possible. PROBLEM: It's hard to see how shadow DOM can stand on its own or why that would be useful. ACTION: write shadow DOM spec, including examples on how it can be used. PROBLEM: What is this I don't even ACTION: lol :DG
CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9
During the October 31 meeting [1], there was agreement to publish a Candidate Recommendation of the WebSockets API and this is a Call for Consensus to do so: http://dev.w3.org/html5/websockets/ The remaining open editorial bug [13700] will be fixed before publication. I propose the CR exit criteria is the same as our last CR (Progress Events): [[ To exit the Candidate Recommendation (CR) stage the following criteria must have been met: 1. There will be at least two interoperable implementations passing all test cases in the test suite for this specification. An implementation is to be available (i.e. for download), shipping (i.e. not private), and not experimental (i.e. intended for a wide audience). The working group will decide when the test suite is of sufficient quality to test interoperability and will produce an implementation report (hosted together with the test suite). 2. A minimum of three months of the CR stage will have elapsed (i.e. not until after DD MMM 2012). This is to ensure that enough time is given for any remaining major errors to be caught. The CR period will be extended if implementations are slow to appear. ]] 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 As with all of our CfCs, positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is November 9 and all comments should be sent to public-webapps at w3.org. -AB [1] http://www.w3.org/2011/10/31-webapps-minutes.html#item14 [13700] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13700
We just ran out of time ... [Was: Re: Component Model f2f: Actionable things]
On 11/2/11 6:41 PM, ext Dimitri Glazkov wrote: You can see the minutes here: http://www.w3.org/2011/11/02-webapps-minutes.html Thanks Dimitri. First of all, thank you all for coming and participating. That goes for me and Chaals too re Monday and Tuesday! It was exhausting, and we just ran out of time. Stupid time! Well, we may get together more frequently than just the annual TPAC meeting week. If folks think that would be useful (e.g. in 6 months), please speak up and we can take it from there. Otherwise, WebApps' next f2f meeting is during the 2012 TPAC meeting in Lyon, FR Oct 29 - Nov 2. -AB
