- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 20 Jun 2008 20:26:19 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5772
Rob Burns <rob@robburns.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|NEEDSINFO |
--- Comment #5 from Rob Burns <rob@robburns.com> 2008-06-20 20:26:18 ---
(In reply to comment #4)
> Rob, we cannot relax the uniqueness requirement for id attributes because it
> defeats the entire purpose for which they were designed.
Nothing I'm proposing defeats the purpose for which id attributes were
designed. Quite the contrary. What I"m proposing enhances what id attributes
were designed to do.
> Although we do need
> to define how to handle duplicate ids, making duplicate ids conforming is not a
> sensible thing to do.
What I'm suggesting is changing the rules for what a duplicate id means and I"m
not suggesting we make duplicate ids conforming.
> 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.
Not if we specify well-defined behavior.
>
> (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?
Id persistence is a goal for all of the reasons you already mention and mention
below as well: without persistence there's no way for getElementById or CSS ID
selectors to work.
> > * 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.
You get too hung up on DTDs. The id attribute takes a value of a particular
type. It's not a date, it's not a stylesheet, it's not a length. The fact that
the draft does not yet address what data type it is doesn't somehow mean that
the attribute takes a value of no particular data type.
>
> > * 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.
It is completely false that xml:id cannot be used in the text/html
serialization. We haven't specified what it means, but there is nothing about
the text/html serialization that would prohibit us from doing so. Therefore it
is not at all contradictory to make set the following objectives:
* make XML serialized HTML work well with other XML vocabularies by using
xml:id
* make the two serializations of HTML consistent by adopting xml:id ID values
for both
* find something useful to do with @id that is both compatible with existing
content and fulfills a need authors have for uniquely identifying fragments
without requiring document wide unique values.
> 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.
Well for XML serialized HTML documents, and compound documents especially, it
would be quite useful to make HTML fit in with other vocabularies. The
backwards compatible part is a red herring here since what I'm proposing is
certainly compatible with exiting content and of course it is not compatible
with existing UAs because it is a proposed feature enhancement.
> > * 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.
HTML5 could certainly specify how getElementById handles duplicate IDs for
HTML. Presumably text/html would follow a more gentle error handling than XML
might follow for the same errors.
>
> > * 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.
Stripping or modifying id attribute values is not a solution to the problem. To
me it is a much more radical solution to say "who cares whether the ids stay
the same and remain persistent, just change them or removing them". The
authoring tool would have to check all embedded and linked scripts and
stylesheets to update the id values there. And depending on the nature of the
authoring tool, there may be other scripts and stylesheets that are not
currently attached to the document and so stripping and modifying IDs breaks
the document.
> > * 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?
Because one can use the same attribute from the same vocabulary (and namespace
in this case) to get a document-wide unique handle on elements. Perhaps SVG,
MathML and others could then migrate their id attribute in the same way I
propose HTML5 migrate its id attribute.
> > * 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.
>
It just means we have an opportunity to help shape how xml:id is handled by
implementations and authored by authors. The usage of these attributes are not
so set in stone as other features of HTML or XML.
> > * 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.
I do not think error handling for getElementById is outside the scope of the
HTML5 recommendation. Also, we have an opportunity to specify that error
handling in a way that makes the id attribute more useful than it already is.
--
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 20:26:59 UTC