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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]>wrote: >>>> >>>>> >>>>> On Apr 10, 2013 1:24 PM, "Scott Miles" <[email protected]> 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 > > >
