W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [webcomponents] HTML Parsing and the <template> element

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 7 Jun 2012 12:45:47 +0300
Message-ID: <CAJQvAuecPh1NUDmuBaxhn73houDEtmKzxgPAjUgGDzznTwi_Bw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Ian Hickson <ian@hixie.ch>, Rafael Weinstein <rafaelw@google.com>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Erik Arvidsson <arv@google.com>, Yehuda Katz <wycats@gmail.com>
On Wed, Jun 6, 2012 at 7:13 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> A call like "document.querySelectorAll('p')" doesn't *want* to get the
> <p> inside the template.

I think it's backwards to assume that querySelectorAll() works a
particular way and that's that's not what authors want and to change
the DOM in response.

There are various solutions that don't involve drastic changes to the
correspondence between the markup and the DOM, for example:

* Invoking querySelectorAll() on a wrapper element that's known not to
be a parent of the templates on the page.

* Using a selector that fails to match elements whose ancestor chain
contains a template element.

* Introducing an API querySelectorNonTemplate(). (Don't say "All" if
you don't mean *all*).

Even though XML has fallen out of favor, I think violations of the DOM
Consistency principle and features that don't work with the XHTML
serialization should be considered huge red flags indicating faulty

Henri Sivonen
Received on Thursday, 7 June 2012 09:46:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC