- From: Scott Miles <sjmiles@google.com>
- Date: Mon, 18 Mar 2013 14:08:14 -0700
- To: Dimitri Glazkov <dglazkov@google.com>
- Cc: public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@google.com>, Adam Klein <adamk@google.com>, Steve Orvell <sorvell@google.com>, Hajime Morrita <morrita@google.com>, Rafael Weinstein <rafaelw@google.com>, Ojan Vafai <ojan@google.com>, Alex Komoroske <komoroske@google.com>, Matthew McNulty <mmcnulty@google.com>
- Message-ID: <CAHbmOLZv5hzFybVvJeA0GfrWJb_KjWeFg4g=VYb+A=hQbq9uUQ@mail.gmail.com>
Ok, well obviously, there are times when you don't want the <shadowroot> to be in innerHTML, so I was correct that I was grossly over simplifying. I guess this is where the second kind of innHTML accessor comes in. Sorry! It's still A though. :) On Mon, Mar 18, 2013 at 2:05 PM, Scott Miles <sjmiles@google.com> wrote: > I'm already on the record with A, but I have a question about 'lossiness'. > > With my web developer hat on, I wonder why I can't say: > > <div id="foo"> > <shadowroot> > shadow stuff > </shadowroot> > > light stuff > > </div> > > > and then have the value of #foo.innerHTML still be > > <shadowroot> > shadow stuff > </shadowroot> > > lightstuff > > I understand that for DOM, there is a wormhole there and the reality of > what this means is new and frightening; but as a developer it seems to be > perfectly fine as a mental model. > > We web devs like to grossly oversimplify things. :) > > Scott > > On Mon, Mar 18, 2013 at 1:53 PM, Dimitri Glazkov <dglazkov@google.com>wrote: > >> Last Friday, still energized after the productive Mozilla/Google >> meeting, a few of us (cc'd) dug into Shadow DOM. And boy, did that go >> south quickly! But let's start from the top. >> >> We puzzled over the the similarity of two seemingly disconnected problems: >> >> a) ShadowRoot is a DocumentFragment and not an Element, and >> b) there is no declarative way to specify shadow trees. >> >> The former is well-known (see >> >> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg356 >> ). >> >> The latter came into view very early as a philosophical problem >> (provide declarative syntax for new imperative APIs) and much later as >> a practical problem: many modern apps use a "freeze-drying" >> performance technique where they load "as-rendered" HTML content of a >> page on immediately (so that the user sees content immediately), and >> only later re-hydrate it with script. With shadow DOM, the lack of >> declarative syntax means that the content will not appear >> "as-rendered" until the script starts running, thus ruining the whole >> point of freeze-drying. >> >> We intentionally stayed away from the arguments like "well, with >> custom elements, all of this happens without script". We did this >> precisely because we wanted to understand what "all of this happens" >> actually means. >> >> Trapped between these two problems, we caved in and birthed a new >> element. Let's call it <shadowroot> (Second Annual Naming Contest >> begins in 3.. 2.. ). >> >> This element _is_ the ShadowRoot. It's deliciously strange. When you >> do div.appendChild(document.createElement('shadowroot')), the DOM: >> >> 0) opens a magic wormhole to the land of rainbows and unicorns (aka >> the Gates of Hell) >> 1) adds <shadowroot> at the top of div's shadow tree stack >> >> This behavior has three implications: >> >> i) You can now have detached ShadowRoots. This is mostly harmless. In >> fact, being able to prepare ShadowRoot instances before adding them to >> a host seems like a good thing. >> >> ii) ShadowRoot never appears as a child of an element. This is desired >> original behavior. >> >> iii) Parsing HTML with <shadowroot> in it results in loss of data when >> round-tripping. This is hard to swallow, but one can explain it as a >> distinction between two trees: a document tree and a composed tree. >> When you invoke innerHTML, you get a document tree. When you invoke >> (yet to be invented) innerComposedHTML, you get composed tree. >> >> Alternatively, we could just make appendChild/insertBefore/etc. throw >> and make special rules for <shadowroot> in HTML parser. >> >> Pros: >> >> * The shadow root is now an Element with localName and defined DOM >> behavior >> * There's now a way to declare shadow trees in HTML >> * Just like DocumentFragment, neatly solves the problem of root being >> inserted in a tree somewhere >> >> Cons: >> >> * We're messing with how appendChild/insertBefore work >> >> What do you folks think? >> >> A. This is brilliant, I love it >> B. You have made your last mistake, RELEASE THE KRAKEN! >> C. I tried reading this, but Firefly reruns were on >> D. ___________________________ >> >> :DG< >> > >
Received on Monday, 18 March 2013 21:08:43 UTC