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 <jonas@sicking.cc> wrote:

> On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> > On Oct 11, 2013, at 10:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >
> >> On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >>> On Oct 7, 2013, at 1:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>>
> >>> On Oct 7, 2013 6:56 AM, "Hajime Morrita" <morrita@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 when I can't interact with text normally.
>
> / Jonas
>



-- 
morrita