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

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.


> > 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 22:50:46 UTC