phil ringnalda

(For some reason, I left this as a draft when I wrote it last May, inspired by Atom autodiscovery. Sure, it’s unclear, and argues for things that I wish weren’t true, but if I let that stop me I’d write even less. Since WordPress will keep nagging me until I either publish it or delete it, publish it is.)

While I’d read them all before, I hadn’t ever looked at the sections of the various HTML specs and recs dealing with the rel attribute of a and link elements all in one sitting before. It’s interesting, if not very instructive.

HTML 1: Like DOM 0, HTML 1 didn’t really exist beyond the rough intersection of how people were doing things. Still, draft-ietf-iiir-html-01.txt is a useful glimpse of HTML as it started toward formal standardization. Both A and LINK had optional REL attributes, whose values were described in a non-normative section as something the authors hoped would be registered by IANA, with unregistered values being preceeded by X-. The listed values included such things that make nofollow seem a model of relationship semantics as USEINDEX, EMBED, and PRESENT (meaning a user agent shouldn’t present the document without also presenting that linked document).

HTML 2.0: The first HTML spec to make it through standardization, it backs far, far away from the previous fixed list with precise meanings, saying only that The semantics of link relationships are not specified in this document.

HTML 3.2: Notable as both the first W3C HTML spec (2.0 was an IETF RFC, rather than a W3C Rec), and as the most heinous use of a paint-splatter background image in a specification that people still read today, HTML 3.2 showed only a little advance from 2.0 in rel values, saying HTML link relationships are as yet unstandardized, although some conventions have been established.

HTML 4.01: Depending on how you handicap the WHAT-WG’s chances, the HTML. For the most part unchanged since 1997, it still defines element meaning in XHTML. The section on link types is fitting for something that would be the only source of authority for anyone arguing about such an abstract thing for so many years. Attribute values are presented with their conventional meaning, so that anyone who wants another interpretation can say that it’s only conventional, not prescriptive, and can say that saying user agents may interpret these link types in a variety of ways means that they have only the shared meaning of any two people who happen to agree (or, given the spec’s focus on search engines, between a search engine and the authors who write markup tailored to it).

Unlisted attribute values are allowed, but should be defined in a profile attribute, one of the clearest indications that the HTML 4 authors didn’t feel that they were done yet. The value of the profile attribute is a space separated list of URIs, where only the first one counts. It may be recognized, or dereferenced, getting… something that then… something something. The first URI in the list acts as a namespace, not only for rel values but also for the value of the scheme attribute on meta elements, so that the true meaning of <meta name="ambiguous" value="very"> is determined by both the scheme="not" attribute, and the profile="http://inmyworld.com/ http://notinyours.com" attribute. Had the world turned differently, I bet HTML 4.5 would have kicked some semantic relationship butt.

Just to give strict constructionist semanticians as much pain as possible, along with a few non-prescriptive examples of rel="alternate" with hreflang="..." for the current document in another language, the spec has exactly one prescriptive use of link with rel="alternate", where alternate stylesheets combine two separate rel values to mean that alternate applies not to the linking document, but to the other value. Makes for quite a bit to hand-wave away, if you want to say that rel="alternate" means exactly what you want it to mean, and nothing more.