- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Mar 2013 13:57:08 -0700
- To: Roland Steiner <rolandsteiner@google.com>
- Cc: Rafael Weinstein <rafaelw@google.com>, Scott Miles <sjmiles@google.com>, Dimitri Glazkov <dglazkov@google.com>, 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>, Ojan Vafai <ojan@google.com>, Alex Komoroske <komoroske@google.com>, Matthew McNulty <mmcnulty@google.com>, Ryosuke Niwa <rniwa@webkit.org>
On Tue, Mar 19, 2013 at 12:05 AM, Roland Steiner <rolandsteiner@google.com> wrote: > AFAICT this has several ramifications: > > .) Being an element, you now have a render box for each <shadowroot>, in > addition to the render box for the host element. That's not a requirement. We can define that the <shadowroot> element doesn't show up in the flattened tree. However allowing the shadowroot to appear in the flattened tree might have advantages. This is something that has been debated before. Also note that the CSSWG has discussed the possibility of introducing "display:content" which might be useful here. > .) Being an element, can a <shadowroot> can itself have a <shadowroot>?. > Contrast: > > <div> > <shadowroot>...</shadowroot> > <shadowroot>...</shadowroot> > > vs: > > <div> > <shadowroot> > <shadowroot> > > .) Similar to the above: can <content> and <shadow> have <shadowroot> > children? > > .) Behavior of a DocumentFragment being inserted into the document also > needs twizzling if it contains a <shadowroot>. All good points. I'm definitely concerned that allowing the <shadowroot> to appear in the markup causes more confusion than it's worth. I'm also not sure what problems that it solves over simply adding real children to the DOM. / Jonas
Received on Tuesday, 19 March 2013 20:58:10 UTC