W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Generating implied end tags upon </table> "in table" (detailed review of parsing algorithm)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 6 Jul 2007 12:34:54 +0300
Message-Id: <309E773C-07CE-4646-A9AD-CC23F9467657@iki.fi>
To: "public-html@w3.org WG" <public-html@w3.org>

(This is part of my detailed review the parsing algorithm.)

The spec says:
> An end tag whose tag name is "table"
>
>     If the stack of open elements does not have an element in table  
> scope with the same tag name as the token, this is a parse error.  
> Ignore the token. (fragment case)
>
>     Otherwise:
>
>     Generate implied end tags.
>
>     Now, if the current node is not a table element, then this is a  
> parse error.
>
>     Pop elements from this stack until a table element has been  
> popped from the stack.
>
>     Reset the insertion mode appropriately.

Why have the steps
>     Generate implied end tags.
>
>     Now, if the current node is not a table element, then this is a  
> parse error.
there at all?

If there are implied end tags to generate, it means that the stack  
has foster-parented stuff pushed onto it. The foster parenting  
triggered an error when the nodes got onto the stack. Do we really  
care about how gracefully they come off the stack?

I suggest striking the steps
>     Generate implied end tags.
>
>     Now, if the current node is not a table element, then this is a  
> parse error.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Friday, 6 July 2007 09:35:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:46 UTC