121040 - Attribute values not normalized in XML

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[Brant Gurganus]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

Mozilla is rendering multiple spaces when it should be rendering only one.  I
quote from the XHTML 1.0 specification:

4.7 Whitespace handling in attribute values

In attribute values, user agents will strip leading and trailing whitespace from
attribute values and map sequences of one or more whitespace characters
(including line breaks) to a single inter-word space (an ASCII space character
for western scripts). See Section 3.3.3 of [XML].

I could not find the section in the HTML 4.01 specs that addresses this.  It
seems to only address extra white space between characters.

Reproducible: Always
Steps to Reproduce:
1. Open example URL.
2. The first line of the third paragraph contains "WYSIWYG" as an acronym with
title attribute.

Actual Results:  I believe the title attribute is rendered incorrectly.  It is
rendered with multiple spaces when it should, to my knowledge, be rendered with
a single space in place of the multiple spaces.

Expected Results:  I believe, to my knowledge that it should be rendered with a
single space in place of the multiple spaces.

The suspect HTML code is:
<acronym
title="What You See Is What You (might)                                
Get">"WYSIWYG</acronym>

Notice, there are multiple spaces after (might).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Over to parser.  This happens on linux too.

Comment 2

[Christopher Hoess (gone)]

Similar to bug 47078.  There's some bugs floating out there about strippingspaces in non-CDATA attributes too (for instance), but I don't remember ifthere's anything on this specifically.

Comment 3

[Brant Gurganus]

The people at the original URL removed the extra space.  It can no longer be
used as an example of the problem.

Comment 4

[Brant Gurganus]

URL removed because it is no longer an example

Comment 5

[Brant Gurganus]

Attachment: acronym title test case

This is a test case for the white space in acronym title bug.  The rendered
tool tip will contain five spaces between "test" and "case" although it should
be rendered with only one space between the two.

Comment 6

[Brant Gurganus]

Simplified test case has been added.

Comment 7

[Brant Gurganus]

All tested browsers get this wrong: IE6, Mozilla, W3C's Amaya, Opera.

Comment 8

[harishd]

Not a high priority. 

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 9

[Brant Gurganus]

It isn't uncommon for editors to wordwrap and pretty print their HTML.  If this
happens to any title attribute, then this problem will occur.  I think it has a
fair likelihood of repetition.

Comment 10

[Christopher Hoess (gone)]

Repurposing this bug for the XML case, HTML case is a duplicate of bug 47078. 
Maybe heikki's bug?

Comment 11

[Martijn Polder]

Attachment: Example that shows CR/LFs as well

The relative seriousness of the bug shows up better if CR/LFs are inserted into
the title-attributes. Instead of the CR/LFs, strange looking characters are
displayed. An extra incentive should be that IE6 handles the CR/LFs correctly.

Comment 12

[Jo Hermans]

*** Bug 299365 has been marked as a duplicate of this bug. ***

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Moving to XML based on comment 10.

Comment 14

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Marking invalid. XHTML1 misrepresents the XML specification here. XML states: [1]

> If the attribute type ***is not CDATA,*** then the XML processor MUST further
> process the normalized attribute value by discarding any leading and trailing
> space (#x20) characters, and by replacing sequences of space (#x20) characters
> by a single space (#x20) character.

(Emphasis mine.) This makes attachment 69987 [details] incorrect, as @title *is* CDATA. [2]
However, we don't seem to normalize for non-CDATA attributes either, but as we aren't a validator, and we don't actually read the full DTD, the following exception applies: [1]

> All attributes for which no declaration has been read SHOULD be treated by a
> non-validating processor as if declared CDATA.

... which makes our behavior for those attributes correct as well.

[1] http://www.w3.org/TR/REC-xml/#AVNormalize
[2] http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_coreattrs