Closed Bug 10173 Opened 20 years ago Closed 20 years ago

DOM comparison of [CI] align attribute fails when comparing upper and lower case.

Categories

(Core :: DOM: Core & HTML, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jcarpenter0524, Assigned: vidur)

Details

(Keywords: platform-parity, testcase)

Attachments

(2 files)

Overview Description:
According to DOM Level-1 spec., HTML Section, "...the return value of an
attribute that is a value list (e.g., left|right|center) is always
capitalized..."

However, the return value for HTMLTableElement.align is always lower case.

Testcase:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>test</TITLE></HEAD>
<BODY>
<P>The return value should be capitalized as &quot;Right&quot;. <BR>
<TABLE BORDER=1 ALIGN="RIGHT">
  <TR><TD>cell data</TD><TD>cell data</TD></TR>
  <TR><TD>cell data</TD><TD>cell data</TD></TR>
</TABLE>
<SCRIPT TYPE="text/javascript">
var oList=document.firstChild.childNodes[1].childNodes[2].align;
document.write("Return Value = " + oList);
</SCRIPT>
</BODY></HTML>

Actual Results:
The return value is "right"

Expected Results:
The return value should be "Right"

Build Date & Platforms Bug Found:
1999-07-19-12-M9
WinNT, Win98, MacPPC, Linux
QA Contact: gerardok → janc
Whiteboard: [TESTCASE]
Should the return be ``RIGHT'' or ``Right''?  I suspect the former, but I'm
going to drag David into this one as well. =)

Not for beta, I don't think.
No, it should be "Right".  However, a getAttribute() should return "RIGHT", I
think.  There are special case rules in the HTML DOM, for backwards
compatibility (with what?).  See
http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-642250288
Summary: DOM returns wrong case for align attribute of HTMLTableElement → DOM comparison of [CI] align attribute fails when comparing upper and lower case.
dbaron is absolutely correct about the return value.

I wrote this bug incorrectly.  The bug is not what DOM returns, but whether it
accepts "RIGHT" "Right" "right" and "riGHt" as the same thing in a comparison.
The align attribute should be case insensitive (as I understand it anyway.)

I'm attaching a new test case as the original is now invalid.

The same thing is happening for bgColor in tables, if this is a bug, is it the
same one or a separate one?

(rewording summary to reflect bug)
Two problems here:

* I don't see any align attributes in your test case (I didn't look too closely,
but...)
* More importantly (if I understand what you're trying to say correctly, which i
may not), the case insensitivity doesn't extend to JavaScript.  The attribute is
case insensitive w.r.t. HTML (and therefore CSS).  However, the DOM defines the
case of the return value, and JavaScript string equality operations just compare
strings, and are therefore case sensitive.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Fix checked in on 11/16/1999. The revised testcase is incorrect. We should
always return a value that has the first letter uppercased.
fyi, this cause breakage.  see bug #19068
Status: RESOLVED → REOPENED
OS: All → Windows 98
Hardware: All → PC
Summary: DOM comparison of [CI] align attribute fails when comparing upper and lower case. → [PP]DOM comparison of [CI] align attribute fails when comparing upper and lower case.
Resolution: FIXED → ---
DOM now returns all lower case on Windows only.  Mac and Linux now return
correct result.
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Keywords: pp
Summary: [PP]DOM comparison of [CI] align attribute fails when comparing upper and lower case. → DOM comparison of [CI] align attribute fails when comparing upper and lower case.
Whiteboard: [TESTCASE]
This bug is now fixed.
Marking fixed
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.