Closed
Bug 269884
Opened 20 years ago
Closed 20 years ago
DOM problem with MIME type application/xml (select element)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: martin.thomson, Unassigned)
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Identical code that is served with the MIME type of application/xml (instead of
text/html or application/xhtml+xml) causes the following simple DOM code to
break. The <option> element is added to the <select>, but the new option is not
styled correctly (a minor alignment difference is noted) and it cannot be selected.
var list = document.getElementById("sel");
var opt = document.createElement("option");
opt.appendChild(document.createTextNode("addedstring"));
list.appendChild(opt);
The problem only occurs when served with the "application/xml" MIME type.
Reproducible: Always
Steps to Reproduce:
1. Load a file as application/xml (.xml) with the above code snippet.
2. Load a file as application/xhtml+xml (.xhtml) with the above code snippet.
3. Load a file as text/html (.html) with the above code snippet.
Actual Results:
The file with MIME type 'application/xml' does not work as expected. The newly
added option is not selectable and it looks subtly different.
Expected Results:
The new item should be selectable and not distinguishable from preexisting options.
I will attach a few test cases.
|
Reporter | |
Comment 1•20 years ago
|
||
This file demonstrates the problem.
|
|
Reporter | |
Comment 2•20 years ago
|
||
This file exhibits no problems.
|
|
Reporter | |
Comment 3•20 years ago
|
||
For completeness, a simple html version.
|
||
Comment 4•20 years ago
|
||
I think you need to use createElementNS in XML files, with the right namespace, instead of createElement
|
|
Reporter | |
Comment 5•20 years ago
|
||
The last comment is correct; the following works OK:
var opt = document.createElementNS("http://www.w3.org/1999/xhtml", "option");
However, I would expect that a qualified name should be enough for the document
(which is the <html> element I thought) to identify what namespace to use by
default. Failing that, the operation should fail with an appropriate message.|
|
||
Comment 6•20 years ago
|
||
I think what happens is that createElement creates an element in the null namespace here (DOM Inspector seems to confirm that). that doesn't sound like it should fail. but cc'ing someone who knows how this stuff is supposed to work.
|
||
Comment 7•20 years ago
|
||
There is no reason the namespace of the root element should be the namespace used by default... in the application/xhtml+xml case, you have explicitly told us this is an HTML document, so it makes sense to assume HTML there. Otherwise using the null namespace makes a lot more sense. And no, this should not fail. The element _can_ be created. If you note, the DOM spec strongly suggests not using createElement() in namespace-aware applications, precisely because of issues like this. Marking invalid, since I believe we have already discussed what the behavior should be here and came up with what we implement.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
|
||
Comment 8•20 years ago
|
||
bz: Do you have a reference for that decision? It seems like a bug that two RFC3023 MIME types would have different DOM behaviour. Do we also default createElement() to SVG for image/svg+xml and to MathML if you use the MathML MIME type and so forth? In what spec would it say that that is correct behaviour?
|
|
||
Comment 9•20 years ago
|
||
> bz: Do you have a reference for that decision? Not offhand, no.... > It seems like a bug that two RFC3023 MIME types would have different DOM > behaviour. You've been saying that for a while, and jst's been disagreeing for a while. Doesn't it bother you more that the application/xhtml+xml case implements nsIDOMHTMLDocument and the application/xml case does not? > Do we also default createElement() to SVG for image/svg+xml and to MathML if > you use the MathML No. We only do this for XHTML and XUL. > In what spec would it say that that is correct behaviour? None, probably, since the spec that defines createElement also strongly urges that it not be used.
|
|
||
Comment 10•20 years ago
|
||
>> It seems like a bug that two RFC3023 MIME types would have different DOM >> behaviour. > > You've been saying that for a while, and jst's been disagreeing for a while. Heh. > Doesn't it bother you more that the application/xhtml+xml case implements > nsIDOMHTMLDocument and the application/xml case does not? Yes, I've said for a long time that an XML Document should implement all the Document interfaces (SVG, HTML, etc), and I see nothing in the specs that says this shouldn't be the case. > > Do we also default createElement() to SVG for image/svg+xml and to MathML if > > you use the MathML > > No. We only do this for XHTML and XUL. That seems very bad. > > In what spec would it say that that is correct behaviour? > > None, probably, since the spec that defines createElement also strongly urges > that it not be used. What is correct behaviour and what is recommended usage are unrelated things.
You need to log in
before you can comment on or make changes to this bug.
Description
•