On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa <[email protected]> wrote: > On Oct 11, 2013, at 10:52 PM, Jonas Sicking <[email protected]> wrote: > >> On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa <[email protected]> wrote: >>> On Oct 7, 2013, at 1:38 PM, Jonas Sicking <[email protected]> wrote: >>> >>> On Oct 7, 2013 6:56 AM, "Hajime Morrita" <[email protected]> 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 when I can't interact with text normally. / Jonas
