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

FWIW (and I'm not sure if this is good or bad) it would be consistent
with the <template> element if

-<shadowroot> serialized by default with innerHTML
-<shadowroot>, when parsed is lifted and pushed onto the parent
element's shadowroot stack
-appendChild(shadowroot) doesn't throw, but doesn't do what you
probably want (e.g. <shadowroot> is simply display:none if not
attached to a host). (I imagine there would be imperative API on
element, so that the correct imperative operation was to directly push
a new shadowroot() onto an element, rather than using appendChild.

Of course, if serialization round-tripping is non-lossy, this raises
the question about implicit shadow roots (i.e. the element is
registered and *creates* its shadowroots whenever it is created).

On Mon, Mar 18, 2013 at 2:38 PM, Scott Miles <sjmiles@google.com> wrote:
> 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<
>>>
>>>
>>
>

Received on Monday, 18 March 2013 21:59:38 UTC