Last Comment Bug 258238 - Support for ID attributes with namespaces
: Support for ID attributes with namespaces
Status: NEW
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- enhancement with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: 258237 (view as bug list)
Depends on: 275196
  Show dependency treegraph
Reported: 2004-09-07 01:35 PDT by Olli Pettay [:smaug] (TPAC)
Modified: 2011-09-03 03:48 PDT (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Olli Pettay [:smaug] (TPAC) 2004-09-07 01:35:02 PDT
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:
Comment 1 Olli Pettay [:smaug] (TPAC) 2004-09-07 02:10:42 PDT
Namespace information should be able to get also from nsIContent.
Comment 2 Anne (:annevk) 2004-09-07 02:21:45 PDT
*** Bug 258237 has been marked as a duplicate of this bug. ***
Comment 3 Olli Pettay [:smaug] (TPAC) 2004-09-07 02:27:01 PDT
Or am I wrong here. If someone needs namespace ID attribute he can implement

Hmm, how did I create that duplicate.
Comment 4 Boris Zbarsky [:bz] (TPAC) 2004-09-07 09:32:55 PDT
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 Anne (:annevk) 2004-09-07 09:36:58 PDT
Won't this be solved, eventually, when 'xml:id' becomes a standard?
Comment 6 Boris Zbarsky [:bz] (TPAC) 2004-09-07 09:46:42 PDT
<html:div id="foo" xml:id="bar"> ?
Comment 7 Anne (:annevk) 2004-09-07 09:54:33 PDT
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?
Comment 8 Hixie (not reading bugmail) 2004-09-07 10:01:53 PDT
Why can't an element have more than one ID? Am I missing something?
Comment 9 Boris Zbarsky [:bz] (TPAC) 2004-09-07 10:05:57 PDT
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...
Comment 10 Hixie (not reading bugmail) 2004-09-07 10:11:12 PDT
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.
Comment 11 Olli Pettay [:smaug] (TPAC) 2004-09-07 10:12:14 PDT
X+V adds a new ID attribute to VoiceXML fields:
The new attribute is in X+V namespace, see the DTD or field element.
Comment 12 Boris Zbarsky [:bz] (TPAC) 2004-09-07 10:15:38 PDT
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...
Comment 13 Hixie (not reading bugmail) 2004-09-07 10:22:25 PDT
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. :-)
Comment 14 Boris Zbarsky [:bz] (TPAC) 2004-09-07 10:28:29 PDT
> 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.
Comment 15 Johnny Stenback (:jst, 2004-09-07 10:33:43 PDT
FWIW, the DOM Level 3 Core spec defines a way to flag any attribute as an ID, see:

and friends...
Comment 16 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2004-09-07 11:14:39 PDT
(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.
Comment 17 Boris Zbarsky [:bz] (TPAC) 2004-09-07 11:37:47 PDT
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
Comment 18 Jonas Sicking (:sicking) No longer reading bugmail consistently 2004-09-12 10:19:53 PDT
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.
Comment 19 Gervase Markham [:gerv] 2005-09-27 02:09:28 PDT
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:
Comment 20 Hixie (not reading bugmail) 2006-10-24 12:30:14 PDT
I vote for WONTFIX here (and in bug 275196, for that matter).

Note You need to log in before you can comment on or make changes to this bug.