Re: [webcomponents]: Re-imagining shadow root as Element

I'm already on the record with A, but I have a question about 'lossiness'.

With my web developer hat on, I wonder why I can't say:

<div id="foo">
  <shadowroot>
    shadow stuff
  </shadowroot>

  light stuff

</div>


and then have the value of #foo.innerHTML still be

  <shadowroot>
     shadow stuff
  </shadowroot>

  lightstuff

I understand that for DOM, there is a wormhole there and the reality of
what this means is new and frightening; but as a developer it seems to be
perfectly fine as a mental model.

We web devs like to grossly oversimplify things. :)

Scott

On Mon, Mar 18, 2013 at 1:53 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

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