Bug 57916 - element name case is incorrect in XHTML documents
Summary: element name case is incorrect in XHTML documents
Status: VERIFIED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-30 21:13 UTC by Jesse Pelton
Modified: 2005-01-04 11:26 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
test case (1.55 KB, text/html)
2003-04-30 21:14 UTC, Jesse Pelton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Pelton 2003-04-30 21:13:56 UTC
Version:            (using KDE KDE 3.1.1)
Installed from:    I Don't Know
OS:          Linux

Summary: element name case is incorrect in XHTML documents

Demonstration: Load this page. It has a load handler that puts up an alert box with the body element's tagName. According to http://www.w3.org/TR/xhtml1/#C_11, "User agents 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." However, Konqueror returns the element name in its original case (lowercase for XHTML), even if the media type is text/html.

Additional information:
- Mozilla, Opera 7.0, and IE 6.0 all get this right.
- The second Safari beta also gets this right, so somewhere there's corrective code. It may be in the Konqueror source tree already, but I thought I should report the issue just in case.
- I'm running Knoppix from a CD.
Comment 1 Jesse Pelton 2003-04-30 21:14:54 UTC
Created attachment 1466 [details]
test case

Oops. I meant, "Load the attached test case."
Comment 2 Thiago Macieira 2003-04-30 22:17:49 UTC
It showed uppercase (testing with Konqueror from KDE CVS 20030405). The Safari 
correction you mention has probably been integrated, so I'm closing this bug report. 
 
Thank you for your report. 
Comment 3 Jesse Pelton 2004-03-17 14:10:47 UTC
The test case fails (that is, the element name is lowercase) in Konqueror 3.2.1. Reopening.
Comment 4 Jesse Pelton 2004-03-17 14:22:17 UTC
Apparently Safari's correction to this problem has not in fact been integrated. Maybe Apple needs a little nudge...?
Comment 5 Jesse Pelton 2004-05-14 01:30:58 UTC
Still broken in 3.2.2.
Comment 6 Jesse Pelton 2004-09-29 02:46:40 UTC
Still broken in 3.3.
Comment 7 Stephan Kulow 2004-11-11 13:53:11 UTC
not sure what you see. But I see BODY (with 3.3.2 code base though)
Comment 8 Jesse Pelton 2004-11-15 23:51:19 UTC
With 3.3.1, the message box says, "document.body.tagName: body". Code from CVS has been reported to work before (see comment #1), but this test has always failed with released code for me.  Maybe the fix lives on a branch that never makes it into releases...?
Comment 9 Stephan Kulow 2004-11-18 16:05:27 UTC
Then you will be pleased about 3.3.2 :)

I think, the thing that was fixed was how we react on xhtml served as text/html, we used to see it as invalid. Save the test case as .xhtml and it 
should work even with 3.3.0
Comment 10 Jesse Pelton 2004-11-19 03:27:38 UTC
I get the same results whether it's saved as .html or .xhtml.  I'm not sure what this tells us, though.  Does Konqueror determine the file type from the file extension when loading a file from disk?  It doesn't list a Content-Type header under View > View Document Information when a file is loaded from disk.  If it does guess content type this way, I'd expect it to treat it as application/xhtml+xml, in which case it would be appropriate for the element names to come back in lowercase (as they always do with versions of Konqueror through 3.3.1).  The problem is what happens when the MIME-type is text/html, in which case element names should be promoted to uppercase.

Anyway, I'll try again when 3.3.2 comes out.  If history is any guide, that could happen sometime in the next month or so.
Comment 11 Jesse Pelton 2004-12-29 01:27:34 UTC
Test case works for me with 3.3.2.  This bug can be closed.