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

On Mon, Jun 11, 2012 at 3:13 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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 think looking at this as whether we are "breaking the correspondance
between source and DOM" may not be helpful -- because it's likely to
be a matter of opinion. I'd like to suggest that we look at more
precise issues.

There are several axes of "presence" for elements WRT to a Document:

-serialization: do the elements appear in the serialization of the
Document, as delivered to the client and if the client re-serializes
via innerHTML, etc...
-DOM traversal: do the elements appear via traversing the document's
childNodes hierarchy
-querySelector*, get*by*, etc: are the element's returned via various
document-level query mechanisms
-CSS: are the element's considered for matching any present or future
document-level selectors

The goal of the <template> element is this: the page author would like
a declarative mechanism to author DOM fragments which are not in use
as of page construction, but are readily available to be used when
needed. Further, the author would like to be able to declare the
fragments inline, at the location in the document where they should be
placed, if & when they are needed.

Thus, template require that its contents be "present" for only
serialization, and not for DOM traversal, querySelector*/etc..., or
CSS.

Also, it may be helpful to think about this in terms of classical
object systems. Currently we only have instances. What we need is a
classes. Native app windowing systems don't force you to create an
instance of every window or dialog that your app may ever need and
place it off screen until it's needed. They allow for the notion of
declaring what the window or dialog will be and delay creating any UI
resources (HWNDs, buttons, drag targets, etc..) until the app creates
an instance.

>
> 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
> hsivonen@iki.fi
> http://hsivonen.iki.fi/

Received on Monday, 11 June 2012 21:15:42 UTC