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
