Re: Shadow DOM and Fallback contents for images

On Oct 17, 2013 6:48 PM, "Hajime Morrita" <morrita@google.com> wrote:
>
>
>
>
> On Fri, Oct 18, 2013 at 3:56 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, Oct 17, 2013 at 1:55 AM, Hajime Morrita <morrita@google.com>
wrote:
>> >
>> >
>> >
>> > On Thu, Oct 17, 2013 at 5:01 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> >>
>> >> On Oct 16, 2013, at 9:47 PM, Hajime Morrita <morrita@google.com>
wrote:
>> >>
>> >> D. "H[ello Shado]w World" - selection spans outside to inside.
>> >>
>> >>
>> >> Suppose we allowed this selection. Then how does one go about pasting
this
>> >> content elsewhere?
>> >>
>> >> Most likely, whatever other content editable area, mail client, or
some
>> >> random app (e.g. MS Word) into which the user is going to paste
wouldn’t
>> >> support shadow DOM and most certainly wouldn’t have the component the
>> >> original page happened to have.
>> >
>> >
>> > We have to define how Range.cloneContents() or extractContents() works
>> > against shadow-selecting range, assuming selection is built on top of
DOM
>> > Range. This doesn't seem that complicated. As cloned element drops its
>> > shadow, these range-generated nodes won't have shadow either.
>>
>> Oh, sounds like you are suggesting that we expand the Range API such
>> that it can have awareness of spanning parts of a shadow DOM tree.
>> While still keeping the existing endpoints "in the same root"?
>>
>> That like that idea!
>
>
> No, that isn't what I meant. I just want to make it explicit that Range
API works well with shadow trees.
> However it happened to be taken by you in some interesting way, and I'm
fine with this  ;-)
>
> So what does this mean?
>
> The "subranges" property exposes the selections of containing
ShadowRoots? That sounds reasonable.
>
> Although I don't think Blink supports this in short term because it only
has per-document selection and doesn't have per-tree ones,
> it is rather a lack of features which can be improved eventually than
something totally incompatible and hurting the Web.
>
> Let me confirm what we're talking about.
>
> 1. Each shadow tree has its own selection. Each selection spans nodes in
the owning tree only.
> 2. User initiated selection operation (like dragging) can operate
multiple selections in different trees seamlessly
>     as if it is single selection crossing boundaries.
> 3. Range and/or Selection API could expose sub-selections/sub-ranges of
containing trees.
>
> Going back to the example,
>
> > C. "H[ello Shadow Worl]d" - selection stays outside shadow, but its
range contains a node with shadow.
>
> This turns something like
>
> C2: "H[ello (Shadow) Worl]d" - There are two selections - "[]" for
outside tree and "()" for inside tree.
>
> And this this one
>
> > D. "H[ello Shado]w World" - selection spans outside to inside.
>
> turns
>
> D2: "H[ello] (Shado)w World"
>
> Is is correct?

Yes!

I think there are at least three ways we could expose these inner ranges:

A) Separate function in the selection API for getting "shadow ranges".
B) Extension to the Range object for getting sub-"shadow ranges".
C) Through the existing multi-range support in the selection API.

C has the advantage that no range or selection API changes are needed. But
has the downside that it makes it messy to associate which ranges are
subranges of other ranges.

B has the advantage that it works anywhere where Range objects are used.
But the downside is that it makes Ranges more complicated.

A has the advantage that it keeps Ranges simple.

I think I'm leaning towards B personally. I don't think the added
complexity to Range objects is a big deal. Anywhere where Ranges are used
you'd likely want to deal with shadow trees in one way or another.

/ Jonas