Re: Shadow DOM and Fallback contents for images

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