- From: Leif Halvard Silli <lhs@malform.no>
- Date: Sat, 31 Jan 2009 00:24:39 +0100
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: Robert J Burns <rob@robburns.com>, HTML WG <public-html@w3.org>
Boris Zbarsky 2009-01-30 22.32: > > Robert J Burns wrote: >> You're honing in on what I was talking about now. There are reasons to >> have an element that says this is here solely as a anchor destination. >> A 'span' with an 'id' attribute might be there for some particular CSS >> hook. However, a phrase wrapped in an "a" with only an 'id' and no >> 'href' is clearly an anchor destination. > > I guess I'm at a bit of a loss to think of a situation where something > is solely an anchor destination without having any other semantics. In Wikipedia (e.g. see http://en.wikipedia.org/wiki/Anchor ) you find things like this: <p><a name="Anchoring_gear" id="Anchoring_gear"></a></p> When you look at the code, you are in no doubt of the purpose of that element there: it is solely there for the purpose of linking to it. > Anything I can think of linking to directly as part of a document > (sections, images, lists, tables, <pre> blocks with program code, > quotations, etc) all have appropriate semantic tags that one would need > around the thing being linked to anyway... At that point, it might be > more clear to put an ID on said semantic tag and use that as the anchor > destination. > > Maybe there are situations I'm just failing to think of here? May be - I speculate - it is more easy to add an empty anchor element rather than manipulating the id of a container element? After all, in Wikipedia, the id-refs, and hence the links, will change very very often. [ I only have one HTML editor available that is able to automatically coordinate id attributes (of h1-h6 elements) with a ToC, and that is Amaya. So may be there is some problem there ... ] Also, if I want a place to be a destination anchor, without having to investigate or find out (it may be impossible to know the content of the A element if it is generated via DOM etc) the *further* semantics of the anchored resource, then I can use <a id="ref">resource</a> and be certain that I have at least not lied plus that I solved a practical problem. >> Similarly any id can serve as a anchor destination, but an 'a' element >> with an 'id' alone is clearly an anchor destination. This is signaled >> to any other authors of the document in a way that a 'span' element >> with an 'id' attributes does not signal. > > While true, it also leads to this fairly common HTML4 authoring pattern > (with name replaced by id on the <a>): > > <a id="mytable"></a> > <table><tr><td> > This is an important table that people should link to > </td></tr></table> > > both because authors copy/paste from existing HTML (which is informed by > the HTML 3.2 legacy of not being able to link to IDs) and because the At least copy-paste is not the reason in Wikipedia. > spec gives <a> a privileged status as an anchor destination that > obscures the fact that any element can be an anchor destination if > that's what you're really meaning to link to. I cannot really agree that HTML 4 gives a privileged status to the A element. Except for the way that name="" allows the full unicode "alphabet" to be used as name content. HTML 5 will be based on IRIs, so that there is no reason for using name="" for that reason anymore. That is a element that is singled out for one purpose has nothing to do with "privileged status". > Note that the above example would break badly if someone happens to > apply a style that positions the table away from the anchor. So it's > not just a matter of semantic purity being violated (thought it most > certainly is), but of practical consequences that make the document less > robust than it could be. However, if I have gotten it right, in HTML 5 it will be non-conforming to e.g. write <body><inline-elemetn></inline-element></body> (or has that idea been left?) >> It is dropped from document conformance. The use of an 'a' element >> with only an 'id' attribute that is also relevant is not supported in >> the current HTML5 draft (but it has been supported in XHTML1.1, >> XHTML1, HTML 4.01, so why are we changing it?). > > I agree that this is a good question. It seems to me that while the use > of such an <a> should be conformant, it should be given no special > status as an anchor destination, for the above-described reasons. How would you take away the special status, I wonder ... After all, it only has two purposes - anchored link or link anchor. -- leif halvard silli
Received on Friday, 30 January 2009 23:25:21 UTC