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

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