What is the bug? I'm trying to create targets for A
links earlier in the same document, and I can't do it with:
| Our first inclination was to simply write:
| <DT><CODE><A NAME="4MvVSWBSRpF84aK"></A>href</CODE>
| but this excercises the aforementioned "bug" in Mosaic.
|
| Perhaps we need a NOTE in the spec about this...
Well, if one wants to write docs that work right with Mosaic now,
they will not conform to the present DTD on this point. That
seems wrong for a DTD meant to document current practice.
It seems to me that we must make legal the only form that Mosaic
accepts for A as a target, and warn users that parsing against
the DTD will not assure them that A's intended as links actually
have content, as is desired.
| >(However, as NAME will eventually become an ID, the value of NAME
| >given here, starting with a number, will become dysfunctional,
| >because IDs must begin with a letter; how about knocking that 4 off
| >the start of it and any others of the sort?)
|
| I don't think NAME will ever become an ID attribute. It's just
| not practical.
So we'll never be able to use SGML's ID/IDREF functionality?
| Perhaps we'll deploy ID attributes (and call them ID, not name).
I would deprecate the creation of attributes named ID that were defined
as CDATA (as NAME is now). That could create a lot of confusion.
| I think the A tag is badly overloaded: it's the source of an anchor,
| or the destination. It's used for footnotes, references within a
| document, references across documents in the same "corpus," references
| across corpuses, etc.
|
| I'd prefer to replace A as the destination of a link by allowing any
| number of elements to take an ID attribute (ala HTML+). I think it
| would be useful to have some sort of link that uses ID/IDREF
| attributes so that an SGML parser could be employed to check those
| links. It might also be useful to indicate whether a link is to
| something in the same "corpus" or to something in a vastly different
| context, though it's not clear that we need special markup for
| that. Perhaps that's the job of the author.
So you want links to CDATA values and links to ID values?
If you just define HREF as an IDREF, then allow any element to have an ID,
you have the problem solved, except that it makes obsolete docs with
NAME values that start with a number, due to woodenheadedness on the part
of the SGML committee.
On the other hand, maybe HTML is a good opportunity to force change
in this ridiculous restriction!
| Anyway... none of this will happen in the near term...
Certainly true about CDATA/ID.
| >So the content model should be changed to:
| ><!ELEMENT A - O %A.content -(A)>
| So you're advocating allowing folks to omit the </A> tag.
| Murry, Eric Sink, and myself have all said "yuk," but nobody
| has raised any technical objections.
Well, my point is a sort of technical objection to *not*
omitting the end tag: if you don't allow its omission, you can't parse
the format Mosaic requires. I'm not defending the design or
Mosaic, only trying to validate my docs.
-- Terry Allen (terry@ora.com) Editor, Digital Media Group O'Reilly & Associates, Inc. Sebastopol, Calif., 95472