Re: Shadow DOM and Fallback contents for images

On Oct 17, 2013, at 10:57 PM, Hayato Ito <hayato@chromium.org> wrote:

> 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.

Could you elaborate?

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

Could you summarize what you've discussed?  I can't figure out which slide I need to be looking at or what kinds of discussions took place there.

> 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