Re: Overlap between StreamReader and FileReader
Formatted and published my latest proposal at github after incorporating Aymeric's multi-dest idea. http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html On Sat, Sep 28, 2013 at 11:45 AM, Kenneth Russell k...@google.com wrote: This looks nice. It looks like it should already handle the flow control issues mentioned earlier in the thread, simply by performing the read on demand, though reporting the result asynchronously. Thanks, Kenneth for reviewing.
[admin] DOM4 is now a deliverable of the HTMLWG
FYI, as Philippe announced a few days ago, the HTMLWG's new charter [1] includes DOM4: [[ http://lists.w3.org/Archives/Public/public-html-admin/2013Sep/0129.html The new charter includes: * An Dual License experiment for some specifications: http://www.w3.org/2013/09/html-charter.html#documentlicense * The addition of the DOM4 specification ]] Re the rationale for moving this spec to HTMLWG, the following (unfortunately, Member-only) information was provided to Members: [[ https://lists.w3.org/Archives/Member/w3c-ac-members/2013JulSep/0049.html The Director made one additional change to this charter as a result of discussion: to move the DOM4 specification from the charter of the Web Applications Working Group to the HTML Working Group. The decision is the result of several considerations: * The DOM4 specification has not been updated by the Web Applications Working Group since December 2012. * The HTML5 specification has a strong dependency on DOM4, so to complete HTML5 on time, we need DOM4 to advance. * At the June AC Meeting [2] we sought input on which specifications could usefully move to the HTML Working Group as part of this experiment. As a result of conversations, it became clear that DOM4 was the primary candidate. * The Chairs of both the HTML Working Group and the Web Applications Working Group have indicated that they support this move. ]] Philippe, Robin, Yves - please clarify if the dual license will apply to the HTMLWG's DOM4 spec and the plan for the spec's Editor(s). My expectation is that www-dom will continue to be used for DOM4 so please confirm that too. -Thanks, AB [1] http://www.w3.org/2013/09/html-charter.html
[admin] Oct 28 is deadline to start a CfC to publish before TPAC 2013
Hi Editors, All, Since the W3C will not publish any documents during TPAC week, if you want to publish a document before TPAC, October 28 is the last day to start a CfC to publish. Please note, however, a lot of groups typically publish right before TPAC, so if you want to publish before TPAC, I highly recommend the CfC be started before October 28 (preferably much earlier). -Thanks, AB
Re: [admin] DOM4 is now a deliverable of the HTMLWG
On Thu, 2013-10-03 at 09:34 -0400, Arthur Barstow wrote: FYI, as Philippe announced a few days ago, the HTMLWG's new charter [1] includes DOM4: [[ http://lists.w3.org/Archives/Public/public-html-admin/2013Sep/0129.html The new charter includes: * An Dual License experiment for some specifications: http://www.w3.org/2013/09/html-charter.html#documentlicense * The addition of the DOM4 specification ]] Re the rationale for moving this spec to HTMLWG, the following (unfortunately, Member-only) information was provided to Members: [[ https://lists.w3.org/Archives/Member/w3c-ac-members/2013JulSep/0049.html The Director made one additional change to this charter as a result of discussion: to move the DOM4 specification from the charter of the Web Applications Working Group to the HTML Working Group. The decision is the result of several considerations: * The DOM4 specification has not been updated by the Web Applications Working Group since December 2012. * The HTML5 specification has a strong dependency on DOM4, so to complete HTML5 on time, we need DOM4 to advance. * At the June AC Meeting [2] we sought input on which specifications could usefully move to the HTML Working Group as part of this experiment. As a result of conversations, it became clear that DOM4 was the primary candidate. * The Chairs of both the HTML Working Group and the Web Applications Working Group have indicated that they support this move. ]] Philippe, Robin, Yves - please clarify if the dual license will apply to the HTMLWG's DOM4 spec and the plan for the spec's Editor(s). Regarding the Document license, the charter should be enough I hope. See section 8 Document License of the HTML Charter: [[ The DOM4 specification is also a candidate for the Dual License. ]] http://www.w3.org/2013/09/html-charter.html Regarding the plan for spec editor, my current understanding is that the HTML Chairs will send a call for editors in the HTML Working Group. My expectation is that www-dom will continue to be used for DOM4 so please confirm that too. This is also my expectation. Philippe
Re: [quota-api] Seeking status and plans
On 10/2/13 9:37 PM, ext Kinuko Yasuda wrote: I'm planning to update the FPWD to use some new syntax like Promises, and Mozilla is showing agreement and interest to implement the new draft per discussion on public-webapps (http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0368.html). The new draft can be found on my github, and am planning to update the WD on w3c site before TPAC. https://github.com/kinu/quota-api/blob/master/draft.md Thanks for the update Kinuko. When you say update the WD on w3c site, do you mean update [ED] or do you mean you would like to publish a new Working Draft as a Technical Report (TR) i.e. update [WD]? If the later, please note October 28 is the deadline to start a CfC to publish a new WD (as a TR). -Thanks, ArtB [ED] https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html [WD] http://www.w3.org/TR/quota-api/ -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
Re: [pointerlock] Seeking status and plans
On Wed, Oct 2, 2013 at 9:30 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi Vincent, If any of the data for the Pointer Lock spec in [PubStatus] is not accurate, please provide corrections. Pointer Lock is no longer blocked on mozilla security review. Firefox stable now implements behavior similar to Chrome when not in full screen. I will be updating the spec and closing https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 soon. Also, if you have any new information re your plans for the spec - last published 29-May-2012 - or the spec's status with respect to being feature complete, implementation status, etc. please let us know. I will update the specification to include the constraints now implemented in Firefox and Chrome, but will leave wording allowing user agents to have additional constraints as appropriate for future contexts. I will also clarify the spec by adding reference to onpointerlockchange and onpointerlock error, and specifying that pointer lock should not be exited upon a transition in window state between fullscreen, maximized or restored. At that point I would like to publish another working draft of the specification, possibly a Last Call Working Draft. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/**webapps/wiki/PubStatushttp://www.w3.org/2008/webapps/wiki/PubStatus
Re: [pointerlock] Seeking status and plans
On 10/3/13 12:14 PM, ext Vincent Scheib wrote: Pointer Lock is no longer blocked on mozilla security review. Firefox stable now implements behavior similar to Chrome when not in full screen. I will be updating the spec and closing https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 soon. Thanks for the update Vincent (I updated PubStatus accordingly). I will update the specification to include the constraints now implemented in Firefox and Chrome, but will leave wording allowing user agents to have additional constraints as appropriate for future contexts. I will also clarify the spec by adding reference to onpointerlockchange and onpointerlock error, and specifying that pointer lock should not be exited upon a transition in window state between fullscreen, maximized or restored. At that point I would like to publish another working draft of the specification, possibly a Last Call Working Draft. OK, please let me know when the ED is updated and then we can discuss the WD vs. LCWD question. (See the following re the Purpose and Entrance Criteria for LCWD http://www.w3.org/2005/10/Process-20051014/tr.html#last-call.) -Thanks, ArtB
RE: [D3E] Seeking status and plan
Yes, we are working through the last of our issues and hope to be ready to issue a publication request. We've made many improvements since the last publication, and with UI Events waiting in the wings, and multiple UAs starting to implement we think we may at last be approaching CR. We'll know more in the next couple of weeks. Thanks! -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, October 2, 2013 9:29 AM To: Travis Leithead; Gary Kacmarcik (Кошмарчик) Cc: public-webapps Subject: [D3E] Seeking status and plan Hi Travis and Gary, If any of the data for D3E in [PubStatus] is not accurate, please provide corrections. Also, please provide a short update re the plan and time-frame to publish a new LCWD. [Hint: it would be really nice to get a new LCWD of D3E published as soon as possible ;-)] -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
RE: [uievents] Seeking status and plans
I think we're spending most of our energy on DOM3Events at the moment, so I don't know how much this spec has changed. Gary should chime-in, but if there's material changes, it would be nice to re-publish it before TPAC. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, October 2, 2013 9:32 AM To: Gary Kacmarcik (Кошмарчик); Travis Leithead Cc: public-webapps Subject: [uievents] Seeking status and plans Hi Gary, Travis, If any of the data for the UI Events spec in [PubStatus] is not accurate, please provide corrections. Also, if you have any new information re your plans for the spec - last published 25-July-2013 - or the spec's status with respect to being feature complete, implementation status, etc., please let us know. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
Re: [selectors-api2] Seeking status and plans
On 2013-10-03 17:51, Arthur Barstow wrote: I'm not sure what you mean re draft of DOM here. Do you mean integrating the selectors API into WebApps' DOM4 [ED]; or do you mean the HTMLWG should start working towards a TR publication of DOM4 that includes the selectors API; or something else? I was referring to this http://www.w3.org/TR/dom/ I didn't realise that was being taken over by the HTMLWG, as I haven't been actively following spec stuff for a while as I've been busy with other work. I guess they'll take care of it, then, so never mind. -- Lachlan Hunt http://lachy.id.au/
Testing Pointer Lock
Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. - A user gesture is required to lock when not in fullscreen. - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. I'm considering starting some pointer lock tests with testharness.js. The only solution I see is to provide instructions in many tests for manual actions and observations. I appreciate any best practice suggestions, or pointers to other specifications with similar challenges. So far I see geolocation tests provide manual instructions.
Re: [quota-api] Seeking status and plans
On Thu, Oct 3, 2013 at 11:13 PM, Arthur Barstow art.bars...@nokia.comwrote: On 10/2/13 9:37 PM, ext Kinuko Yasuda wrote: I'm planning to update the FPWD to use some new syntax like Promises, and Mozilla is showing agreement and interest to implement the new draft per discussion on public-webapps (http://lists.w3.org/Archives/** Public/public-webapps/**2013JulSep/0368.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0368.html ). The new draft can be found on my github, and am planning to update the WD on w3c site before TPAC. https://github.com/kinu/quota-**api/blob/master/draft.mdhttps://github.com/kinu/quota-api/blob/master/draft.md Thanks for the update Kinuko. When you say update the WD on w3c site, do you mean update [ED] or do you mean you would like to publish a new Working Draft as a Technical Report (TR) i.e. update [WD]? If the later, please note October 28 is the deadline to start a CfC to publish a new WD (as a TR). Sorry I meant to update [ED]. I'd also like to see if I could make it a new WD, though the timing might be a bit tight. (Thanks for reminding the deadline) -Thanks, ArtB [ED] https://dvcs.w3.org/hg/quota/**raw-file/tip/Overview.htmlhttps://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html [WD] http://www.w3.org/TR/quota-**api/ http://www.w3.org/TR/quota-api/ -Thanks, ArtB [PubStatus] http://www.w3.org/2008/**webapps/wiki/PubStatushttp://www.w3.org/2008/webapps/wiki/PubStatus
Re: Testing Pointer Lock
On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib sch...@google.com wrote: Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. - A user gesture is required to lock when not in fullscreen. - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. I'm considering starting some pointer lock tests with testharness.js. The only solution I see is to provide instructions in many tests for manual actions and observations. I appreciate any best practice suggestions, or pointers to other specifications with similar challenges. So far I see geolocation tests provide manual instructions. Longdesc also has manual tests. The ones at http://github.com/chaals/longdesc-tests are looking like they will be accepted as actual tests. There is *1* automated test, which I haven't tried to put it into testharness yet. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Testing Pointer Lock
On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote: On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib sch...@google.com (mailto:sch...@google.com) wrote: Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. That might be tested using a reftest[1]. - A user gesture is required to lock when not in fullscreen. That might be tested using a WebDriver test (we haven't agreed on a way to write or run those yet). - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) This might also be feasible using WebDriver. - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. That could be automated using WebDriver. I'm considering starting some pointer lock tests with testharness.js. The only solution I see is to provide instructions in many tests for manual actions and observations. If there's interest on your side to explore the WebDriver-based option, I'm happy to start a discussion on how those tests should be written in the relevant channel (public-test-in...@w3.org), but that really depends on what your main goal with this effort is (move the spec along the REC track, or improve interop) and what your timeline's like. If you want to ship the spec quickly, going the manual route with testharness.js is probably your best option. You'll always be able to revisit later (you could even do both in parallel). --tobie --- [1]: http://testthewebforward.org/docs/reftests.html
