User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040808 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040808 At the moment only attributes without namespace can be used as ID attributes. To support for example X+V's xv:id, it should be possible to define the ID attribute name and namespace. So possibly we could add set/getIDAttributeNamespace() to nsINodeInfo Reproducible: Always Steps to Reproduce:
13 years ago
Namespace information should be able to get also from nsIContent.
*** Bug 258237 has been marked as a duplicate of this bug. ***
Or am I wrong here. If someone needs namespace ID attribute he can implement http://lxr.mozilla.org/seamonkey/source/content/base/public/nsIStyledContent.h#63 GetID(); Hmm, how did I create that duplicate.
First off, you're correct that ID attributes in fact have to be in the null namespace in Mozilla right now (and the code you're looking at, along with nsIContent and all callers are what would need fixing). That said, the concept of namespaced IDs makes no sense. Consider: <html:div id="foo" ev:id="bar"> What should happen? The point is, the ID attribute should be determined by the language the element is from (as specified by the element's namespace). There's no need to namespace the ID attr at that point... So it sounds to me like we would be better off talking to "X+V" (whatever/whoever that is; got a link?) about this than going of and implementing something that is ill-defined in general.
Won't this be solved, eventually, when 'xml:id' becomes a standard?
<html:div id="foo" xml:id="bar"> ?
Ok, I meant it more as a reply to comment 0. If you can use 'xml:id', there is no need for namespaces. Shouldn't the W3C define which ID gets preference in the 'xml:id' draft?
Why can't an element have more than one ID? Am I missing something?
Ian, see http://w3.org/TR/2004/REC-xml11-20040204/#one-id-per-el (and http://w3.org/TR/2004/REC-xml-20040204/#one-id-per-el for the XML 1.0 equivalent). Anne, the xml:id draft doesn't specify the case I cite because it is technically not valid XML. This is not to say that people won't write it, and we're not a validating parser...
As you say, that's a validity constraint, and so largely irrelevant here. I don't understand the problem with having more than one ID.
X+V adds a new ID attribute to VoiceXML fields: http://www.voicexml.org/specs/multimodal/x+v/12/#N11EC9 The new attribute is in X+V namespace, see the DTD or http://www.voicexml.org/specs/multimodal/x+v/12/#N10722 field element.
Right. The question is why they're doing this instead of putting the ID attribute in the null namespace. If people all took this route, you could end up in a situation where you wanted two ID attributes in different namespaces on the node, and the XML spec prohibits that...
Because the element itself might not be under your control. XML prohibits a validating UA from processing a document with a DTD that explicitly marks two attributes on the element as being of type ID. But since Web UAs typically aren't validating, and namespaced documents typically don't have a DTD, I don't see that it's very relevant. :-)
> I don't understand the problem with having more than one ID. We _could_ change our ID handling to supporting a list of ID attribute names per element (instead of just a single attribute name). I think things would sort of work. Maybe. The question is, why would this be useful? > and namespaced documents typically don't have a DTD I thought the point was that the UA assumed knowledge of the document language (including things like IDs that would be defined in the DTD associated to that document) from the namespace? Which rather implies to me that restrictions placed on such documents with DTDs would also apply to DTD-less documents... anything else doesn't really make much sense unless the intent is to confuse people.
FWIW, the DOM Level 3 Core spec defines a way to flag any attribute as an ID, see: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-ElSetIdAttr and friends...
(In reply to comment #14) > > I don't understand the problem with having more than one ID. > > We _could_ change our ID handling to supporting a list of ID attribute names per > element (instead of just a single attribute name). I think things would sort of > work. Maybe. The question is, why would this be useful? Well, I don't think changing nsIStyledContent would be necessary since any namespaced ID attributes would presumably be IDs for any elements.
Actually, no. The links in comment 11 show that the xv:id attribute is only an ID for vxml:field elements per that spec. Other vxml elements ("rule", "cancel") use an "id" attribute in the null namespace for their ID. Still others have no attr of type ID defined at all. The XHTML attributes being imported into this spec naturally use "id" in the null namespace. There's also some mumbling about an "id" attribute in the null namespace at the bottom of the table (search for "vxml:field&" in the page at http://www.voicexml.org/specs/multimodal/x+v/12/)
The basic problem here is of course that DTDs aren't "namespaced" and that id-attributes is declared in the DTD, thus you can't specify a namespace for the id-attribute, only a name. In my mind defining namespaced id-attributes will always get you on thin ice. Namespaced attributes are intended for "global" attributes that can be placed on any element, such as ev:event, xlink:href, or xsl:use-attribute-sets. And if you set such an attribute on an element that already has an id defined you'll break the rule defined in comment 9. I do realize that it's not the author that walked out on thin ice here, but rather was pushed out there by the W3C spec.
12 years ago
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/
12 years ago
I vote for WONTFIX here (and in bug 275196, for that matter).