xhtml documents behave like html documents

RESOLVED INVALID

Status

()

Core
XML
RESOLVED INVALID
16 years ago
15 years ago

People

(Reporter: sicking, Assigned: sicking)

Tracking

({xhtml})

Trunk
mozilla1.0
x86
Other
xhtml
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

XHTML documents currently behave like html documents. This causes 
createProcessingInstruction, createCDATASection and getElementsByTagName(NS) to 
behave wrongly.

Patch coming up
nice bug# :-)
Status: NEW → ASSIGNED
oops, i was supposed to have this
Assignee: heikki → sicking
Status: ASSIGNED → NEW
Keywords: xhtml
Comment on attachment 73489 [details] [diff] [review]
patch to fix

found a few more places to check for xhtml-ness.. new patch in a sec
Attachment #73489 - Attachment is obsolete: true
Created attachment 73491 [details] [diff] [review]
patch v2

fixes CreateElement(NS) too
arg! ignore the nsXULElement.(cpp|h) changes in there. They are another patch 
to keep my debug builds alive. Forgot to save before cutting it out :(

i'll go to bed now
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0

Comment 7

16 years ago
jonas, what we had planned to do with johnny about this, was to create a new
nsXHTMLDocument class (inheriting nsHTMLDocument) which overrides the needed
methods (just like you did in this patch). Also, I assume you mean "xhtml
documents behave like html documents [when served as text/html]. 
However, if my memory serves me well, it was said that we shouldn't sniff the
doctype to know what kind of document we should create, or something like that.
So perhaps this patch would be needed anyway, but that would suck.
I wanted to do this patch for 1.0, but I'm not sure it will be possible. If
there is demand I can, though.
> jonas, what we had planned to do with johnny about this, was to create a new
> nsXHTMLDocument class (inheriting nsHTMLDocument) which overrides the needed
> methods (just like you did in this patch).

Oki, that sounds fine, I just ran into this and thought it was a quick fix. But 
if you had planned to do the nsXHTMLDocument class solution before 1.0 then 
that is a much better fix.

> Also, I assume you mean "xhtml
> documents behave like html documents [when served as text/html]. 

No, it's mostly aimed as xhtml docuemnts served as text/xml. When and how we 
parse as html vs. xhtml is an orthogonal issue, but when we've decided that a 
document is xhtml then it should get a certain behaviour.

Or are there three possible ways a html document can behave; 1: html, 2: xhtml 
served as text/html and 3: xhtml served as text/xml? I had the impression that 
2 was the same as either 1 or 3 and that there was a debate over which one?

If 2 is indeed a different way to behave, then how is it different from 1 and 
3? (the spec confuses me ;-) )
We create nsHTMLDocument only if the mime type is text/html. If the mime type
says HTML, we should treat the document as plain ol' HTML, and not jump through
hoops to discover if the user really meant XHTML. I think this bug should be
wontfix (at least for now).

application/xhtml+xml is a different matter, and I would accept nsXHTMLDocument
for that.
nono, that's not what the patch is trying to do. The patch is trying to fix the 
case when a user sends xhtml document as type text/xml (or application/xml). In 
those cases too we create an nsHTMLDocument.

So we end up with a DOM where all elements behave like xhtml content, except 
the root Document object which behaves like an html. Try for example doing 
|document.getElementsByTagName("BODY")| in an xhtml element, you'll get a 
nodelist which contains the <body> even though it's the wrong case.

So this bug is only about making xhtml documents behave like xhtml document, 
unlike now when they behave like html documents.


As a sidenote: I do agree with heikki that we should *only* look at the 
mimetype sent to us and then send to the appropriate parser. However i'm not 
entierly sure if the spec agrees with that. But that's for a different bug.
Whaat! Since when??? We create the document object as soon as we see the mime
type. I do not understand how we could have an HTML document with XML mime type.
If we do it is really, really wrong! I'll check after lunch...

Comment 12

16 years ago
Heikki is right. text/xml should not result in HTMLDocument.
But it does :-)

I totally agree that it would be better if we had a nsXHTMLDocument class. But 
we can't just create an nsXMLDocument. If we did that we wouldn't be able to 
implement HTML-DOM on the document which would be confusing since we do that on 
all elements (and we have to do it on for example form-elements).

So either this bug should be fixed by, as Fabian suggests, creating a 
nsXHTMLDocument class which inherits nsHTMLDocument (or which implements HTML-
DOM some other way). Or by doing what i do in the patch.

I totally agree that using another class would be better, but i just had the 
feeling that that would not happen before 1.0
Created attachment 73571 [details]
Minimal XHTML file with XHTML mime type
I don't see what you are seeing. Place a breakpoint in nsXMLDocument
constructor, and load those two testcases. I hit the bp in the first testcase,
but not in the second.
okey, i suck :(

sorry for poor testing.

We should probably create nsXHTMLDocuments somewhere, somehow, but that's 
covered by bug 111514
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 19

16 years ago
I'll keep your patch around when I do nsXHTMLDocument though, that's exactly the
basis I was looking for :-) Thanks!

Updated

15 years ago
QA Contact: petersen → rakeshmishra
You need to log in before you can comment on or make changes to this bug.