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

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?

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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 4 June 2012 21:42:34 UTC