Three items of note

Since I last wrote herein, three events have piqued my nerdy curiosity, suggesting some appropriate musings on them. The first affects the web development business; the second has to do with a change in how visited links look in some web browsers; and the third concerns a browser extension bug which, for a few weeks, fouled up code blocks in some websites (including this one).

Cloudflare acquihires Astro

Among the tools I’ve used over the years to build and maintain this site, one of the more interesting is Astro. This open-source framework has come a long way since its beta versions, which with I tinkered a few years ago; and, in the process, it’s gained a ton of support among the web dev community. However, that support apparently never translated to a revenue stream that would sustain either Astro itself or the Astro Technology Company which employed a substantial number of the folks behind Astro. The resulting financial shortfall risked Astro’s perhaps becoming abandonware in the not-too-distant future; that would have been a sad ending to a greatly admired project.

As a result, according to jointly released blog posts, Cloudflare has acquihired the Astro Technology Company. Although not all acquihires are good for the object of said events, this one — at least for now — looks like a win-win. Cloudflare gets to own a solid and popular development framework (much like Vercel owns Next.js), and the Astro team gets to keep that framework growing and improving.

Visited links on Blink-based browsers

Turns out I missed a change from last April that affects the color of visited links in a Blink-based browser such as Chrome or Chromium. In the early days of the web, a link you hadn’t yet visited in a given browser would always be a bright blue color (#0000ff) while one you had visited therein would be purplish (#800080). More to the point, a visited link would be that purplish color regardless of which originating page had gotten you there.

For example: if you were on foo.com and clicked a link to bar.com, you would subsequently see that bar.com link in the purplish color on any other page, not just on foo.com, as long as the browser still kept that visit in its history. Of course, over time, websites have gotten a lot more creative about their various link colors but the behavior remained the same.

Or, at least, it did until last April’s release of Chromium 136. Now, with any browser based on that version or later, you’ll “see” the visited link as visited only if that visit came from the site you’re viewing. This change, attributed by Google to the need to firm up browser security, received attention at the time from Bleeping Computer and Tom’s Guide, among other sites.

At this writing, only Blink-based browsers like Chrome and Chromium work this way for visited links’ appearances; it remains to be seen when, or whether, Gecko- and WebKit-based browsers will follow the Chromium project’s lead.

1Password vs. code blocks

Most password management apps have their own extensions for browsers, simplifying the act of entering one’s credentials when necessary. Each such extension injects some additional code into the content delivered to the browser. This usually works without interfering with the appearance of a web page but, for a few weeks last month, such was not the case following an update to the 1Password browser extension.

The problematic version, v.8.11.23.x, totally clobbered the syntax highlighting on some (but not all) web pages with code blocks like this one, which shows a little CSS:

.sitemap-div {
	margin: 0 auto;
	width: 90%;
}

With the buggy extension version enabled, the code block looked something like this, at least on my site:

As for why, here’s an example of what the 1Password bug did to anything from the combination of Hugo and Chroma. This is how a specific code block on one of my Hugo-generated pages is supposed to look in HTML:

<div>
  <div class="highlight">
    <pre tabindex="0" class="chroma">
      <code class="language-plaintext" data-lang="plaintext">
        <span class="line">
          <span class="cl">
            /Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo
          </span>
        </span>
      </code>
    </pre>
  </div>
</div>

. . . and this is the HTML for the same code block after the then-buggy 1Password extension got through with it:

<div>
  <div class="highlight">
    <pre tabindex="0" class="chroma language-plaintext">
      <code class="language-plaintext" data-lang="plaintext">
        /Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo
      </code>
    </pre>
  </div>
</div>

Those missing spans obviously made a lot of difference, as did the insertion of a spurious language-plaintext in the pre element’s class declaration.

As one might expect, the glitch was soon the subject of an active discussion in the 1Password Community Forum, where one complaint after another showed screen captures of how the bug had “massacred their boy,” so to speak. What had happened? Well, based on various comments I read there and elsewhere about the issue, it appears that the buggy version was injecting the JavaScript-based Prism syntax highlighter. The additional code apparently was mistakenly left behind from a particular inter-version development test. Although some sites somehow escaped unscathed, the bug clearly caused styling conflicts with numerous other pages’ own syntax highlighting code.

Despite the 1Password team’s relatively quick acknowledgement of the SNAFU, it took several days¹ before a fix arrived in the form of v.8.11.27.x, first in the Chrome Web Store and later the corresponding “stores” for Firefox and Safari; and not until v.8.12.0 did the release notes mention the fix:

We’ve fixed an issue where the 1Password extension could break syntax highlighting for code blocks on some websites.

Latest commit (61f99f077) for page file:
2026-01-21 at 5:15:10 PM CST.
Page history