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

On Mon, Jun 4, 2012 at 3:50 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 4 Jun 2012, Tab Atkins Jr. wrote:
>> >
>> > [...] We could do this by having the parser insert a fake node into
>> > the stack of open elements just for this purpose, I think. That is,
>> > when switching insertion mode in response to the first start tag
>> > inside the template insertion mode, also insert something into the
>> > stack so that the next time we reset, we reset correctly. We need to
>> > do that in a way that doesn't match end tags, though... Maybe we have
>> > to introduce a new kind of thing we push on the stack, which doesn't
>> > get matched by anything but the reset algorithm?
>>
>> A "template context"?  Sets the context for the rest of parsing, and
>> gets popped by a </template> returning to its matching <template>.
>
> Yeah, something like that could work. We'd have to make sure we defined it
> as happening when </template> was popped, but if we force that to only
> ever happen when we see a literal </template> (which the proposal seems
> to, though I haven't verified that) that might work ok.

So the most straight-forward way I saw to approach this (implemented
here: https://bugs.webkit.org/show_bug.cgi?id=86031) was to make the
"context element" become a stack of "context elements".

The idea is that each level of nested <template> opens a new fragment
parsing context, with a coinciding context element which is initially
unknown.

E.g. from you example above:

<template> <tbody> </tbody> <template> </template> <tr> </template>

-When the first <template> element is encountered, the parser switches
into ImpliedContext insertion mode and pushes an unknown element on
the stack of context elements which is associated with the current
<template> element
-When the <tbody> is encountered, it replaces the unknown element with
a <table> context element
-When the inner <template> is encountered, it pushes another unknown
context element onto the stack of context elements
-When the inner </template> is encountered, the <template> is popped
from the stack of open elements and the unknown element is popped from
the stack of context elements. The reset insertion mode appropriately
algorithm is run -- which now examines the "current" context element
(associated with the first <template> which is the current element)
which is <table> and sets the insertion mode to InTable.

>
>
>> > The proposal here doesn't support SVG (or MathML, but SVG seems more
>> > important for <template>). Short of hard-coding a list of SVG
>> > elements, which seems really bad for forwards compatibility, I don't
>> > have a good proposal for dealing with this. I suppose we could go back
>> > to having an attribute on <template>, this time setting the context at
>> > a more coarse level of just HTML vs SVG vs MathML; that's more likely
>> > to be understood by authors than what I was suggesting before ("in
>> > table body", etc).
>>
>> It doesn't require any more hard-coding than HTML needs in order to
>> create proper elements instead of HTMLUnknownElements.  You have to know
>> the list of valid HTML elements to produce a proper DOM, and update that
>> as you add more, even if the rest of parser is unchanged. This is the
>> same thing, except it needs the list of valid SVG and MathML elements.
>
> I agree that it's the same. I don't think having a hard-coded list of HTML
> elements is a good thing either, it's got the same forward-compatibility
> problems. Unfortunately in the case of the existing lists we had no choice
> because UAs already had them. Here, we have a choice.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 4 June 2012 23:37:21 UTC