- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Thu, 25 Aug 2011 09:08:13 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: olli@pettay.fi, public-webapps <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Aug 25, 2011 at 8:35 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: >> One thing missing is some kind of declarative way to define >> shadow trees, similar to XBL1's <content>. >> >> It would be rather strange if one needs to explicitly construct >> shadow tree after the element is created. > > I know we plan to add a declarative syntax similar to XBL, but the > scripted syntax gets into the details better, so it's better to focus > on that first. It's also easy, when you start from a declarative > solution, to accidentally build in magic that's hard to replicate > imperatively. Starting from imperative has similar risks, but I think > they're easier to manage. Splitting into a fresh thread. I also think being able to use markup to declare shadow DOM trees is pretty cool, however I would strongly recommend coming up with a use case that clearly illustrates the need for it. Now that we have a fairly rigorous framework around this spec development (http://wiki.whatwg.org/wiki/Component_Model_Methodology), we should follow it. So we have to answer this question first: Why and to Whom is it important to have such a feature? One notion I was toying with is productivity, since declarative markup should be easier to read. Another possible point is consistency: we can build DOM trees using markup in a document, why not in shadow DOM? I don't think performance quite cuts it anymore, since JS engines have gotten to the point where I doubt you'll see a significant difference between declarative and imperative tree instantiation. :DG<
Received on Thursday, 25 August 2011 16:08:39 UTC