Re: Shadow DOM and Fallback contents for images

I am aware that there are issues related to selections regarding Shadow DOM
both in the spec and the implementation.
But I don't have a clear answer to resolve that and couldn't satisfy users.
This is one of the toughest issues, I think.

Some of us have already started to tackle this issue. We had a similar
topic on blinkon conference (http://bit.ly/blinkon).

CC-ing yosin@, hoping he has the latest idea.



On Fri, Oct 18, 2013 at 2:24 PM, Hajime Morrita <morrita@google.com> wrote:

> B looks fine. We don't have to rush into the API addition though. The API
> is just a shortcut of a tree traversal and easy to polyfill. It won't too
> late to design this after hearing some concrete usecases.
>
> Also, we need to extend this rough idea to take reprojection (<content>
> and <shadow>) into account. I hope projection-proficient people like
> Dimitri and Hayato help to do that.
>
>
> On Fri, Oct 18, 2013 at 1:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>>
>> 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
>>
>
>
>
> --
> morrita
>



-- 
Hayato