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

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