RfC: LCWD of Selectors API Level 1; deadline July 19
This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. -Thanks, AB
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
Arthur Barstow art.bars...@nokia.com wrote: This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. Section 1 contains a unwanted duplication: With these methods methods, There is something odd about the way matching is defined: Section 6 defines matching Element node directly in terms of the [SELECT] reference, then section 6.4 defines what it means to evaluate a selector but this is never referenced. I think section 6 needs to define matching Element node as something like: An Element node is a matching Element node if the result of invoking the *evaluate a selector* algorithm with the selector and the Element bnode is true. And then have the matching rules in a separate explanatory sentence in 6.4: Selectors are evaluated against the given element according to the rules for matching elements defined in Selectors [SELECT]. This would seem to be the original intention - the algorithm was added, but then section 6 wasn't updated (it's the same as in the previous CR) Did an edit go missing somewhere? -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
[Bug 17643] New: What should transaction.error be set to if a error handler throws an exception
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17643
Summary: What should transaction.error be set to if a error
handler throws an exception
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jo...@sicking.cc
QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
The most basic question is, what should happen in the following scenario:
objectStore.add(value, 1); // succeeds
req = objectStore.add(value, 1); // will fail due to key collision
req.onerror = function(e) {
throw;
}
This should obviously abort the transaction, but should transaction.error.name
return ConstraintError or AbortError.
I don't have a strong opinion.
It sort of feels like the exception does override normal behavior, so we should
set it to AbortError.
--
Configure bugmail: https://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 17644] New: OK I spent hours all over the web and your docs getting to grips with websocket, my question now is this.... in the the handshake....how does one actually implement the header for t
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17644 Summary: OK I spent hours all over the web and your docs getting to grips with websocket, my question now is this in the the handshakehow does one actually implement the header for the websocket? there is not explanation of this anywhere... how is the head 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: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: OK I spent hours all over the web and your docs getting to grips with websocket, my question now is this in the the handshakehow does one actually implement the header for the websocket? there is not explanation of this anywhere... how is the header constructed in either php or javascript for the websocket handshake for the example like: GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Because during my test...I in chrome I see the error: Error during WebSocket handshake: 'Sec-WebSocket-Accept' header is missing in the server it keeps disconnecting...I am testing locally in xampp...and and enabled the websocket that works with like: php -q C:\xampp\htdocs\server\server.php but it disconnects and the chrome console shows: Error during WebSocket handshake: 'Sec-WebSocket-Accept' header is missing Can I see an example of how to actually send the headers and the Sec-WebSocket-Key in when we send the handshake? Posted from: 87.114.223.140 User agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5 -- Configure bugmail: https://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 17645] New: Define more precisely what the origin of the IDBEnvironment is
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17645 Summary: Define more precisely what the origin of the IDBEnvironment is Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jo...@sicking.cc QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Specifically, we should make it clear that document.domain doesn't affect indexedDB at all. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[websockets] Seeking comments on moving back to CR; deadline July 9
Hi All, Since this was a busy week for some group members and I will be offline for several days, let's extend the deadline for comments until July 9. If you have any feedback, please reply by July 9. -Thanks, Art Original Message Subject:[websockets] Seeking comments on moving back to CR; deadline June 28 Resent-Date:Thu, 21 Jun 2012 14:29:06 + Resent-From:public-webapps@w3.orgmailto:public-webapps@w3.org Date: Thu, 21 Jun 2012 10:28:31 -0400 From: ext Arthur Barstow art.bars...@nokia.commailto:art.bars...@nokia.com To: public-webapps public-webapps@w3.orgmailto:public-webapps@w3.org Hi All, I created a tracking document for the two comments and five bugs that were submitted against the 24 May LCWD of Web Sockets (or in the approximate time frame of that publication): http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-24May2012http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-24May2012. Below is my take on these bugs and comments. It would be good to get this spec back to CR and hence closer toward the IP commitments that will only be final when the spec reaches Recommendation. Bugs: * 17073 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073 - marked as an Enhancement; don't include in the v1 CR * 17224 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224 - this looks like an Editorial bug to me as I stated in the bug. Assuming there is consensus the text should be unsolicited pongs, if Hixie can't fix this before the v1 CR copy is created, I'll make this change in the v1 CR. * 17262 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262 - Jonas' view as expressed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262#c13https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262#c13 seems reasonable so I propose closing this with a resolution of WorksForMe. * 17263 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263 - send(ArrayBuffer), which was included in the December 2011 CR, has been implemented and presumably must be supported by some browsers (e.g. bc/legacy reasons). As such, it seems reasonable to fix this bug and perhaps we could argue a new LCWD is not needed since it has already been implemented. * 17264 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 - this bug appears to be a rehash of bug 13104 which was Fixed in October 2011 so I propose closing this with a resolution of Duplicate. Comments: * LC-1 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0807.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0807.html - The 28-May-2012 reply by Takeshi Yoshino notes this is a Chrome bug and not a spec bug. The 1-June-2012 reply by Simon Pieters indicates the Protocol spec needs to be updated. As such, I don't think any changes are needed for v1 of the spec. * LC-2 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html - This is an editorial bug and is already captured in Bug 12510. Ideally, this bug would be fixed before the v1 CR branch is created. However, if Hixie can't fix it before then and if no one else creates an acceptable patch for Hixie, I don't support blocking the v1 CR for this. Please send all comments by June 28. -Thanks, AB
Re: [websockets] Seeking comments on moving back to CR; deadline June 28
On 6/21/12 4:53 PM, ext Julian Reschke wrote: On 2012-06-21 16:28, Arthur Barstow wrote: ... http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html - This is an editorial bug and is already captured in Bug 12510. Ideally, this bug would be fixed before the v1 CR branch is created. However, if Hixie can't fix it before then and if no one else creates an acceptable patch for Hixie, I don't support blocking the v1 CR for this. ... I disagree that this is editorial. Yes I agree that editorial wasn't a particularly good characterization of bug 12510. Without proper references the spec simply is incomplete. Now that we have the URL spec in /TR/, it seems like that spec just needs to be added as a reference. -AB
