- From: Jukka Korpela <Jukka.Korpela@hut.fi>
- Date: Mon, 01 Jan 2001 22:56:31 +0200
- To: www-validator@w3.org
On Sun, 31 Dec 2000 21:27:40 +0900 (JST), Masayasu Ishikawa <mimasa@w3.org> wrote: >- Recent versions of Amaya, iCab, Internet Explorer, Lynx, Netscape, > Mozilla, Opera, w3m, ..., all support "id". I might miss something, but e.g. Netscape 4.51 on Win98 does not seem to support "id" for local links (href="#foo" in a document which has id="foo" somewhere). Perhaps it's not recent enough? > Use of the "id" attribute as fragment identifier is compatible with > XPointer's bare-name shorthand [2], while the "name" attribute is not. I had thought that the fundamental reason was that "id" is declared as taking ID value, thereby imposing specific syntax and uniqueness requirement on it, whereas "name" is declared as CDATA, i.e. anything goes. This allows some more errors to be caught in validation. So in a sense, the change from "name" to "id" fixes an original design flaw - but if you ask me, it would be better to wait for stable and reliable support in browsers before generally recommending that authors use "id" (only). >Also note that in the XHTML Basic specification, the "id" attribute is >NOT used on the "a" element, but on other elements like "h2" and "dt". Is there any particular reason not to allow "id" for "a"? If "id" is to serve the purpose of indicating _any_ element as a potential destination of links, why exclude "a"? -- Yucca, http://www.hut.fi/u/jkorpela/ Qui nescit tacere nescit et loqui
Received on Monday, 1 January 2001 15:58:33 UTC