W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Reading a start tag in "text" insertion mode

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 16 Aug 2013 03:24:13 +0000 (UTC)
To: "Mohammad Al Houssami (Alumni)" <mha53@mail.aub.edu>
Message-ID: <alpine.DEB.2.00.1308160321450.5474@ps20323.dreamhostps.com>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
On Thu, 15 Aug 2013, Mohammad Al Houssami (Alumni) wrote:
>
> I am building a parser incrementally by sets of elements (and not all at 
> the same time ) so while debugging I noticed that the text insertion 
> mode does not have a "anything else" branch. Lets assume my input is the 
> following: <title><head> The title start tag will lead us to the text 
> insertion mode. And then what should happen ?  The specifications don't 
> deal with this case as there is nothing that says what should happen in 
> this case... I think I am missing something here ?

The generic RCDATA element parsing algorithm puts the tokenizer into the 
RCDATA state, from which the only possible tokens are text tokens, end tag 
tokens, and end-of-file tokens. These are the same tokens that the "text" 
mode handles.

So you parse a <title> start tag token, you go into "text" mode, then you 
get six character tokens, which get inserted into the <title> element, 
then you get an EOF token, and you unwind the parser and end.

What token are you getting that isn't handled?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 16 August 2013 03:24:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC