Re: Shadow DOM and Fallback contents for images

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