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

On Wed, Jun 6, 2012 at 3:50 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson <ian@hixie.ch> wrote:
>> On Wed, 4 Apr 2012, Rafael Weinstein wrote:
>>> On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>>> >
>>> > Perhaps lost among other updates was the fact that I've gotten the
>>> > first draft of HTML Templates spec out:
>>> >
>>> > http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
>>>
>>> I think the task previously was to show how dramatic the changes to the
>>> parser would need to be. Talking to Dimitri, it sounds to me like they
>>> turned out to be less "open-heart-surgery" and more "quick outpatient
>>> procedure". Adam, Hixie, Henri, how do you guys feel about the
>>> invasiveness of the parser changes that Dimitri has turned out here?
>>
>> I think it's more or less ok, but it has the problem that it doesn't give
>> a way to reset the insertion mode again while inside a <template>.
>
> I still think that breaking the old correspondence between markup and
> the DOM and shrugging the XML side off is a big mistake. Why would it
> be substantially harder to check inertness by walking the parent chain
> (which normally won't be excessively long) as opposed to checking a
> flag on the owner document?
>
> I strongly believe that this template contents should be children of
> the template element in the DOM instead of being behind a special
> wormhole to another document while parsing and serializing as if the
> special wormhole wasn't there.

This has pretty bad usability pitfalls.

A template like this:

<template>
  <p>Stamp out copies of me!</p>
</template>

...is morally equivalent to this:

<script type="text/template">
  <p>Stamp out copies of me!</p>
</script>

Which is to say, neither of them actually represent page content.
They represent templates of such, which will be  used to produce
actual page content.

A call like "document.querySelectorAll('p')" doesn't *want* to get the
<p> inside the template.  It'll be doing processing on paragraphs in
the page, real paragraph filled with content.  Similarly with class
selectors, or other things of similar nature.  An id selector probably
*does* want to grab the template element, but using ids inside of a
template is a bad idea anyway, since it will produce multiple elements
with the same id.

The only way to avoid this kind of matching is either to only link in
templates externally, expect all authors to qualify their selectors
sufficiently to never include a template element, or somehow hide the
contents from selectors applied to the main document.

I think the first is bad, I doubt anyone would reasonably think the
second would happen, and so the third is necessary.  I think the
current plan (to stash the contents of a <template> into a document
fragment) is a decent way to accomplish this.  Another alternative is
to simply state that they don't match selectors with a scope rooted
higher than their <template>.

~TJ

Received on Wednesday, 6 June 2012 16:14:39 UTC