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 <sjmi...@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 <sjmi...@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 <a...@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 <sjmi...@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 <a...@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 <sjmi...@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 >>>>>> <bkard...@gmail.com>wrote: >>>>>> >>>>>>> >>>>>>> On Apr 10, 2013 1:24 PM, "Scott Miles" <sjmi...@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
