Re: Shadow DOM and Fallback contents for images
The text in shadows are select-able, and it behaves kind of like iframes as Ryosuke mentioned. I'm not sure if these are clear from the current draft, but points are: - Users can select a part of the shadow tree. - If selected range is in a shadow tree, it isn't accessible (in API sense) outside the shadow. For one outside the shadow, that is document.getSelection(), the selection is represented as a range which selects the shadow host. Inside shadow, that is ShadowRoot.getSelection(), the selection points the node inside the shadow. This is how encapsulation works with Shadow DOM. It's just about API. The UA knows what part of the text is selected. Thus things like clipboards should work as expected. - The selection cannot cross the shadow boundary. Both ends of the selection should be in a same tree. I think this restriction is mainly for simplicity. Does this make sense? On Mon, Oct 14, 2013 at 1:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote: Hi, I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. That being said, it might be a good exercise to think about feasibility to implement img-like custom element which supports alternate text. 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . The caret just skips the alt-text. I think we generally consider that a bug. I think this is a desirable behavior since the img element is atomic. I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. Note that this part is about selection, not editing. I don't see any reason to treat the alt text different from any other text. I.e. that the user can select character-by-character by default, but that this can be overridden by the author if desired. If I'm not mistaken, how alternative text is presented is up to UA vendors. Given that, I don't think we should mandate one way or another with respect to this behavior. A more important question is what happens to selection inside a shadow DOM created by the author. 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content This is same as 1) above. The caret skips the alt-text. I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. Selection and editing are related but different. Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable Ugh, my text here is gibberish :) I think I intended to say: It is fine to enable the author to opt out of making the shadow content selectable, but the default should be that it is selectable. I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an atomic unit outside of it. Sounds like we should change the spec. Unless we have a good reason to treat selection as atomic? One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries. e.g. what should UA copy if selection ends points are in two different shadow trees. Requiring each selection end to be in the same shadow tree solves this problem. Again, most selections are not related to editing. I think that if we made all text inside shadow content only selectable as a whole, that would make shadow content a second class citizen in the page. The result would be that authors actively avoid putting text inside shadow content since the user experience would be so surprising. As a user, I'm always annoyed
Re: [gamepad] Seeking status and plans
On 10/10/13 2:12 PM, ext Ted Mielczarek wrote: 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. Thanks for this update Ted. Scott - please let us know if you have any additional status to share. Since 21388 is now Resolved/Fixed, based on what you say above it seems like the next step should be to have a 1-week pre-LC call for comments. Then, assuming no major issues are raised, I would start a CfC to publish a LCWD. However, I noticed 4 open bugs [Bugs]. What is the plan for these (f.ex. are they deferred to the next version)? One reason groups publish a LCWD is to use it as a signal that broader review of the spec is desired, and in this case, perhaps we can ask Marcos to help us reach out to the developer community he mentioned in [Dev]. -Thanks, ArtB [Dev] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0181.html -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388
Re: [gamepad] Seeking status and plans
On Tuesday, October 15, 2013 at 12:47 PM, Arthur Barstow wrote: One reason groups publish a LCWD is to use it as a signal that broader review of the spec is desired, and in this case, perhaps we can ask Marcos to help us reach out to the developer community he mentioned in [Dev]. I've pinged the developer, as he works for Moz. I can reach out to a few other devs too. If anyone knows folks working with this API, please let me know.
Re: [gamepad] Seeking status and plans
On 10/14/2013 3:34 PM, Marcos Caceres wrote: Hi All, The Gamepad API was briefly discussed at the LXJS conference. See: http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s It seems at least one developer is very unhappy with it. Have we received any other feedback from developers about it? Has any effort been made to reach out to other developers to get feedback? Thanks for the pointer. I watched that portion of the video and it's not very constructive feedback. I'll reach out to him (considering he's a coworker) and see if I can find out more specifics. We heard from quite a few developers while implementing the first draft of the API and they were overwhelmingly in favor of the current design. I haven't heard much in the way of feedback from developers actually testing the implementation we've shipped, so it's possible there are issues with it in practice. I'd definitely like to hear more we declare things finished. -Ted
Re: Shadow DOM and Fallback contents for images
On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote: Hi, I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. That being said, it might be a good exercise to think about feasibility to implement img-like custom element which supports alternate text. 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . The caret just skips the alt-text. I think we generally consider that a bug. I think this is a desirable behavior since the img element is atomic. I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. Note that this part is about selection, not editing. I don't see any reason to treat the alt text different from any other text. I.e. that the user can select character-by-character by default, but that this can be overridden by the author if desired. If I'm not mistaken, how alternative text is presented is up to UA vendors. Given that, I don't think we should mandate one way or another with respect to this behavior. A more important question is what happens to selection inside a shadow DOM created by the author. 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content This is same as 1) above. The caret skips the alt-text. I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. Selection and editing are related but different. Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable Ugh, my text here is gibberish :) I think I intended to say: It is fine to enable the author to opt out of making the shadow content selectable, but the default should be that it is selectable. I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an atomic unit outside of it. Sounds like we should change the spec. Unless we have a good reason to treat selection as atomic? One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries. e.g. what should UA copy if selection ends points are in two different shadow trees. Requiring each selection end to be in the same shadow tree solves this problem. Again, most selections are not related to editing. As far as I know, the most common use case of selecting anything on a Web page is copying it to somewhere else. I think that if we made all text inside shadow content only selectable as a whole, that would make shadow content a second class citizen in the page. The result would be that authors actively avoid putting text inside shadow content since the user experience would be so surprising. What are concrete examples of components for which users have to select text across the shadow boundary? - R. Niwa
Re: [gamepad] Seeking status and plans
On Tuesday, October 15, 2013 at 4:01 PM, Ted Mielczarek wrote: On 10/14/2013 3:34 PM, Marcos Caceres wrote: Hi All, The Gamepad API was briefly discussed at the LXJS conference. See: http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s It seems at least one developer is very unhappy with it. Have we received any other feedback from developers about it? Has any effort been made to reach out to other developers to get feedback? Thanks for the pointer. I watched that portion of the video and it's not very constructive feedback. I'll reach out to him (considering he's a coworker) and see if I can find out more specifics. We heard from quite a few developers while implementing the first draft of the API and they were overwhelmingly in favor of the current design. I haven't heard much in the way of feedback from developers actually testing the implementation we've shipped, so it's possible there are issues with it in practice. I'd definitely like to hear more we declare things finished. Ok, great. Let me know if I can do anything to help. -- Marcos Caceres