[whatwg] Spec ambiguity and Firefox bug for newlines following <pre> and <textarea>

[Michael Day]

Hi,

If a newline character token follows a <pre> or <textarea> start tag, it 
is supposed to be ignored as an authoring convenience.

However, what if a NULL character token gets in the way? Consider these 
two cases, where "NULL" represents a literal U+0000 character:

<pre>NULL&#xA;

<textarea>NULL&#xA;

For textarea, the tokenizer will be in the rcdata state, which generates 
replacement character (U+FFFD) tokens for each NULL. So the newline will 
not be the next token following the start tag, and should not be 
ignored. Chrome gets this right, Firefox get this wrong, and displays 
the replacement character *and* strips the newline.

For pre, the tokenizer will be in the data state, which emits NULL 
characters as-is. The NULL character token is then ignored by the "in 
body" insertion mode. Does this mean it doesn't count as the next token 
after the start tag? Both browsers seem to think so.

In general, the concept of "next token" is not well defined; in fact I 
don't think it is ever explicitly defined in the spec. If a token is 
ignored, is it still the next token?

Since this concept is only used for the specific case of ignoring 
newlines at the start of <pre>, <listing>, and <textarea>, perhaps a 
better mechanism could be found to describe how it should work.

Best regards,

Michael

-- 
Prince: Print with CSS!
http://www.princexml.com