69032 - XHTML whitespace rules aren't being followed

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[Sampo Syreeni]

On the page cited, there are red xhtml:pre elements. It is easy to see that the
initial linefeed after the <pre>-tag gets rendered as a blank line, unlike when
the XHTML documents are served as text/html. So it's not an HTML or XML problem,
but an XHTML one.

According to the XHTML spec (http://www.w3.org/TR/xhtml1/#uaconf
): "[...] The following characters are defined in [XML] as whitespace
characters: [...] Carriage return (&#x000D;) Line feed (&#x000A;) [...] In
elements where the 'xml:space' attribute is set to 'preserve', the user agent
must leave all whitespace characters intact (with the exception of leading and
trailing whitespace characters, which should be removed). [...] Leading and
trailing whitespace inside a block element must be removed. [...]". I.e. <pre>
should work as in HTML.

Marking as enhancement since XHTML is a christmas-list item...

Comment 1

[James Green]

jg@cyberstorm:~$ host upsws3591.ntc.nokia.com
upsws3591.ntc.nokia.com A record currently not present

Reporter: can you attach a testcase please? Severity should be Normal. This
could be parser or layout.

Comment 2

[Sampo Syreeni]

Damn. Changed the URL to an online version. I must be braindead, or getting 
senile.

It's much more likely that it's a layout thing - if it was the XML parser, 
people would have noticed it elsewhere.

Comment 3

[Keyser Sose]

Confirmed
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001021408

Marking NEW.

Comment 4

[bsharma]

qa contact updated.

Comment 5

[bsharma]

changing the component to 'Layout'.

Comment 6

[karnaze (gone)]

Reassigning to Buster's list.

Comment 7

[Christopher Hoess (gone)]

Adding keyword.

Comment 8

[Christopher Hoess (gone)]

Reporter: the URL no longer contains the tags in question.  Do you have another
URL showing the problem?  Is this related to bug 2750?

Comment 9

[Sampo Syreeni]

Ah, yes. They are green now. What a wonderful choice of colors, don't you think?
;) It's <pre class="disposition"> in the code, and the leading empty line still
seems to be there at 0.9.3.

Comment 10

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 11

[Christopher Hoess (gone)]

Having done investigation into Bug 2750, there's code in the htmlparser to
handle this specific situation for HTML. Probably an XML parser problem and not
layout. Can you provide a new testcase?

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Seems like the testcase is no longer available. It would help if someone made a
testcase and attached it to this bug, so it wouldn't get lost.

I think we have never supported xml:space, so I don't think this is XHTML
specific. I would bet it is an issue with Expat or possibly with our integration
of it. There  might be a dupe about this somewhere.

Comment 13

[Sampo Syreeni]

Attachment: Testcase for XHTML whitespace handling

Pre element in XHTML, which shouldn't have a leading empty line

Comment 14

[Sampo Syreeni]

Attached a test case.

I think the problem is that, XML parsers are supposed to return all white-space
to the application. Regardless of xml:space, even, if I'm not entirely mistaken.
This is different from HTML, where the parser is supposed to have removed the
space. So, in XHTML the parser *will* give us the extra linefeed in the
beginning of <pre/>, and the content sink will have to know to strip it.

Comment 15

[Hixie (not reading bugmail)]

The XHTML spec has _no_ business telling us what to do when parsing. This is
invalid, IMHO. We are rendering the test case correctly.

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I can't see that the XHTML spec says anything like comment 0 (was it quoting a
workdraft?). AFAICT this bug is INVALID

Comment 17

[Hixie (not reading bugmail)]

It says it in:
   http://www.w3.org/TR/xhtml1/#uaconf

But I still think that's ridiculous and can be ignored.

Comment 18

[Sampo Syreeni]

Attachment: The original test case with a different MIME type

The orignal test case with a genuine XHTML MIME type. Attached to test for
XML/XHTML variance in whitespace handling.

Comment 19

[Sampo Syreeni]

Let me clarify. According to XHTML 1.0 and HTML 4.0(1) (the two of which I was
originally referring to), the attached test cases should render without a
leading empty line. I suspect later XHTML versions will tell you the same thing,
although I haven't checked.

The problem arises because XHTML is an XML application, while HTML is an SGML or
standalone one, as I've explained. I agree that whatever the Mozilla HTML and
XML parsers actually do, internally, is none of W3C standards' business. Still,
rendered text should work according to the rules as a whole. As of the latest
nightly build (2002120208) it doesn't. For it to pass, the conditions are:

-If you parse the example as XML (text/xml), the leading whitespace should
render if you do not switch to XHTML rendering upon encountering the XHTML
namespace.
-If you parse the example as XML (text/xml), the leading whitespace shouldn't
render if you switch to XHTML rendering upon encountering the XHTML namespace.
-If you parse it as XHTML (application/xhtml+xml) the leading whitespace most
definitely shouldn't show.
-If you parse the corresponding SGML/HTML representation (text/html), the
leading whitespace would obviously be discarded.

At the moment, neither of the attached representations works as it's supposed
to. The first one is supposed to be rendered as XML, so we could argue Mozilla
parses it as XML without paying regard to namespaces, and so fails to notice
that pre-elements should be handled differently (as per XHTML 1.0). The newly
attached one with the XHTML MIME type however is incorrectly rendered by any
definition. Hence, Mozilla isn't conformant to XHTML 1.0.

I originally marked this as an enhancement, since XHTML isn't part of the
current, official Mozilla agenda. Thus, it doesn't bother me if the Mozilla
crowd decides that XHTML isn't worth supporting -- I do understand about
priorities. But this one definitely isn't INVALID. It's either WONTFIX or NEW;
minor, major or enhancement.

Comment 20

[Hixie (not reading bugmail)]

The point is, we're not an XHTML user agent. We're an XML+CSS user agent that
happens to have some knowledge about the XHTML namespace. So those rules don't
apply to us.

Comment 21

[Sampo Syreeni]

In that case, the report should probably once more be marked enhancement and
resolved WONTFIX.

Comment 22

[Henri Sivonen (:hsivonen)]

Any particular reason why this one isn't RESOLVED (WONTFIX or INVALID)?

Comment 23

[Hixie (not reading bugmail)]

why indeed