Re: Fallout of non-encapsulated shadow trees

Hi Anne,
Thank you for attending the 'Selection on Shadow DOM' session at BlinkOn.

Let me add a link to the slides we used at BlinkOn here:
https://docs.google.com/a/google.com/presentation/d/19Y6iLC7haWVHUDC1JOLfMj_AmT94rncEXxlUGWSQeFI/edit


On Thu, May 15, 2014 at 3:17 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> I'm still trying to grasp the philosophy behind shadow trees.
> Sometimes it's explained as "exposing the primitives" but the more I
> learn (rather slowly, this time at BlinkOn) the more it looks like a
> bunch of new primitives.
>
> We cannot explain <input> still, but since we allow going inside the
> shadow tree we now see the need for a composed tree walker (a way to
> iterate over a tree including its non-encapsulated interleaved shadow
> trees). In addition we see the need for a composed range of sorts, so
> selection across boundaries makes sense. Neither of these are really
> needed to explain bits of the existing platform.
>
>
Good point. I think we need an additional idea to explain the behavior of
<input> elements.

That would be a huge win for us if we could explain all semantics of
<input> elements by using the terminology and capabilities provided by Web
Components. As of now, I'd have to say that there is a still gap between
them.

Although this is a rough idea, but I am feeling that we should make custom
elements have a capability of responding to a 'copy' message or something
like so that they can control which *text* (or in other formats) should be
returned if they are selected atomically. However, this idea is too
immature to explain further.

If the author of custom elements doesn't need to control that, the default
behavior, which we explained in the session and will try to experiment,
might be enough.

I guess yosin@ or other guys who are woking on Selection and Editing might
have another better idea.


-- 
Hayato