A Problem With Link Relationships

Published on Dec 23, 2022 (updated Dec 1, 2024), filed under development (feed). (Share this on Mastodon or Bluesky?)

Álvaro Montoro just wrote a detailed post about the rel attribute, A Theory of Web Relativity. It suggests to make more use of rel.

I didn’t set out to write about rel (I didn’t set out to write anything, really, with too much to do before and over the holidays). But there’s something about rel that Álvaro doesn’t mention, but that needs mentioning.

It’s the toll on maintainability, by linked resources outside of one’s control.

rel has many important and useful values—see Álvaro’s post—, but also (like its old counterpart, rev) many values that are notoriously difficult to maintain.

What’s the Problem?

First, we need to be sure we use the rel attribute correctly. With something like style sheets, that’s straightforward, but in other cases, it’s not. Still, let’s assume correct use.

Then, we need to make sure we keep it up-to-date.

This is where problems can begin, as with invisible information, this is traditionally harder. We don’t have enough exposure to this kind of metadata to even know it’s there.

With invisible information on resources outside of one’s control (as with external links and resources), keeping link relationships up-to-date requires regular effort, which makes it more costly.

(Take link rot and that after 5–10 years, 65–70% of links aren’t working anymore. That is, we’re already bad at managing links—keeping invisible link relationships up-to-date is an even more difficult ask.)

With invisible information about changing types of relationships (as with XFN) on resources outside of one’s control, upkeep is essentially impossible to sustain.

That is, for a rel for a style sheet or feed, there isn’t much of a problem. The resource types don’t change and the relationships themselves don’t, either. For author information or tags, the ground starts moving. If pointing to something external, there is an increased chance these link relationships need attention. For neighbors or crushes (XFN), which almost certainly are external and very likely to change, we have the finger not on but in the wound.

Therefore, yes, enriching documents with more metadata, using rel, has benefits, some of which we do claim and some of which we can claim. But maintaining this kind of invisible information for anything that can change, over the years, is so difficult, it won’t just be a problem for more use of rel—it already has been a problem for use of rel. (XFN is cool but—this is why no one is making full use of it.)

If You Still Choose to Make More Use of rel

For an HTML minimalist (did you check my latest book? I love minimal HTML), this is enough to stay far away from many applications of rel that involve external resources (especially XFN).

But if you’re not a minimalist and you either deal with more maintainable use cases, or are still not concerned about maintainability, what can you do?

I tested ChatGPT for this (why not, this is 2022)—and it offered two interesting recommendations that I will share as is (I really need to get going).

Document the use of the rel attribute: It is a good idea to document the use of the rel attribute on a website, either in a separate document or as part of the code base. This can help developers understand the intended relationships between different elements on the page and ensure that the rel attribute is used consistently.

Use the rel attribute sparingly: While the rel attribute can be useful for conveying relationships between elements on a page, it is important not to overuse it. Using too many different values or using the attribute unnecessarily can make it difficult to maintain and understand the relationships between different elements on the page.

Avoid letting link relationships become a maintenance sink.

See you for one or two more posts this year but other than that—happy holidays!

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)