- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 20 Jun 2008 14:28:57 +0000
- To: public-html-bugzilla@w3.org
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