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

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 #12 from Rob Burns <rob@robburns.com>  2008-06-25 12:33:37 ---
(In reply to comment #11)
> (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.

No, I want to strengthen uniqueness by changing the scope of the uniqueness
(and also strengthen persistence). In contrast, you're the one advocating for
matching multiple duplicate IDs for CSS and DOM APIs. In my proposal the
likelihood of non-unique id attributes declines substantially.

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

Let me repeat this in capsule form:
 * authors use xml:id with an ID data type (or a value consistent with an ID
data type if you don't like the use of the term "data type")
 * authors use id attributes with an IDENT data type unique among all its
siblings (of course in legacy content and future content, authors can continue
to take steps to ensure the id attributes are unique document-wide if that's
their preferred authoring practice)
 * duplicate xml:id=ID would cause fatal errors (as much as I know you have a
knee jerk reaction against that it has its place and it reinforces the pattern
already familiar to authors where xml implies fatal error)
 * duplicate id=IDENT would also be an error, but would me much less likely to
occur

That's still not two lines as Hixie requested, so how about:

 * facilitating easier authoring of unique and persistent identifiers that can
be scoped from scripts and stylesheets upon aggregation

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

getElementById should return a single element. That's the result of requiring
uniqueness. If you say you're for uniqueness but you want a DOM method to
return multiple duplicates you're undermining the uniqueness with confusing
error handling.

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

HTML5 proposes making styles scoped. How will a scoped stylesheet with id
selectors work? You also are way to focussed on traditional web browsers. Every
time a user pastes content into an editor, they are aggregating content.
Persistence should at least be easily achievable for the authors that want to
pursue that approach. It doesn't mean you can't change your id values every day
if you want, every time you get a whim to do so go right ahead.

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

Well perhaps id attribute values should have a little more definition too. For
example, do we want to permit “<form id='#'>”?

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

I'd rather not. The participants in that discussion simply added
misunderstanding upon misunderstanding. What I would suggest is that xml:id be
added in the xml namespace (even in the text/html serialization). However, in
any event the namespace use of a colon was designed to be completely compatible
with non-namespaced processors so the tag name remains “xml:id” whether
processed by an namespace aware implementation or not.

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

Because the other vocabularies are xml and xml:id is an attribute encouraged
for use with these vocabularies. Also using id wouldn't address this proposal
since one attribute cannot take a value that is both document-wide unique and
not document-wide unique.

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

However, HTML5 has to define what the ID data type is for it to work with that
method. The method getElementById (not getElementsById) is not asking for the
element that has an attribute called “id” with the value passed as an argument.
The method asks for the element with ID an value (whatever attribute carries
those values) whose value matches the argument. That could be “<element
lachy='value'>” It is up to the document specification to determine where an
element ID comes from.

So for an HTML5 document with two elements both sharing the same value of the
id attribute it is certainly within our scope (or even required) that we
specify which one of those values is an ID and which one is not (or that they
both are if that's what you're saying you prefer).

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

Again, you're missing what this bug is about. The id attribute cannot be two
things at once. xml:id makes sense to provide a more strict attribute for ID
values. I'd be fine if you want to call the new attribute ”lachy”. However, as
an aside  I still don't understand this irrational distaste for 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 Wednesday, 25 June 2008 12:34:15 UTC