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

AFAICT this has several ramifications:

.) Being an element, you now have a render box for each <shadowroot>, in
addition to the render box for the host element.
Those may be beneficial or just superfluous by themselves, but they may
result in cases where there is a gap between the host's box and the
<shadowroot>'s box. We had rich text editing bugs because of such
scenarios, e.g., when the user clicked within such a gap.

.) Being an element, can a <shadowroot> can itself have a <shadowroot>?.
Contrast:

    <div>
        <shadowroot>...</shadowroot>
        <shadowroot>...</shadowroot>

    vs:

    <div>
        <shadowroot>
            <shadowroot>

.) Similar to the above: can <content> and <shadow> have <shadowroot>
children?

.) Behavior of a DocumentFragment being inserted into the document also
needs twizzling if it contains a <shadowroot>.


- Roland




On Tue, Mar 19, 2013 at 6:59 AM, Rafael Weinstein <rafaelw@google.com>wrote:

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