8.43 KB, patch
|Details | Diff | Splinter Review|
339 bytes, application/xhtml+xml
339 bytes, text/html
339 bytes, text/xml
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
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
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
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...
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
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
I'll keep your patch around when I do nsXHTMLDocument though, that's exactly the basis I was looking for :-) Thanks!
You need to log in before you can comment on or make changes to this bug.