W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

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

From: Scott Miles <sjmiles@google.com>
Date: Mon, 18 Mar 2013 14:08:14 -0700
Message-ID: <CAHbmOLZv5hzFybVvJeA0GfrWJb_KjWeFg4g=VYb+A=hQbq9uUQ@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@google.com>, Adam Klein <adamk@google.com>, Steve Orvell <sorvell@google.com>, Hajime Morrita <morrita@google.com>, Rafael Weinstein <rafaelw@google.com>, Ojan Vafai <ojan@google.com>, Alex Komoroske <komoroske@google.com>, Matthew McNulty <mmcnulty@google.com>
Ok, well obviously, there are times when you don't want the <shadowroot> to
be in innerHTML, so I was correct that I was grossly over simplifying. I
guess this is where the second kind of innHTML accessor comes in. Sorry!

It's still A though. :)


On Mon, Mar 18, 2013 at 2:05 PM, Scott Miles <sjmiles@google.com> wrote:

> 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<
>>
>
>
Received on Monday, 18 March 2013 21:08:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT