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

On Tue, Jun 12, 2012 at 12:14 AM, Rafael Weinstein <rafaelw@google.com> wrote:
> 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.

Arguments that correspondence between the source and the DOM are a
matter of opinion in the HTML case is the sort of slippery slope I'm
worried about. After all, in theory, we could make the parsing
algorithm output whatever data structure. If we make an exception
here, I expect that we'll see more proposals that will involve the
parser generating non-traditional DOM structures in order to
accommodate supposed API benefits at the expense of the old
DOM-assuming stuff working generically.

In the XML case, the correspondence between the source and the DOM is
not a matter of opinion. At least not at present. It seems that the
template spec is not willing to change that. Why? Why doesn't the same
answer apply to HTML?

I think we shouldn't violate the DOM Consistency Design Principle and
make templates have wormholes to another document when parsed from
text/html but have normal children when parsed from
application/xhtml+xml. That sort of route will lead to having to
implement template inertness twice and one of the solutions will be
one that's supposedly being avoided by the proposed design for HTML.

> 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

I'm arguing that these axes should be coupled the way they are now and
have always been. (And if you want them decoupled, the decoupling
should be done e.g. using selectors that specifically prohibit
templates in the parent chain of the selected node or using APIs that
aren't low-level tree accessors like firstChild, childNodes and
getElementById().)

For better or worse, the DOM is a data structure that represents the
markup and then has some higher-level-feature sugaring. It's not a
data structure whose shape is dictated by the higher-level features.
The DOM is so fundamental to the platform that I think the bar for
changing its nature should be very high. Certainly higher than one
vendor wishing to proceed with the feature that they've come up with.
Certainly not for a feature that could be implemented without breaking
the traditional model with relative ease (making inertness check walk
the parent chain [or propagate an equivalent flag down for O(1) read]
and rooting selector queries differently or using *:not(template)).

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 15 June 2012 11:34:48 UTC