Re: Shadow DOM and Fallback contents for images

Talking over an example might help...

----
<div>
    "Hello "
    <span>
        #shadowroot
            "Shadow"
    </span>
    " World"
</div>
----

This renders text "Hello Shadow World".

In my understanding, following patterns of selections are allowed:

A. "H[ell]o Shadow World" - selection stays outside shadow
B. "Hello S[had]ow world" - selection stays inside shadow
C. "H[ello Shadow Worl]d" - selection stays outside shadow, but its range
contains a node with shadow.

This is not allowed:

D. "H[ello Shado]w World" - selection spans outside to inside.

What unclear for me is:

- For case of C, should we consider "Shadow" being selected? Naively
thinking yes, but the implication isn't that clear.

- Should we have a way to forbid B to ensure the selection atomicity?
Probably yes, but I don't think we have one. The spec could clarify this
point. My feeling is that this is tangential to Shadow DOM and is more
about generic "selection atomicity" concept. It could be covered by a CSS
property for example.




On Thu, Oct 17, 2013 at 1:25 PM, Jonas Sicking <jonas@sicking.cc> wrote:

>
> On Oct 16, 2013 8:04 PM, "Ryosuke Niwa" <rniwa@apple.com> wrote:
> >
> > On Oct 16, 2013, at 5:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >
> > > On Tue, Oct 15, 2013 at 12:04 PM, Ryosuke Niwa <rniwa@apple.com>
> wrote:
> > >> On Oct 13, 2013, at 9: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.
> > >>
> > >> 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"?
>
> What if the text "Note" was longer? Is there ever a use case for selecting
> part of a word? If not, why does all browsers allow it?
>
> > As Hajime noted, users can select text as long as both ends of
> selections are in the same shadow tree.
>
> That is not what Hajime said.
>
> / Jonas
>



-- 
morrita