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

Sorry if I'm clobbering this thread, I promise to stop after this, but I
solved my own mental model. Namely, I decide to treat <shadowroot> like
outerHTML.

If I define (pseudo):

<div id=A>
  <shadowroot>
     <span id=B>
        <shadowroot>
           ...

The A.innerHTML == "<span id=B><shadowroot>..."

I don't see A's shadowroot, because it's really part of it's outer-ness.
It's part of what makes A, it's not part of A's content.

Now I can send A's innerHTML to B with no problem. Or roundtrip A's content
with no problem.

I realize I've broken several standard laws, but in any event it seems
consistent to itself.



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

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