User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 I have xml document with DTD. Root of document has default namespace (xmlns attribute). When I create new element by createElement() method then I can't get new element by getElementById() attribute. If I create new element by createElementNS() method then getElementById() works fine. Most likely createElement() method doesn't specify namespace for new element. Reproducible: Always
save it on local disc and place it under 'chrome://' protocol
save on root of local disc 'c:/' and change url of external DTD
save on local disc with xml and dtd files
Elements created with the DOM Level 1 methods don't get namespaces in conformance with the spec. We implemented two exceptions for XHTML and XUL, see bug 280692.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Are you really sure that getElementById() returns null because createElement() doesn't set namespace? If is true, I belive this behaviour is not very comfortably. As I can understand from bug 280692 nobody knows why such behaviour was offered in spec. What difference between XUL, XHTML and arbitrary XML? Why createElement() should have another behaviour for XML documents?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
> Are you really sure that getElementById() returns null because createElement() > doesn't set namespace? Yes, in this case (since the id-attribute in the DTD ends up tied to that particular namespace, which could be considered a bug in itself -- note that if there were no <class> elements in the document then even the createElementNS() case wouldn't work here; we have a bug on that). DTDs are a parse-time-only issue in Mozilla (since we're a non-validating parser); they don't really affect DOM interaction except through sharing of nodeinfos (which is what makes the createElementNS() case work here). > As I can understand from bug 280692 nobody knows why such behaviour > was offered in spec. Because there is no sane behavior that makes sense in a mixed-namespace document otherwise. > What difference between XUL, XHTML and arbitrary XML? XUL and XHTML have specific MIME types (application/xhtml+xml and application/vnd.mozilla.xul+xml). Those are what affect the behavior of createElement; the namespace on the root element does not. Also, XHTML has this little problem of needing to be somewhat compatible with HTML if it's to be adopted at all. And XUL is what Mozilla defines it to be. That's why it makes sense to mess with createElement for those cases. > Why createElement() should have another behaviour for XML documents? For a text/xml document there is simply no reasonable behavior for createElement past creating a node in the null namespace.
(In reply to comment #6) > Yes, in this case (since the id-attribute in the DTD ends up tied to that > particular namespace, which could be considered a bug in itself Is there instruction of DTD to specify namespace for witch DTD will work? What namespace will be choosed by DTD in current realization if xml document has a multiple namespaces? Will DTD be applied for elements of all namespaces or default only? How it works in current realization? > -- note that if > there were no <class> elements in the document then even the createElementNS() > case wouldn't work here; we have a bug on that). Can you say me number of this bug? > Because there is no sane behavior that makes sense in a mixed-namespace document > otherwise. Why the next behaviour is not sane: createElement() should create element with default namespace of document?
> Is there instruction of DTD to specify namespace for witch DTD will work? Not that I know of. > What namespace will be choosed by DTD It'll apply to all of them. The "tying" I talked about is happening because of bug 252774. > Can you say me number of this bug? Bug 252774. > create element with default namespace of document? There is no such concept (that is, a document has no default namespace). If you mean the default namespace of the document's documentElement (if any), that can change quite easily, and I think createElement returning different things during a document's lifetime is pretty wrong. In any case, marking dependent on bug 280692; once that gets resolved there may be something to discuss here or might not be.
Depends on: 280692
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Actually, this bug is invalid. The current behaviour is according to spec.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.