[Bug 5772] ID value types too restrictive and inflexible for some use cases

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5772





--- Comment #4 from Lachlan Hunt <lachlan.hunt@lachy.id.au>  2008-06-20 14:28:57 ---
Rob, we cannot relax the uniqueness requirement for id attributes because it
defeats the entire purpose for which they were designed.  Although we do need
to define how to handle duplicate ids, making duplicate ids conforming is not a
sensible thing to do.

The getElementById() method is designed for returning only a single element. 
This makes it significantly harder to work with those elements in the DOM. 
Additionally, fragment identifiers in URIs can only point to one element in a
document, which makes duplicate ids rather useless from an end user
perspective.

(In reply to comment #0)
> * The goals of maintaining document-wide uniqueness for IDs and also achieving
> ID persistence are at odds with one another (for example consider pasting
> content, and other aggregation of content)

When it comes to content aggregation, why is id persistence considered a goal?

>  * Authors may want to uniquely identify an element without desiring the
> strictness of the ID data type

That does not make sense. How can you uniquely identify something without
enforcing the uniqueness requirement?  Additionally, why is the ID data type
relevant in the context of HTML 5?  HTML 5 is not defined in terms of a schema
language or DTD, and in particular, the definition of the id attribute makes no
reference to being of type ID.

>  * The xml:id attribute already provides an attribute taking a value of type ID
> and only one such attribute is permitted in the XML serialization of HTML5
> (though it could potentially be used in both serializations)
>  * Authors want consistency between the text/html serialization and the XML
> serialization of HTML5

Those two points seem contradictory. Since xml:id cannot be used in the HTML
serialisation, but id can be used in both, it seems the best way to achieve
consistency is to continue using the id attribute as a unique identifier in
both.  We should not add xml:id to the HTML serialisation because it's not
backwards compatible, and it doesn't even have wide support in browsers for
XHTML.  xml:id is only ever useful for cases where generic XML processing is
used and ID matching is required, but where there is no knowledge of HTML
semantics within the tool.  Note that such cases are rare.

>  * Authors and authoring tools already produce documents without carefully
> checking the uniqueness of ID values (even within XHTML and XML documents)
> within the document of the uniqueness of type ID attributes on each element, so
> HTML5 should clearly define interoperable norms for matching such errant IDs,
> including matching for:
>     - the CSS id/ID selector.
>     - DOM id related methods (getElementById).

Authoring tools that produce such documents are non-conforming.  However, I
agree that error handling needs to be defined.  As far as the ID selector is
concerned, Selectors already defines this adequately (#foo matches all elements
with an ID of foo, regardless of uniqueness).  It is the responsibility of the
DOM specification to define how getElementById deals with duplicate IDs, though
it is a well known issue that it currently doesn't.  However, we currently lack
the necessary resources to rewrite the DOM spec and fix all of its issues, but
this is an issue for the WebApps WG, not the HTML WG.

>  * Authors want a way to aggregate content such as articles from different
> sites or articles from the same site in a way that does not cause ID collisions
> nor id attribute collisions.

This is a valid use case, but I believe the appropriate solution lies with the
authoring tools and CMSs that perform the aggregation, to check for id
attributes and either strip or modify duplicates.

>  * Authors want to mix arbitrary vocabularies in compound documents that make
> use of xml:id as a cross-vocabulary/cross-namespace ID-valued attribute.

I'm not sure how that is relevant to your proposal.  I'm also not sure what the
problem is solved by that solution, nor what evidence you have to support your
claim that authors want it.  Since (X)HTML, SVG and MathML all have their own
id attributes, why would xml:id be at all useful for such documents?

>  * While including ids in hand-coded HTML can be cumbersome and therefore
> authors are likely to include them only for some direct and immediate need,
> authoring tools can easily add auto-generated id values to elements or elements
> of a particular type. However to ensure document-wide uniqueness, such id
> values may end up being difficult to read and type accurately, difficult to
> distinguish, and long.

I'm not sure how your proposal addresses this issue, and it's not clear whether
or not this is a real problem to solve.

>  * The usage of xml:id is still in its infancy and now is the time to shape its
> usage and treatment by common UAs.

Again, I'm not sure how that is relevant or what you mean by it.

>  * Unique id attribute value violations are common place and so clear
> interoperable processing guidance needs to be provided when id attribute value
> collisions do occur

Agreed, and aside from the aforementioned getElementById issue, which is
outside the scope of HTML5, that is already the case.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 20 June 2008 14:29:36 UTC