76054 - String() HTML methods not XHTML compliant

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Alex Vincent [:WeirdAl]]

From Bugzilla Helper:

I've noticed the HTML methods of String.prototype return uppercase tags.  The 
latest HTML recommendation from the W3C specifies lowercase tags -- example:  
<big>k</big> instead of <BIG>k</BIG>.

Reproducible: Always
Steps to Reproduce:
1. Type javascript:alert("k".big()) into your location bar.


Actual Results:  Alert window containing "<BIG>k</BIG>".

Expected Results:  Alert window containing "<big>k</big>".

Comment 1

[Phil Schwartau]

Confirming. I was unable to fine a definitive comment on this by W3C,
for example at http://www.w3.org/TR/html401/present/graphics.html#edef-BIG

[e-mail]: can you provide a W3C URL reference on this issue? 
Thanks - 

Comment 2

[Alex Vincent [:WeirdAl]]

Unfortunately, the XHTML 1.0 specs do not go over each and every tag like HTML 
4.01 does.  Also, because the String() object (ECMAScript) is not covered in 
the DOM, there's no references there.

About the best references I can find are Sections 4.2 and of the XHTML 1.0 W3C 
Recommendation.

-- quote --
4.2 Element and attribute names must be in lower case
XHTML documents must use lower case for all HTML element and attribute names. 
This difference is necessary because XML is case-sensitive e.g. <li> and <LI> 
are different tags.
-- quote --

-- quote --
C.11 Document Object Model and XHTML
The Document Object Model level 1 Recommendation [DOM] defines document object 
model interfaces for XML and HTML 4. The HTML 4 document object model specifies 
that HTML element and attribute names are returned in upper-case. The XML 
document object model specifies that element and attribute names are returned 
in the case they are specified. In XHTML 1.0, elements and attributes are 
specified in lower-case. This apparent difference can be addressed in two ways: 

Applications that access XHTML documents served as Internet media type 
text/html via the DOM can use the HTML DOM, and can rely upon element and 
attribute names being returned in upper-case from those interfaces. 
Applications that access XHTML documents served as Internet media types 
text/xml or application/xml can also use the XML DOM. Elements and attributes 
will be returned in lower-case. Also, some XHTML elements may or may not appear 
in the object tree because they are optional in the content model (e.g. the 
tbody element within table). This occurs because in HTML 4 some elements were 
permitted to be minimized such that their start and end tags are both omitted 
(an SGML feature). This is not possible in XML. Rather than require document 
authors to insert extraneous elements, XHTML has made the elements optional. 
Applications need to adapt to this accordingly. 
-- quote --

Based on the above, now that I think about it, this bug may be invalid.  The 
above quotes suggest it depends on the mime-type.  I was looking at it from the 
point of view of XHTML 1.0, as this is the latest W3C recommendation.

Still, if it is not a bug, I think it should be reclassified as a request for 
enhancement.

Comment 3

[Alex Vincent [:WeirdAl]]

The URL for the above quotes is http://www.w3.org/TR/2000/REC-xhtml1-
20000126 .  Apologies for the spam.

Comment 4

[Phil Schwartau]

cc'ing Brendan for his opinion on this issue - 

Comment 5

[Alex Vincent [:WeirdAl]]

Hey, I'm impressed.  I've welcomed your comments on 70879 (Errata in JS1.5 
documentation), and I'm glad you were able to confirm this one so quickly.

May I suggest we're looking at three different cases here:

(1) A webpage sent to the client as text/html.  
(2) A webpage sent to the client as text/xml or application/xml.
(3) From about:blank, using the javascript:alert("k".big())

As per the W3C specs, these cases may be treated separately.

Comment 6

[Brendan Eich [:brendan]]

Trivial to fix -- rogerl, can you do this one quickly?  Rhino should get the
same lower case love.

/be

Comment 7

[Alex Vincent [:WeirdAl]]

Ah, quick comment:  I recently filed bug # 76057 as well, regarding a DOM 
issue.  Would any such fix to this bug impact that one as well?

Comment 8

[Alex Vincent [:WeirdAl]]

Regarding bug # 76057 above:  disregard.  Next time I'll let my friends file 
their own bugs.  This one I was certain about, the other I was going off what 
they were telling me.  Sorry for the spam.

Comment 9

[rogerl (gone)]

Attachment: lower-casified all the tags; look ok?

Comment 10

[Phil Schwartau]

I have filed bug 78706 for this same issue in Rhino -

Comment 11

[Alex Vincent [:WeirdAl]]

While we're on the subject, the <blink> tag we all know has been deprecated 
from HTML 4 and XHTML 1.  Should the String.prototype.blink method override a 
deprecated blink in the standards and use JS/CSS to enable blink anyway?  
Should the method itself be deprecated?

Comment 12

[Phil Schwartau]

Testcase added to JS testsuite: 

               js/tests/js1_5/Regress/regress-76054.js

Comment 13

[Brendan Eich [:brendan]]

r/sr=[e-mail] on rogerl's patch, let's get this.  Shaver, can you
give another r/sr?

I think we should keep blink and everything, this is all legacy crap, not
normative, not likely to influence anyone.

/be

Comment 14

[Alex Vincent [:WeirdAl]]

Where's the testcase??  
http://lxr.mozilla.org/mozilla/source/js/tests/js1_5/Regress/ doesn't show 
it.  :(

Nothing major, just wanted to take a look at it.

Comment 15

[Phil Schwartau]

lxr takes some time to update, unfortunately. 
I will attach the testcase below.

Comment 16

[Phil Schwartau]

Attachment: The testcase. Depends on utilities in js/tests/js1_5/shell.js

Comment 17

[Patrick C. Beard]

r=beard, patch is trivial.

Comment 18

[rogerl (gone)]

Fix checked in.

Comment 19

[Phil Schwartau]

Marking Verified - the testcase passes in the debug and optimized JS shell.

Comment 20

[Mathias Bynens]

11 years later, IE still has this issue. https://connect.microsoft.com/IE/feedback/details/752283