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

On 8/1/07, Robert Burns <rob@robburns.com> wrote:
> On Aug 1, 2007, at 9:01 AM, Jim Jewett wrote:

[It would be OK to _explicitly_ just delegate to another standard,
such as xml or Unicode appendix 31, which defines identifier syntax --
http://www.unicode.org/reports/tr31/tr31-8.html]

> > But my recommendation (to document authors) is still to stick with
> > ASCII letters of a single case plus (non-initial) digits.  ...

> I see what you're saying here now. I think I would rather see
> something like this addressed through one of the "green' notes.

Putting it in a Green notes would be fine.

> Something like:
>
> "Note: Authors should be aware that some legacy tools may not handle
> Unicode characters outside the ASCII rang properly when processing
> IDs. For maximum compatibility authors should stick with ASCII only
> characters in producing a value for the @id attribute."

Slight rewording to

"Note: Authors should be aware that some tools may not handle all IDs properly.
For maximum compatibility, authors should use IDs starting with an
ASCII letter, containing only ASCII letters and numbers, and
containing only a single case (upper or lower) of letter."

> In this way we let authors know about wearing seatbelts. However, we
> don't make it seem like we endorse the continued poor state of the
> tools. ... After all many of those maturity issues may be fixed
> even before we go to CR status.

It isn't just legacy tools that will get this wrong.

Many tools written primarily for something other than HTML5 will
continue to be used with html, simply because they are available and
familiar.  Other languages (including xml and html 4) have different
rules.

Even new (but simple or homegrown) tools written explicitly for use
with html5 will often get this wrong, because people will continue to
assume the "obvious" constraints on an ID.  (Depending on their
previous experience, they may disagree about what those constraints
are, but they won't always think to remove the constraints.)

-jJ

Received on Wednesday, 1 August 2007 22:04:31 UTC