W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2012

Re: Support getElementById and other methods of ShadowRoot on DocumentFragment

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Sat, 30 Jun 2012 15:24:02 -0700
Message-ID: <CADh5Ky34bMbc0bSbiDBQAM1waaC8LfdgAxJaH1sqEv8zLdfzOw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Elliott Sprehn <esprehn@gmail.com>, www-dom <www-dom@w3.org>
On Fri, Jun 29, 2012 at 6:17 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>
> This seems like yet another reason to make the root of the shadow tree
> be an element rather than a DocumentFragment. In the component model
> spec we're likely going to be creating shadow trees by cloning
> <template> elements, so it seems to make a lot of sense to me to use
> that cloned <template> element as the shadow tree, rather than
> conceptually moving all the children over to this, arguably somewhat
> awkward, DocumentFragment subclass.

It's an interesting idea. From my perspective, ShadowRoot is nothing
like an element in a general sense: it has no tag name or attributes.
It has its fairly unique scoping requirements and events, and styling
boundaries. Making it a DocumentFragment-like thing has the advantage
of never worrying about accidentally detaching the shadow root from
its host by an errant DOM operation:

document.body.appendChild(someShadowRoot); // only moves its children

And it also explains how the template nodes enter that special world
of a separate scope:

shadowRoot.appendChild(someTemplateElement.content);

At this point, I just don't see how we can make it and the template
element be the same thing. However, I am happy to hear a good argument
for this. Merging HTMLTemplateElement and ShadowRoot is intriguing.

Can you maybe file a bug on this and post your thoughts on it? Handy
link here: http://goo.gl/KiaWc

>
> / Jonas
>
Received on Saturday, 30 June 2012 22:24:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 30 June 2012 22:24:39 GMT