[Bug 10800] Reconsider form feed (U+000C) conformance

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10800

--- Comment #5 from Henri Sivonen <hsivonen@iki.fi> 2010-10-04 13:21:08 UTC ---
(In reply to comment #2)
> The main reason this is allowed is that form feeds appear in documents such as
> RFCs.

In the case of text/plain RFCs, it doesn't matter if form feeds count as space
characters or not.

When you say "such as", do you really mean "such as" or do you mean
specifically and only RFCs?

> https://bugzilla.mozilla.org/show_bug.cgi?id=437915 suggests Mozilla already
> does what the HTML spec says, though. I'm loathe to keep dragging implementors
> back and forth on this.

Maybe you shouldn't have tested in Acid3 in the first place. It's not something
that was an active interop problem making it harder for authors to write Web
content.

> Furthermore, changing this would mean changing the
> Gecko and WebKit HTML parsers, which treat U+000C like U+0020 in a whole bunch
> of places.

It would be relatively easy to remove the treatment from Gecko's HTML parser.

> We don't really gain anything by making U+000C illegal if we still let it
> appear in the DOM (which we presumably would, as we do U+000B for example).

We would gain consistency between various specs and code. Now Gecko has a
different set of space characters in different places and the specs have a
different set of space characters in different places (most obviously between
HTML5 and XML 1.0).

> Furthermore, CSS syntactically agrees with the HTML spec here in terms of how
> U+000C is handled (as whitespace).

This surprises me. I don't recall seeing that in Gecko's white-space property
implementation when I last looked.

Have you tested to see that implementations actual treat U+000C as CSS white
space?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 4 October 2010 13:21:10 UTC