RE: New tests submitted by Microsoft for WebApps specs
On Tuesday, September 13, 2011 6:27 PM, Adrian Bateman wrote: Today we shipped Microsoft Internet Explorer 10 Platform Preview 3 as part of the Windows 8 Developer Preview. Alongside this release, we have submitted interop tests for several WebApps specs for review by the working group: WebSockets API (101 tests/assertions) Changeset: http://dvcs.w3.org/hg/webapps/rev/6712344ae119 Tests: http://w3c- test.org/webapps/WebSockets/tests/submissions/Microsoft/ Indexed DB (87 tests/assertions) Changeset: http://dvcs.w3.org/hg/webapps/rev/62fbeaa2ed43 Tests: http://w3c-test.org/webapps/IndexedDB/tests/submissions/Microsoft/ WebWorkers (51 tests/assertions) Changeset: http://dvcs.w3.org/hg/webapps/rev/7b0ba70f69b6 Tests: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ Notes: * The tests all use the common test harness developed initially in the HTML WG and adopted by the WebApps WG in the test submission guidelines. * Since these are the first submitted tests for each of these specs, we created new folders for them in the webapps folder. * 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. * The Indexed DB tests include code to work around the current vendor prefixing. At some point we will need to remove this code from the official test suite but it makes running the tests simpler for now. * The WebSockets API tests require a running service. We are currently hosting the service on a Microsoft server (html5labs-interop.cloudapp.net). We are committed to working with the W3C systems team and this working group to host the service at the W3C when this is possible. FYI, the IndexedDB tests don't reflect the latest spec changes that have been made to the IDBFactory.open API to integrate the VERSION_CHANGE functionality. They will have to be updated in the future to deal with this change. Israel
Re: Joystick support
Hi All, As Scott knows, and as suggested by some responses to this thread, the members of the Web Events WG are interested in adding the Joystick API to its charter [1]. As such, my expectation is the process to formally update Web Event's charter to add this API will begin soon. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0041.html On 8/24/11 3:23 PM, ext Scott Graham wrote: Hello, I noticed that Mozilla has started to prototype support for Joystick events. There's some documentation on this effort https://wiki.mozilla.org/JoystickAPI as well as a prototype https://bugzilla.mozilla.org/show_bug.cgi?id=604039 I'm also interested in adding support for joysticks to Chromium and so would like to open the discussion up to a broader audience. Do others see this as a valuable API? Or have comments on the design? scott
Re: RfC: LCWD of Touch Events version 1; deadline October 11
On Tue, 13 Sep 2011 21:43:38 +0200, Charles Pritchard ch...@jumis.com wrote: As I understand it, Touch Events v. 1 is only attempting to codify what's already been introduced by WebKit, namely, by Apple, and followed-up by others. That's in contrast to the parallel development of v. 2, which does try take on new items. Except apparently its init***Event() method does not match WebKit: http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0054.html -- Anne van Kesteren http://annevankesteren.nl/
RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]
Hixie, Brian, Jonas, All, Since Brian sent the original e-mail [1], there has been some Bugzilla activity and there are now 5 open bugs for Web Sockets. It appears to me (and please correct me if I'm wrong) the .binaryType issue Jonas raised on the list [2] will not result in any spec changes. I agree 12510 and 13700 are editorial bugs and as such do not need to block LC. Re the other open bugs, Brian suggests: 13104 and 13984 should be closed; 13777 be addressed as outlined in the bug; 13990 (which is now marked as Resolved Invalid) also be addressed as indicated in the bug. Ideally, all open bugs should be closed before a LC is published. However, we can also use an LC now to gather input on the open bugs. Brian proposes an LC be published now with the spec as is. What do others think? -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1365.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html On 9/9/11 6:05 PM, ext Brian Raymor wrote: The IETF HyBi WG has moved beyond Last Call and has presented the WebSockets protocol to the IESG for approval: http://www.ietf.org/mail-archive/web/hybi/current/msg08640.html Now that the protocol is more stable, I think that the current WebSockets API is feature complete and meets the requirements for publishing a Last Call working draft to encourage broader review and feedback. Here is my review of the outstanding bugs (not closed, where resolution not Fixed). I recommend that the outstanding issues be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. 9973 - If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - This bug is a year old, likely out of date now, and from an anonymous contributor 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - This bug is from an anonymous contributor from 6 months ago. The API spec doesn't need to link to server implementations. 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong();//allow client to receive response of ping Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - It's not necessary to include API support for ping/pong. In addition, this bug has been inactive for two months. 13172 - The definition for [MessageEvent] is missing Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - It's been inactive for a month and MessageEvent is defined in the HTML5 Web Messaging specification. 13700 - W3C SotD of this document still mentions whatwg.org version of the WebSocket protocol which is out of date. New, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call 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. 13984 - Need a way to object detect which binary formats are supported before connecting New, Assigned to Ian Hickson MICROSOFT PROPOSAL: Close the bug. The original issue (binary support detection in Chrome) should be addressed in WebKit. The additional scenario (querying which binary types are supported) is not required in V1. 13990 - Need a spec for CloseEvent constructor New, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 14057 - In section The WebSocket interface when describing the operation of the WebSocket constructor, the following statement is made: Return a new WebSocket object, and continue these steps in the background (without blocking scripts). ... New, Assigned to Ian Hickson MICROSOFT PROPOSAL: Resolve the bug as duplicate (12510) and close. In addition, there is a new discussion on design changes for binary message support related to the original discussions in 12102 - WebSocket protocol update time: 1-Sep-2011 ; [WebSocket API] .binaryType ; by Jonas, reply by Hixie http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1199.html MICROSOFT PROPOSAL: We do not support the proposed changes. Our implementation experience has not indicated this requirement. We find that most developers use blobs when there is a need to consume data as resources addressed by a URI or to store data in Indexed DB. We have haven't heard of a need to
[Bug 14148] New: shouldn't WorkerLocation also have resolveURL?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14148 Summary: shouldn't WorkerLocation also have resolveURL? Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#wor kerlocation 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, sim...@opera.com, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html Multipage: http://www.whatwg.org/C#workerlocation Complete: http://www.whatwg.org/c#workerlocation Comment: shouldn't WorkerLocation also have resolveURL? Posted from: 85.227.155.223 by sim...@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.9.168 Version/11.51 -- 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 13104] Enable keepalive on WebSocket API
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13104 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #10 from Ian 'Hixie' Hickson i...@hixie.ch 2011-09-14 18:04:03 UTC --- I don't see why the scripts would have to have anything to do with this. The browser should just take care of this automatically. -- 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 13984] Need a way to object detect which binary formats are supported before connecting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13984 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WORKSFORME --- Comment #11 from Ian 'Hixie' Hickson i...@hixie.ch 2011-09-14 18:06:59 UTC --- The current state of matters is apparently just a Chrome bug, so there's nothing we can do in the spec to fix this today. Going forward, if we add a new binary type then we can add a way to detect for it then. In the meantime, in compliant browsers the code in comment 4 is sufficient. -- 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 14048] Suggestion of change in process for dispatch the event in Server-Sent Events
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14048 Per-Erik Brodin per-erik.bro...@ericsson.com changed: What|Removed |Added CC|public-html-wg-issue-tracki |per-erik.bro...@ericsson.co |n...@w3.org, |m, public-webapps@w3.org |public-h...@w3.org | Component|HTML5 spec (editor: Ian |Server-Sent Events (editor: |Hickson)|Ian Hickson) Platform|Macintosh |Other Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org OS/Version|MacOS X |other --- Comment #1 from Per-Erik Brodin per-erik.bro...@ericsson.com 2011-09-14 19:11:50 UTC --- If the data buffer is an empty string in step 1 it means that there were no data: lines and that's why we want to abort. If the data buffer contains only a line feed character in step 2 it means that there was exactly one data: line but it didn't have a value and thus a MessageEvent with an empty string as its data should be dispatched (similarly, two data: lines without values will result in event.data containing a single line feed character). -- 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: [editing] Using public-webapps for editing discussion
Since some related functionality was included (at one point) in the HTML5 spec, it seems like we should ask the HTML WG for feedback on Aryeh's email. Aryeh told me there are some related bugs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13423 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13425 Maciej, Sam, Ruby - do have a sense if the HTML WG has a (strong) opinion on Aryeh's question below? -Art Barstow On 9/13/11 4:27 PM, ext Aryeh Gregor wrote: For the last several months, I was working on a new specification, which I hosted on aryeh.name. Now we've created a new Community Group at the W3C to host it: http://aryeh.name/spec/editing/editing.html http://www.w3.org/community/editing/ Things are still being worked out, but one issue is what mailing list to use for discussion. I don't want to create new tiny mailing lists -- I think we should reuse some existing established list where the stakeholders are already present. Previously I was using the whatwg list, but as a token of good faith toward the W3C, I'd prefer to switch to public-webapps, even though my spec is not a WebApps WG deliverable. (If it ever does move to a REC track spec, though, which the Community Group process makes easy, it will undoubtedly be in the WebApps WG.) Does anyone object to using this list to discuss the editing spec?
Re: [editing] Using public-webapps for editing discussion
On 9/14/11 4:30 PM, Arthur Barstow wrote: Since some related functionality was included (at one point) in the HTML5 spec, it seems like we should ask the HTML WG for feedback on Aryeh's email. Aryeh told me there are some related bugs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13423 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13425 Maciej, Sam, Ruby - do have a sense if the HTML WG has a (strong) opinion on Aryeh's question below? -Art Barstow On 9/13/11 4:27 PM, ext Aryeh Gregor wrote: For the last several months, I was working on a new specification, which I hosted on aryeh.name. Now we've created a new Community Group at the W3C to host it: http://aryeh.name/spec/editing/editing.html http://www.w3.org/community/editing/ Things are still being worked out, but one issue is what mailing list to use for discussion. I don't want to create new tiny mailing lists -- I think we should reuse some existing established list where the stakeholders are already present. Previously I was using the whatwg list, but as a token of good faith toward the W3C, I'd prefer to switch to public-webapps, even though my spec is not a WebApps WG deliverable. (If it ever does move to a REC track spec, though, which the Community Group process makes easy, it will undoubtedly be in the WebApps WG.) Does anyone object to using this list to discuss the editing spec? I'm happy to see this spec continued on the webapps WG. I don't see Shelley Powers' objection being addressed. She has expressed concerns that the HTML Editing APIs have been taken out of W3C WGs and associated processes. Apple, Google and Microsoft representatives have vetoed rich text editing as a supported use case for public-canvas-api, the Google/WHATWG editing specification is now the -only- supported solution for developers to author editing environments. Because this is the only approved method of editing HTML content, and I've seen -no- controversy around the specification itself, I'd like Shelley Powers' position reconsidered by the editors. Were Apple, Google and Microsoft to loosen their position on rich text editing, such that authors can proceed with rich text editing that does not rely on this specification, I'd be less concerned. I don't think that'll happen for the next ~18 months. Aryeh, consider releasing more authority to the W3C process. The specification is fairly mature, I'm not seeing push-back on this spec, and I know that there are several voices which would better served through formal process. Also, try to get this onto the hg repositories, in the same style that DOM4 has been entered. It works well for maintaining your CC0/WHATWG labels while also providing the W3C with a publishable draft under their own restrictions. -Charles
