- From: Erik Arvidsson <arv@chromium.org>
- Date: Tue, 16 Apr 2013 12:21:05 -0400
- To: Dominic Cooney <dominicc@google.com>
- Cc: Scott Miles <sjmiles@google.com>, Brian Kardell <bkardell@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Alex Komoroske <komoroske@google.com>, Ojan Vafai <ojan@google.com>, Matthew McNulty <mmcnulty@google.com>, Hajime Morrita <morrita@google.com>, Elliott Sprehn <esprehn@google.com>, public-webapps <public-webapps@w3.org>, Adam Klein <adamk@google.com>, Steve Orvell <sorvell@google.com>, Dimitri Glazkov <dglazkov@google.com>
On Mon, Apr 15, 2013 at 11:05 PM, Dominic Cooney <dominicc@google.com> wrote: > On Thu, Apr 11, 2013 at 5:53 AM, 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. > > > Sorry for replying to such a cold thread. > > Could you elaborate on what symmetry is being broken here? outerHTML is > innerHTML with a prefix and a suffix. In this proposal the prefix includes > <shadow-root>. What problems are likely to result from that? outerHTML has always been start tag + innerHTML + end tag. Now it would become start tag + shadow dom + innerHTML + end tag. I remember when IE used to include those pesky <?import> directives and the confusion it caused. Lets not make a similar mistake. > Dominic > >> >> 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 >> >> > > > > -- -- erik
Received on Tuesday, 16 April 2013 16:21:56 UTC