- From: Robert Burns <rob@robburns.com>
- Date: Wed, 1 Aug 2007 10:54:26 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: HTML WG <public-html@w3.org>
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 UTC