W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: ID Characters (was: Re: 3.4. Global attributes)

From: Robert Burns <rob@robburns.com>
Date: Wed, 1 Aug 2007 10:54:26 -0500
Message-Id: <4F9F6026-C87E-4FE0-9B39-E46A9BFCA62F@robburns.com>
Cc: HTML WG <public-html@w3.org>
To: Henri Sivonen <hsivonen@iki.fi>


On Aug 1, 2007, at 10:34 AM, Henri Sivonen wrote:

>
> On Aug 1, 2007, at 18:18, Robert Burns wrote:
>
>> On the issue of the @id attribute and compatibility, I'm not sure  
>> what we're trying to accomplish here. Henri says[1] that the  
>> attribute is of type CDATA and not of type ID
>
> That's not quite what I said.
>
> I said that it is not of type ID as far as the XML Processor (that  
> is, the XML parser as defined by the XML 1.0 spec) is concerned  
> when there is no DTD declaring the attribute id to be of type ID.  
> Between the XML parser and later stages of processing, you do want  
> to assign IDness to id. I propose acknowledging this explicitly in  
> the spec and calling the processing stage an "XHTML id Processor".  
> This is analogous to how xml:id gains its IDness after the XML  
> Processor in the DTDless case.
>
> (What I said above holds regardless of what lexical space is  
> allowed for the id attribute.)

I think you're raising a completely different issue from what I'm  
trying to address.

First, I'm just trying to understand what the draft says and is  
trying to accomplish with regard to @id. If that involves changing  
its data type, I'm not sure that's necessarily a bad thing. Second,  
my concern is just how that (or other HTML5 norms surrounding @id)  
effects our compatibility with HTML4 and XML1. Certainly saying @id  
takes type CDATA makes us conforming with XML1 (though now breaking  
with HTML4). It also may confuse authors and UA developers who might  
expect an @id attribute to take an ID data type. And if all we're  
trying to accomplish is to add numbers to the start character —and a  
few even more minor enhancements — to what is supposed to be an  
opaque string anyway, then I'm not sure it's worth the potential  
compatibility headaches.

Take care,
Rob
Received on Wednesday, 1 August 2007 15:54:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:03 GMT