brhfl.com

Anchors, away!

My line of work involves a lot of mushing around of the requirements of customers who don’t know the Agency’s style requirements, best practices for web, and CMS limitations into something that comfortably adheres to the preceding rules while still pleasing (or at least appeasing) said customer. Often, folks inexplicably want a handful of tiny, near-zero content pages, when typically we try to present the content together, broken up by headers with IDs. I have to go through quite a few layers to communicate how their requirements will actually manifest, and the technical knowledge is reduced each step of the way.

The term ‘anchors’ comes up in these instances, a lot. I understand that the term makes sense as far as relating something concrete to a structural abstraction – the ‘anchor’ is cast somewhere on the page, and you can just follow the corresponding line (link) to it. I also understand how this came to be from a historical tech perspective – as I understand it, Tim Berners-Lee envisioned a far more bidirectional system of linking, so our <a> (anchor) element would represent something more nodelike, an exit point and an entrance point.

But links don’t work that way on the internet as we know it. The <a> element is probably the least logically named element in modern HTML. But for a while, even though <a> elements still didn’t work that way, we had kind of a hack in place that accomplished the same goal. The HTML 3.2 specification tells us that “[Anchors] are used to define hypertext links and also to define named locations for use as targets for hypertext links”, with the distinction coming from whether an <a> element has an href or a name attribute. It wasn’t until HTML 4.0 that we even had an id attribute to use.

The two uses of the anchor element, while compatible in conjunction with one another (<a href="www.example.com" name="here">) in line with Berners-Lee’s vision, are still semantically very different functions. HTML 4.0 still encouraged the dual-usage, but at least acknowledged these were fundamentally different things, “The A element may define an anchor, a link, or both.” It no longer actually calls <a> anchor, and instead states that the element has two distinct usages. Obviously this is not great as far as semantics are concerned, but more trouble comes when one starts to introduce styling.

HTML 4.0 brought with it the big push for stylesheets, the separation of structure and content. Of course, if you’re styling <a> to look like a link, all of your <a> elements being used as anchors now just appear to be nonfunctional links. The solution wrecked any sense of structural connection between the anchor and the text it represents – simply use an empty <a name="headline"> element in front of your text. This is clearly awful, and with the id attribute now present and sharing namespace with name, entirely unnecessary.

HTML5 still supports this behavior, though recommends against it. Anyone who cares at all about semantics, about accessibility should recommend against it. The CMS I use at work has finally done away with it. And I think that as we slowly come to our senses about this, we should probably just do away with the term ‘anchor’ as well. The attribute is id, the hash in the URL denotes a ‘fragment identifier’. They’re a bit more jargonistic, but these are the terms I always try to use. There’s still a legacy connection between the word ‘anchor’ and the <a> element. And when dealing with folks who occasionally wind up changing things that they don’t really have the background to be changing, legacy language can lead to legacy behavior, as well as making it more difficult to search for help they may need.