On Tue, Oct 15, 2013 at 12:04 PM, Ryosuke Niwa <[email protected]> wrote: > On Oct 13, 2013, at 9:19 PM, Jonas Sicking <[email protected]> wrote: > >> 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. > > As far as I know, the most common use case of selecting anything on a Web > page is copying it to somewhere else.
Sure. But copying is also different from 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. > > What are concrete examples of components for which users have to select text > across the shadow boundary? Any component which contains text in the shadow content. For example a component that generates the +-- Note --------- | Text here +------------------ That appears in many specs. The "Note" text here would likely appear in the shadow content. / Jonas
