A Bit of a Cleanup ⁂ starbreaker.org

I’ve made some changes to my website involving link preview meta tags, stylesheets, and webmentions for IndieWeb compatibility. I’ll discuss them in slightly more detail below, in preparation to update my website’s colophon.

link preview tags

I had ceased to support Twitter Card meta tags several weeks ago, and now I have removed all support for Open Graph meta tags as well. This will most likely result in links published to social media not having preview images any longer.

My website does still provide a preview image, but it is implemented by the following means.

<title>home | starbreaker.org</title>
<meta name="description"
      content="rock operatic speculative fiction 
               (and more) by Matthew Cambion" />
<link href="https://starbreaker.org/index.html"
      rel="canonical" />
<link href="https://starbreaker.org/feed.xml"
      rel="alternate"
      title="starbreaker.org RSS: Full Text"
      type="application/rss+xml" />
<link href="https://starbreaker.org/headlines.xml"
      rel="alternate"
      title="starbreaker.org RSS: Headlines Only"
      type="application/rss+xml" />
<link href="https://starbreaker.org/social.png"
      rel="preview"
      width="1080"
      height="1080"
      type="image/png"
      alt="link preview image for 
           parasocial media silos" />

an alternative to Twitter Card and Open Graph preview tags using standard HTML <head> elements

As far as I’m concerned, these elements in <head> should be quite sufficient for social platforms like Twitter, Facebook, Mastodon, and Friendica to generate a link preview without the use of platform specific tags. Furthermore, <link rel="preview"> has precedent in the Atom Activity Streams v1.0 specification from 2011. This one tag eliminates the need for separate tags representing a link preview image’s URL, height, width, and text description, and neither Open Graph nor Twitter Cards request a MIME type.

Will platforms render link previews using the tags I provided? That’s not my problem. As I wrote back in January in “RE: Does a Blog Need to Integrate?”:

It is not a website operator’s job to integrate their website with external services.

I was originally talking about feeds in the context of the expectation for static websites to support ActivityPub:

As far as I’m concerned, the integration of websites with external services is a solved problem. We have RSS. We have Atom. For Nyarlathotep’s sake, we even have JSON feeds. What more do you people want?

I have come to think the same of link preview images for social platforms. I see no need for platform-specific tags.

Need to specify a page’s language? The <html> element has a lang attribute.
Does the page contain most of its content as audio or video? Why not <link rel="audio"> or <link rel="video"> with the appropriate MIME type?

Why do all of this? I stripped out the Open Graph tags for the same reason I dropped Twitter Cards support. Neither Elon Musk nor Mark Zuckerberg are paying me to support their platforms.

CSS stylesheets

I had had my own custom stylesheet, but I decided that Kev Quirk’s Simple CSS better suited my needs, though I still have a smaller custom stylesheet to customize colors and do stuff like remove the border from <article>. I probably could have styled my own tables, but I couldn’t be bothered.

webmentions

I had implemented a script to receive incoming webmentions but never got around to implementing a script for compiling and transmitting outgoing webmentions. It doesn’t seem worthwhile to keep around a half-assed implementation of an IndieWeb feature that is likely to become a spam vector, so I scrapped it. If I really want somebody to know that I linked and quoted something on their site I’ll email them. Other website operators are welcome to email me for the same reason.

WebP and AVIF support

I’ve been using the <picture> element to serve WebP and AVIF formats to compatible browsers while providing a fallback to JPEG and PNG for old browsers. However, all of the major browsers (Chrome, Firefox, and Safari) support AVIF. Microsoft Edge apparently doesn’t, despite being based on Chromium. I had been thinking of adjusting my scripts and makefile to make this website service only AVIF images, but I might switch to serving only WebP images instead without any fallback to JPEG and PNG since Edge supports WebP but not yet AVIF (despite being based on Chromium, the FOSS code with which Chrome is built).

I’m not going to make this change yet; I want to think this through so that I don’t break shit because of a dumb mistake.