Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time
On Wed, Oct 9, 2013 at 10:55 PM, Jonas Sicking jo...@sicking.cc wrote: Maybe it's time to reconsider if ShadowRoot should be an element rather than a DocumentFragment again? Either that or let it have its own node type if it's going to be incompatible with DocumentFragment in terms of behavior. Alternatively we could add more hidden state such as host which we added for template, but that's not exactly great. -- http://annevankesteren.nl/
[Bug 23422] Adding a method to deliver editing-related events to a DOM element
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23422 Takayoshi Kochi ko...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Takayoshi Kochi ko...@google.com --- Added enable/disableEditingEvents() at https://dvcs.w3.org/hg/ime-api/rev/10a3d6ec9336 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [streams-api] Seeking status and plans
I think the plan should be more here now: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html Regards Aymeric Le 02/10/2013 18:32, Arthur Barstow a écrit : Hi Feras, If any of the data for the Streams API spec in [PubStatus] is not accurate, please provide corrections. Also, please see the following thread and let us know your plan for this spec http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0599.html. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
[Bug 23479] New: File Constructor and Blob Constructor should have same signature
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23479 Bug ID: 23479 Summary: File Constructor and Blob Constructor should have same signature Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: a...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org File and Blob constructors currently have different signatures. Feedback in off-list email was: Shouldn't the File constructor have the same signature as the Blob constructor, but also allow a 'name' parameter to be passed in the dictionary. Possibly even throwing if no name is provided. Having the Blob constructor and the File constructor be so different when they are really doing the same thing seems surprising. And forcing authors to create a temporary Blob just so that they can create a File seems wasteful. Please consider this implementation feedback. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [streams-api] Seeking status and plans
On 10/10/13 6:26 AM, ext Aymeric Vitte wrote: I think the plan should be more here now: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html There are indeed at least two specs here: [1] Feras' https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm [2] Takeshi's http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html Among the Qs I have here are ... * What is the implementation status of these specs? * Would it make sense or be useful to merge or layer the specs, or should we only work on one of these specs? * Who favors WebApps stopping work on [1] and starting work on [2]? * Would anyone object to WebApps stopped working on [1]? If yes, are you willing to help lead the effort to move Feras' spec forward? * Takeshi - I noticed you are not a member of WebApps. Are you willing to work on [2] within the context of WebApps? -Thanks, AB Regards Aymeric Le 02/10/2013 18:32, Arthur Barstow a écrit : Hi Feras, If any of the data for the Streams API spec in [PubStatus] is not accurate, please provide corrections. Also, please see the following thread and let us know your plan for this spec http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0599.html. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
RE: [streams-api] Seeking status and plans
Apologies for the delay, I had broken one of my mail rules and didn't see this initially. Asymeric is correct - there have been a few threads and revisions. A more up-to-date version is the one Asymeric linked - http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html The above version incorporates both promises and streams and is a more refined version of Streams. From other threads on Stream, it became apparent that there were a few pieces of the current Streams API ED that were designed around older paradigms and needed refining to be better aligned with current APIs. I think it does not make sense to have two different specs, and instead have a combined one that we move forward. I can work with Takeshi on getting his version incorporated into the Streams ED, which we can then move forward with. Thanks, Feras Date: Thu, 10 Oct 2013 09:32:20 -0400 From: art.bars...@nokia.com To: vitteayme...@gmail.com; feras.mou...@hotmail.com; tyosh...@google.com CC: public-webapps@w3.org Subject: Re: [streams-api] Seeking status and plans On 10/10/13 6:26 AM, ext Aymeric Vitte wrote: I think the plan should be more here now: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html There are indeed at least two specs here: [1] Feras' https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm [2] Takeshi's http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html Among the Qs I have here are ... * What is the implementation status of these specs? * Would it make sense or be useful to merge or layer the specs, or should we only work on one of these specs? * Who favors WebApps stopping work on [1] and starting work on [2]? * Would anyone object to WebApps stopped working on [1]? If yes, are you willing to help lead the effort to move Feras' spec forward? * Takeshi - I noticed you are not a member of WebApps. Are you willing to work on [2] within the context of WebApps? -Thanks, AB Regards Aymeric Le 02/10/2013 18:32, Arthur Barstow a écrit : Hi Feras, If any of the data for the Streams API spec in [PubStatus] is not accurate, please provide corrections. Also, please see the following thread and let us know your plan for this spec http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0599.html. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
Problem in the Entry interface description (filesystem)
Hello, In the description of the Entry interface located here: http://dev.w3.org/2009/dap/file-system/pub/FileSystem/#the-entry-interface I noticed the following sentence: An abstract interface representing entries in a file system, each of which may be a Filehttp://dev.w3.org/2009/dap/file-system/pub/FileSystem/#dfn-file or DirectoryEntryhttp://dev.w3.org/2009/dap/file-system/pub/FileSystem/#idl-def-DirectoryEntry., with a link leading to the File interface. Obviously, the File interface is not a descendant of the Entry interface, but FileEntry is, as can been easily checked on both descriptions: http://dev.w3.org/2006/webapi/FileAPI/#dfn-file http://dev.w3.org/2009/dap/file-system/pub/FileSystem/#the-fileentry-interface File is a Blob. I hope it helps, but I'm sure I'm not the first to notice. Regards, Alexis Dufrenoy
Re: Problem in the Entry interface description (filesystem)
Greetings Alexis, The specification actively edited now is: http://w3c.github.io/filesystem-api/Overview.html -- A* On Oct 10, 2013, at 10:00 AM, alexis dufrenoy wrote: Hello, In the description of the Entry interface located here: http://dev.w3.org/2009/dap/file-system/pub/FileSystem/#the-entry-interface I noticed the following sentence: An abstract interface representing entries in a file system, each of which may be a File or DirectoryEntry., with a link leading to the File interface. Obviously, the File interface is not a descendant of the Entry interface, but FileEntry is, as can been easily checked on both descriptions: http://dev.w3.org/2006/webapi/FileAPI/#dfn-file http://dev.w3.org/2009/dap/file-system/pub/FileSystem/#the-fileentry-interface File is a Blob. I hope it helps, but I'm sure I'm not the first to notice. Regards, Alexis Dufrenoy
Re: [gamepad] Seeking status and plans
On 10/2/2013 12:31 PM, Arthur Barstow wrote: Hi Ted, Scott, If any of the data for the Gamepad spec in [PubStatus] is not accurate, please provide corrections. 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. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus Hi Art, Thanks for the nudge! My work on the spec (and the Firefox implementation) fell by the wayside for many months, but I found some time to work on my implementation recently. We (Mozilla) are shipping a very-close-to-spec implementation in Nightly builds, and it's available behind a preference in our current release (Firefox 24). I'd actually like to ship our implementation in release soon, I just have a few minor implementation bugs (with significant impact) to fix as well as one possible breaking spec change[1]. With those in order I'd be pretty happy to ship. We'd be shipping unprefixed, as is our new policy. It's my understanding that Google has been shipping a prefixed implementation that's also pretty close to the spec for some time now, but that Scott suffers from the same Gamepad is not really my full-time job problem that I do. He'd be more equipped to talk about this than I am, certainly. In terms of feature-completeness I think the spec is basically done. Aside from that one breaking change I'd like to make I don't think there's anything else we want to address right now that couldn't be done in a future release of the spec. We've wanted to keep the scope small from the beginning and I think we did okay. It definitely needs some more work (mostly polishing of the text, fixing the existing bugs), but we could certainly get out a new WD with the most recent text. -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388
Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time
On Thu, Oct 10, 2013 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 9, 2013 at 10:55 PM, Jonas Sicking jo...@sicking.cc wrote: Maybe it's time to reconsider if ShadowRoot should be an element rather than a DocumentFragment again? Actually, that's the first thing I said to Elliott when I saw his mail. Then he turned to me and said: remember all the serialization crap we sifted through to finally reach the conclusion that ShadowRoot as element is a bad idea? At which it all paged in ( http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0356.html), and I convulsed on the floor from the standards-discussion equivalent of the brain freeze. Either that or let it have its own node type if it's going to be incompatible with DocumentFragment in terms of behavior. Alternatively we could add more hidden state such as host which we added for template, but that's not exactly great. There's something to that. ShadowRoot is more like Document than a DocumentFragment. :DG
