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: Mon, 11 Jun 2012 15:13:31 +0300
Message-ID: <CAJQvAuckPgGYvRntLErFD20gyDXdOwyNnK0TF8A7nDzVb81UQg@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 Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Just saying that querySelector/All doesn't match elements in a
> template (unless the scope is inside the template already) would work,
> but it means that we have to make sure that all future similar APIs
> also pay attention to this.

I think that would be preferable compared to opening the Pandora's box
of breaking the correspondence between the markup of the DOM tree.
Besides, we'd need something like this for the XML case anyway if the
position the spec takes is that it shies away from changing the
correspondence between XML source and the DOM.

In general, I think the willingness to break the correspondence
between the source and the DOM should be the same for both HTML and
XML serializations. If you believe that it's not legitimate to break
the correspondence between XML source and the DOM, it would be logical
to treat radical changes to the correspondence between HTML source and
the DOM as equally suspect.

I worry that if we take the position here that it's okay to change
your correspondence between the source and the DOM in order to
optimize for a real or perceived need, it will open the floodgates for
all sorts of arguments that we can make the parser generate whatever
data structures regardless of what the input looks like and we'll end
up in a world of pain. It's bad enough that isindex is a parser macro.

Henri Sivonen
Received on Monday, 11 June 2012 12:14:56 UTC

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