[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 #11 from Lachlan Hunt <lachlan.hunt@lachy.id.au>  2008-06-22 11:48:28 ---
(In reply to comment #5)
> (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.

The purpose of the id attribute was to be a document-wide unique identifier. 
As I understood your proposal, you want to relax the uniqueness requirement to
some extent.  I fail to see how that doesn't defeat the purpose.

> What I'm suggesting is changing the rules for what a duplicate id means and I"m
> not suggesting we make duplicate ids conforming.

Now I'm really confused.  I really not sure what you're proposing now, since
that seems to contradict other statements you've made.

>> 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.

Specifying well-defind behaviour for gEBId, which needs to be done anyway,
doesn't address the problem I raised of it still only returning a single
element.  This is a problem for your proposal because if a script depends on a
particular ID, and then it is duplicated elsewhere in the document, it could
potentially cause it to match the wrong element.

>> 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.

But if we look at the common aggregation use case, which is typically done for
syndicating blogs (e.g. PlanetHTML5), then the aggregated content usually
doesn't come with all associated stylesheets and scripts.  The styles typically
come from the host document.

> 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 draft adequately defines the allowed values.  It just doesn't define it in
terms of a specific data type.  The nearest concept that HTML5 has to data
types is the microsyntax section, which mostly deals with values that have
special parsing requirements.

> It is completely false that xml:id cannot be used in the text/html
> serialization.

Please refer to the recent aria discussion about colons in attribute names and
namespaces to understand why xml:id won't work well in text/html.

>>  We should not add xml:id to the HTML serialisation...
>
> Well for XML serialized HTML documents, and compound documents especially, it
> would be quite useful to make HTML fit in with other vocabularies.

Please explain why xml:id is better than simply using id, and how it makes it
"fit in with other vocabularies".

> 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.

No, because this spec doesn't define getElementsById.  It is a separate
specification that needs to define its own behaviour.

>>>  * 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.

>From an authoring perspective, why does the namespace help this in any way
whatsoever?  For HTML, SVG and MathML, authors can already use the id attribute
on all elements, use ID selectors and getElementById in the same way for each
language, and things aren't unnecessarily complicated by namespaces.


-- 
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 Sunday, 22 June 2008 11:49:06 UTC