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

You should report this issue and your previous issue ("HTML5 is broken: 
<menuitem> causes infinite loop")
in Bugzilla.  The WHATWG HTML spec makes it easy.

--Peter

-----Original Message----- 
From: Michael Day
Sent: Monday, May 13, 2013 10:36 PM
To: whatwg@whatwg.org
Subject: [whatwg] Spec ambiguity and Firefox bug for newlines following and

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

Received on Tuesday, 14 May 2013 03:20:50 UTC