Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
On Jun/10/2011 3:05 PM, ext Ian Hickson wrote: On Fri, 10 Jun 2011, Arthur Barstow wrote: My take on the comments is that most commentors prefer the spec to be changed as PLH suggested in comment #5: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c5 Hixie - are you willing to change the spec accordingly? What's the rush here? This is a minor issue, which I plan to address in due course. It's not blocking implementors, it's not causing any interoperability trouble, it's not stopping someone from writing a test suite, why all the fuss? I would like all of the group's specs to keep moving forward on the Recommendation track. That is an expectation set forth in the group's charter and I don't think I have ever asked the group to rush this or any other spec. (On the contrary, I have supported longer review periods when requested and do not enforce the 90-day heartbeat publication policy just to publish.) In this case, at least one other spec (which is planned for Proposed Recommendation in early August) has a normative dependency on Storage (and these functions in particular). Although the reference policy provides some flexibility, I think it is sub-optimal for later stage specs to depend on specs that are still changing. I would appreciate it, if you would please provide a date when you expect to have addressed this issue. (FYI, Cam is working on a schedule to move Web IDL to LC which is the only other dependency not yet at LC for the spec mentioned above.) -AB
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
On Sat, 11 Jun 2011, Arthur Barstow wrote: On Jun/10/2011 3:05 PM, ext Ian Hickson wrote: On Fri, 10 Jun 2011, Arthur Barstow wrote: My take on the comments is that most commentors prefer the spec to be changed as PLH suggested in comment #5: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c5 Hixie - are you willing to change the spec accordingly? What's the rush here? This is a minor issue, which I plan to address in due course. It's not blocking implementors, it's not causing any interoperability trouble, it's not stopping someone from writing a test suite, why all the fuss? I would like all of the group's specs to keep moving forward on the Recommendation track. That is an expectation set forth in the group's charter and I don't think I have ever asked the group to rush this or any other spec. (On the contrary, I have supported longer review periods when requested and do not enforce the 90-day heartbeat publication policy just to publish.) The recommendation track is an archaic mechanism. We shouldn't do things just because they are in charters or process documents, we should do things because they make sense and improve the Web. In this case, at least one other spec (which is planned for Proposed Recommendation in early August) has a normative dependency on Storage (and these functions in particular). Although the reference policy provides some flexibility, I think it is sub-optimal for later stage specs to depend on specs that are still changing. I would be absoluely fine with Web Storage going to REC right now. There's no reason we need to gate on this particular issue. You can go ahead and publish the doc as LC, CR, PR, whatever it is you need. Heck even if the spec wasn't ready according to the process document, there's ample precedent in the W3C for publishing documents completely in violation of the process. XHTML never had a test suite before going to REC, for instance. SVG went to CR with literally dozens of open issues and didn't even report half the formal objections. Nobody else follows process, why should we? I would appreciate it, if you would please provide a date when you expect to have addressed this issue. That's not how this works. (FYI, Cam is working on a schedule to move Web IDL to LC which is the only other dependency not yet at LC for the spec mentioned above.) And what will happen to Web IDL when we find that we need to change something? Web IDL is a core platform spec, it's not like it's ever going to be finished. The particular issue in question isn't a particularly important one. The spec describes a superset of implementations, and is a logical direction for the spec to go. (Even within the process, there's no reason we couldn't go to LC with it as is.) Implementations are the ultimate guide here, when this issue bubbles up to the top of the priority list then it'll get resolved one way or the other based on what they do and want. However, I'm not going to arbitrarily prioritise issues just for bureaucratic reasons. (This isn't a trivial issue to resolve, it would take me a few hours of carefully asking questions of the various browser vendors.) There are far bigger fish to fry right now on the Web platform than whether or not vendors' long-term plans include supporting File objects in localStorage, or what not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
On Sat, Jun 11, 2011 at 4:32 AM, Arthur Barstow art.bars...@nokia.comwrote: On Jun/10/2011 3:05 PM, ext Ian Hickson wrote: On Fri, 10 Jun 2011, Arthur Barstow wrote: My take on the comments is that most commentors prefer the spec to be changed as PLH suggested in comment #5: http://www.w3.org/Bugs/Public/**show_bug.cgi?id=12111#c5http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c5 Hixie - are you willing to change the spec accordingly? What's the rush here? This is a minor issue, which I plan to address in due course. It's not blocking implementors, it's not causing any interoperability trouble, it's not stopping someone from writing a test suite, why all the fuss? I would like all of the group's specs to keep moving forward on the Recommendation track. That is an expectation set forth in the group's charter and I don't think I have ever asked the group to rush this or any other spec. (On the contrary, I have supported longer review periods when requested and do not enforce the 90-day heartbeat publication policy just to publish.) In this case, at least one other spec (which is planned for Proposed Recommendation in early August) has a normative dependency on Storage (and these functions in particular). Although the reference policy provides some flexibility, I think it is sub-optimal for later stage specs to depend on specs that are still changing. I would appreciate it, if you would please provide a date when you expect to have addressed this issue. (FYI, Cam is working on a schedule to move Web IDL to LC which is the only other dependency not yet at LC for the spec mentioned above.) -AB I am speaking only for myself (and not Google, WebKit, or Chromium) but I feel obligated to point out that localStorage specifies a fundamentally broken synchronization model that we are not able to fix due to compatibility concerns. This is noted at http://dev.w3.org/html5/webstorage/#issues with a tragically optimistic request for suggestions. As an implementor, my main motivation to pay any attention to localStorage is to think up ways to discourage authors from using it for anything non-trivial. In my opinion, the only thing left to be done with localStorage is to write it off as an unfortunate failure, learn our lesson, and move on. This may not be relevant to the processes you are trying to follow. - James
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
On Sat, Jun 11, 2011 at 12:32 PM, Arthur Barstow art.bars...@nokia.com wrote: On Jun/10/2011 3:05 PM, ext Ian Hickson wrote: On Fri, 10 Jun 2011, Arthur Barstow wrote: My take on the comments is that most commentors prefer the spec to be changed as PLH suggested in comment #5: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c5 Hixie - are you willing to change the spec accordingly? What's the rush here? This is a minor issue, which I plan to address in due course. It's not blocking implementors, it's not causing any interoperability trouble, it's not stopping someone from writing a test suite, why all the fuss? I would like all of the group's specs to keep moving forward on the Recommendation track. That is an expectation set forth in the group's charter and I don't think I have ever asked the group to rush this or any other spec. (On the contrary, I have supported longer review periods when requested and do not enforce the 90-day heartbeat publication policy just to publish.) Although we can all appreciate not being rushed to finish, I wonder if forcing the 90 day requirement might work as a good way to short circuit the W3C's process wrt putting Editor's drafts on /TR/. Might also start discouraging certain implementers from cherry-picking dated specs - which would be a really good thing. 3 months is actually an ok time frame; and it's better than specs stagnating on /TR/ while all the real work happens in the Editor's drafts. I would support moving to a 3 month pub model or maybe even monthly snapshots. Specially now that the W3C is allowing editors to put big red warnings about specs being out of date: http://www.w3.org/TR/2011/WD-html5-20110525/ I was previously blocked by the W3C pub team from putting one of these big red banners into my specs, so I'm super happy to see the HTML spec having one. This has set a fantastic precedence and hopefully this practice will be adopted across the W3C. In this case, at least one other spec (which is planned for Proposed Recommendation in early August) has a normative dependency on Storage (and these functions in particular). Although the reference policy provides some flexibility, I think it is sub-optimal for later stage specs to depend on specs that are still changing. I don't think we have much option here. Prematurely slapping REC on specs without having things thoroughly implemented and tested in the wild would be a mistake, IMO we are seeing the consequences of this ATM with Web Storage. Part of the natural evolution of things. -- Marcos Caceres http://datadriven.com.au
[Bug 12941] New: If I understand what I'm reading correctly, there's an error at the end of A background number-crunching worker tutorial. I think you mean postMessage() instead of send() in t
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12941 Summary: If I understand what I'm reading correctly, there's an error at the end of A background number-crunching worker tutorial. I think you mean postMessage() instead of send() in the sentence To send a message back to the page, the send() method is used 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/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: If I understand what I'm reading correctly, there's an error at the end of A background number-crunching worker tutorial. I think you mean postMessage() instead of send() in the sentence To send a message back to the page, the send() method is used to post a message when a prime is found. Also, I think it reads with a bit of redundancy, but that's a minor quibble. -- Kevin Cole, Gallaudet University kevin.c...@gallaudet.edu Posted from: 68.33.80.144 User agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 -- 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: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Fri, Jun 10, 2011 at 5:13 PM, Cameron McCormack c...@mcc.id.au wrote: Mark Pilgrim: What about setVersion() with no arguments? I ask because WebKit currently treats it like setVersion(undefined) and I'm in the process of fixing it in about 19 places. That’s the right behaviour. Huh?? At least in the Gecko DOM implementation we always throw an exception if too few parameters are defined. Only if parameters are explicitly marked as [optional] are you allowed to not include them. I was under the impression that this was the case in most DOM implementations, with notable exception of webkit. / Jonas
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
On Sat, 11 Jun 2011, James Robinson wrote: I am speaking only for myself (and not Google, WebKit, or Chromium) but I feel obligated to point out that localStorage specifies a fundamentally broken synchronization model that we are not able to fix due to compatibility concerns. This is noted at http://dev.w3.org/html5/webstorage/#issues with a tragically optimistic request for suggestions. As an implementor, my main motivation to pay any attention to localStorage is to think up ways to discourage authors from using it for anything non-trivial. In my opinion, the only thing left to be done with localStorage is to write it off as an unfortunate failure, learn our lesson, and move on. Yeah, that is also a pretty good point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
