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

I thought of another tack. I should have made it clear that I wasn't so
much making a proposal as trying to suggest the nature of 'shadow-dom'
works without lossiness when considered part of outerHTML. The notion
itself doesn't seem to me to be particularly worthy of controversy, so I
suspect the issue is around notation.

As a strawman, pretend we defined a 'shadowroot' attribute, like this:

    <div shadowroot="Decoration --><content></content><-- Decoration">
      Light DOM
    </div>

Treated this way, there is no confusion about inner and outerHTML, and
there is no lossiness when serializing. A <video> tag, e.g.,  has no
'shadowroot' attribute on it (unless user adds one) so there is no
confusion about intrinsic and extrinsic shadow-roots.

Given the strawman, then I could reframe Dimitri's idea as: the shadowroot
attribute sucks for ergonomics, what if we just use a syntax where we
(cheat and) mark up the shadowroot as if it were a child node.

If we decide that's a bad idea, the so be it, but I suggest that's a
separate argument from my claim that there can be a clean lossless mental
model for shadowroot markup.


On Wed, Apr 10, 2013 at 2:04 PM, Scott Miles <sjmiles@google.com> wrote:

> Well ok, that's unfortunate, I do wish you gave me more than "no, that's
> bad". Here are a couple more thoughts.
>
> 1. I suspect the loss-of-symmetry occurs because Dimitri has defined an
> element that has markup as if it is a child, but it's not actually a child.
> This is the 'wormhole' effect.
>
> 2. My proposal is consistent and functional. I haven't heard any other
> proposal that isn't lossy or damaging to the standard methods of working
> (not saying there isn't one, I just haven't seen any outline of it yet).
>
> Scott
>
>
> On Wed, Apr 10, 2013 at 1:53 PM, Erik Arvidsson <arv@chromium.org> wrote:
>
>> For the record I'm opposed to what you are proposoing. I don't like that
>> you lose the symmetry between innerHTML and outerHTML.
>>
>>
>> On Wed, Apr 10, 2013 at 4:34 PM, Scott Miles <sjmiles@google.com> wrote:
>>
>>> I made an attempt to describe how these things can be non-lossy here:
>>> https://gist.github.com/sjmiles/5358120
>>>
>>>
>>> On Wed, Apr 10, 2013 at 12:19 PM, Scott Miles <sjmiles@google.com>wrote:
>>>
>>>> input/video would have intrinsic Shadow DOM, so it would not ever be
>>>> part of outerHTML.
>>>>
>>>> I don't have a precise way to differentiate intrinsic Shadow DOM from
>>>> non-intrinsic Shadow DOM, but my rule of thumb is this: 'node.outerHTML'
>>>> should produce markup that parses back into 'node' (assuming all
>>>> dependencies exist).
>>>>
>>>>
>>>> On Wed, Apr 10, 2013 at 12:15 PM, Erik Arvidsson <arv@chromium.org>wrote:
>>>>
>>>>> Once again, how would this work for input/video?
>>>>>
>>>>> Are you suggesting that `createShadowRoot` behaves different than when
>>>>> you create the shadow root using markup?
>>>>>
>>>>>
>>>>> On Wed, Apr 10, 2013 at 3:11 PM, Scott Miles <sjmiles@google.com>wrote:
>>>>>
>>>>>> I think we all agree that node.innerHTML should not reveal node's
>>>>>> ShadowDOM, ever.
>>>>>>
>>>>>> What I am arguing is that, if we have <shadow-root> element that you
>>>>>> can use to install shadow DOM into an arbitrary node, like this:
>>>>>>
>>>>>> <div>
>>>>>>   <shadow-root>
>>>>>>     Decoration --> <content></content> <-- Decoration
>>>>>>   <shadow-root>
>>>>>>   Light DOM
>>>>>> </div>
>>>>>>
>>>>>>
>>>>>> Then, as we agree, innerHTML is
>>>>>>
>>>>>> LightDOM
>>>>>>
>>>>>>
>>>>>> but outerHTML would be
>>>>>>
>>>>>> <div>
>>>>>>   <shadow-root>
>>>>>>     Decoration --> <content></content> <-- Decoration
>>>>>>   <shadow-root>
>>>>>>   Light DOM
>>>>>> </div>
>>>>>>
>>>>>>
>>>>>> I'm suggesting this outerHTML only for 'non-intrinsic' shadow DOM, by
>>>>>> which I mean Shadow DOM that would never exist on a node unless you hadn't
>>>>>> specifically put it there (as opposed to Shadow DOM intrinsic to a
>>>>>> particular element type).
>>>>>>
>>>>>> With this inner/outer rule, all serialization cases I can think of
>>>>>> work in a sane fashion, no lossiness.
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 10, 2013 at 12:05 PM, Erik Arvidsson <arv@chromium.org>wrote:
>>>>>>
>>>>>>> Maybe I'm missing something but we clearly don't want to include
>>>>>>> <shadowroot> in the general innerHTML getter case. If I implement
>>>>>>> input[type=range] using custom elements + shadow DOM I don't want innerHTML
>>>>>>> to show the internal guts.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 10, 2013 at 2:30 PM, Scott Miles <sjmiles@google.com>wrote:
>>>>>>>
>>>>>>>> I don't see any reason why my document markup for some div should
>>>>>>>> not be serializable back to how I wrote it via innerHTML. That seems just
>>>>>>>> plain bad.
>>>>>>>>
>>>>>>>> I hope you can take a look at what I'm saying about outerHTML. I
>>>>>>>> believe at least the concept there solves all cases.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 10, 2013 at 11:27 AM, Brian Kardell <bkardell@gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 10, 2013 1:24 PM, "Scott Miles" <sjmiles@google.com> wrote:
>>>>>>>>> >
>>>>>>>>> > So, what you quoted are thoughts I already deprecated mysefl in
>>>>>>>>> this thread. :)
>>>>>>>>> >
>>>>>>>>> > If you read a bit further, see that  I realized that
>>>>>>>>> <shadow-root> is really part of the 'outer html' of the node and not the
>>>>>>>>> inner html.
>>>>>>>>> >
>>>>>>>>> Yeah sorry, connectivity issue prevented me from seeing those
>>>>>>>>> until after i sent i guess.
>>>>>>>>>
>>>>>>>>> > >> I think that is actually a feature, not a detriment and
>>>>>>>>> easily explainable.
>>>>>>>>> >
>>>>>>>>> > What is actually a feature? You mean that the shadow root is
>>>>>>>>> invisible to innerHTML?
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> > Yes, that's true. But without some special handling of Shadow
>>>>>>>>> DOM you get into trouble when you start using innerHTML to serialize DOM
>>>>>>>>> into HTML and transfer content from A to B. Or even from A back to itself.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> I think Dimiti's implication iii is actually intuitive - that is
>>>>>>>>> what I am saying... I do think that round-tripping via innerHTML would be
>>>>>>>>> lossy of declarative markup used to create the instances inside the
>>>>>>>>> shadow... to get that it feels like you'd need something else which I think
>>>>>>>>> he also provided/mentioned.
>>>>>>>>>
>>>>>>>>> Maybe I'm alone on this, but it's just sort of how I expected it
>>>>>>>>> to work all along... Already, roundtripping can differ from the original
>>>>>>>>> source, If you aren't careful this can bite you in the hind-quarters but it
>>>>>>>>> is actually sensible.  Maybe I need to think about this a little deeper,
>>>>>>>>> but I see nothing at this stage to make me think that the proposal and
>>>>>>>>> implications are problematic.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> erik
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> erik
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> erik
>>
>>
>>
>