[webcomponents]: Re-imagining shadow root as Element

Last Friday, still energized after the productive Mozilla/Google
meeting, a few of us (cc'd) dug into Shadow DOM. And boy, did that go
south quickly! But let's start from the top.

We puzzled over the the similarity of two seemingly disconnected problems:

a) ShadowRoot is a DocumentFragment and not an Element, and
b) there is no declarative way to specify shadow trees.

The former is well-known (see
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg356).

The latter came into view very early as a philosophical problem
(provide declarative syntax for new imperative APIs) and much later as
a practical problem: many modern apps use a "freeze-drying"
performance technique where they load "as-rendered" HTML content of a
page on immediately (so that the user sees content immediately), and
only later re-hydrate it with script. With shadow DOM, the lack of
declarative syntax means that the content will not appear
"as-rendered" until the script starts running, thus ruining the whole
point of freeze-drying.

We intentionally stayed away from the arguments like "well, with
custom elements, all of this happens without script". We did this
precisely because we wanted to understand what "all of this happens"
actually means.

Trapped between these two problems, we caved in and birthed a new
element. Let's call it <shadowroot> (Second Annual Naming Contest
begins in 3.. 2.. ).

This element _is_ the ShadowRoot. It's deliciously strange. When you
do div.appendChild(document.createElement('shadowroot')), the DOM:

0) opens a magic wormhole to the land of rainbows and unicorns (aka
the Gates of Hell)
1) adds <shadowroot> at the top of div's shadow tree stack

This behavior has three implications:

i) You can now have detached ShadowRoots. This is mostly harmless. In
fact, being able to prepare ShadowRoot instances before adding them to
a host seems like a good thing.

ii) ShadowRoot never appears as a child of an element. This is desired
original behavior.

iii) Parsing HTML with <shadowroot> in it results in loss of data when
round-tripping. This is hard to swallow, but one can explain it as a
distinction between two trees: a document tree and a composed tree.
When you invoke innerHTML, you get a document tree. When you invoke
(yet to be invented) innerComposedHTML, you get composed tree.

Alternatively, we could just make appendChild/insertBefore/etc. throw
and make special rules for <shadowroot> in HTML parser.

Pros:

* The shadow root is now an Element with localName and defined DOM behavior
* There's now a way to declare shadow trees in HTML
* Just like DocumentFragment, neatly solves the problem of root being
inserted in a tree somewhere

Cons:

* We're messing with how appendChild/insertBefore work

What do you folks think?

A. This is brilliant, I love it
B. You have made your last mistake, RELEASE THE KRAKEN!
C. I tried reading this, but Firefly reruns were on
D. ___________________________

:DG<

Received on Monday, 18 March 2013 20:54:06 UTC