On Oct 16, 2013, at 5:14 PM, Jonas Sicking <[email protected]> wrote: > 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.
In that case, the entire "Note" will be selected as an atomic unit. Is there a use case in which you want to select a part of "Note" and a part of "Text here"? As Hajime noted, users can select text as long as both ends of selections are in the same shadow tree. - R. Niwa
