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