Closed
Bug 17913
Opened 25 years ago
Closed 24 years ago
[dom]HTMLHtmlElement.version returns nothing
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: ckritzer, Assigned: vidur)
References
()
Details
(Keywords: testcase, Whiteboard: [nsbeta2+][6/01])
Attachments
(1 file)
|
306 bytes,
text/html
|
Details |
When the HTML element in a document is set to <HTML version="4.0">,
document.getElementsByTagName('HTML').item(0).version returns nothing.
Steps to Reproduce:
1) Either goto the link above or copy/paste the following into a document:
******************************************************************************
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML version="4.0">
<HEAD>
<TITLE>HTMLHtmlElement.version</TITLE>
</HEAD>
<BODY>
<SCRIPT type="text/javascript">
document.write("HTML Version = '" +
document.getElementsByTagName('HTML').item(0).version + "'");
</SCRIPT>
</BODY>
</HTML>
******************************************************************************
2)
3) Load either document into the 1999110308 apprunner on Win98/MacOS9 or
1999110313 Linux6 apprunner.
Actual Results: HTML Version = ''
Expected Results: HTML Version = '4.0'
Build Date & Platform Bug Found:
MacOS9 1999110308 apprunner
Linux6 1999110313 apprunner
Win98 1999110308 apprunner
Additional Builds and Platforms Tested On:
|
Assignee | |
Comment 1•25 years ago
|
||
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
|
||
Comment 3•25 years ago
|
||
|
|
||
Updated•25 years ago
|
Whiteboard: [TESTCASE]
|
|
||
Comment 4•25 years ago
|
||
Moved test into attachment and marking TESTCASE.
|
||
Comment 5•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
|
||
Comment 8•25 years ago
|
||
PDT would like more info on this. WHat will break if we don't do this in beta1?
Adding [NEED INFO] to Status Summary.
Whiteboard: [TESTCASE] → [NEED INFO]
|
Reporter | |
Comment 10•25 years ago
|
||
As far as I know nothing will break, but we will not be DOM Level 1 compliant without this feature.
|
|
Assignee | |
Comment 11•25 years ago
|
||
This is far from critical or beta1 material. I'm taking it off the radar.
Keywords: beta1
|
|
Assignee | |
Comment 12•25 years ago
|
||
While I recognize the DOM Level 1 compatibility issue, this is not critical to either existing pages or the types of Level 1 applications we see people writing. Should be a simple fix, but moving it off till a later milestone.
Severity: critical → normal
Whiteboard: [NEED INFO]
Target Milestone: M18
|
|
Reporter | |
Comment 13•24 years ago
|
||
nominating for nsbeta2 based on: - feature (DOM Level 1 Standards Compliance) broken
Keywords: nsbeta2
|
||
Comment 14•24 years ago
|
||
Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2.
Whiteboard: [nsbeta2+][6/01]
|
||
Comment 15•24 years ago
|
||
This seems to work now, my guess is that this was fixed when the parser was fixed to actually give the attributes on the HTML element to the content sink (the parser used to ignore the attributes on the HTML tag). I checked the code and the DOM code does what it's supposed to do, marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 16•24 years ago
|
||
Marking VERIFED FIXED on: - MacOS9 2000-05-23-12-M16 Commercial Build - Linux6 2000-05-23-10-M16 Commercial Build - Win95 2000-05-23-10-M16 Commercial Build
Status: RESOLVED → VERIFIED
|
||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•