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

On Mon, Jun 4, 2012 at 2:42 PM, 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>.
> Consider the difference in how these would parse:
>
>   <template> <tbody> </tbody>                        <tr> </template>
>
>   <template> <tbody> </tbody> <template> </template> <tr> </template>
>
> We need a way to stay in the 'in table' mode. 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>.

> 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.

~TJ

Received on Monday, 4 June 2012 22:22:19 UTC