The default bug view has changed. See this FAQ.

Support for ID attributes with namespaces




13 years ago
6 years ago


(Reporter: smaug, Unassigned)



Firefox Tracking Flags

(Not tracked)


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:
OS: Windows 2000 → All
Namespace information should be able to get also from nsIContent.

Comment 2

13 years ago
*** 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

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.

Comment 5

13 years ago
Won't this be solved, eventually, when 'xml:id' becomes a standard?
Hardware: PC → All
<html:div id="foo" xml:id="bar"> ?

Comment 7

13 years ago
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 (and 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:
The new attribute is in X+V namespace, see the DTD or 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:

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
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.
Depends on: 275196
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:
Ever confirmed: true
I vote for WONTFIX here (and in bug 275196, for that matter).
Assignee: general → nobody
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.