The curious case of the code

Volume 9, Issue 36; 29 Dec 2025

The behavior of some versions of some browsers on some platforms changed in the last week or so. But when I dug in, it just got weird.

Update, TL;DR: it was 1Password (h/t Henri Sivonen).

I. Kid. You. Not.

What happened initially was that I noticed that the syntax summaries of RELAX NG schemas in the XML Calabash documentation were rendering incorrectly. It appeared that br tags were being ignored, making the whole summary one long line.

I posted about it on Mastodon, and there was some interesting discussion. Some folks got the same results I did, some didn’t, even with what appeared to be the same browser.

I thought it was related to some combination of the CSS white-space property and code elements. There was some speculation that this was an intentional change related to the fact that code elements (unless they’re inside a pre) are supposed to be “a single phrase of code or line of code”.

If it’s intentional, I’m unimpressed. The content model of the code element is “Phrasing content” which includes the br element. I don’t think a dramatic, breaking change in how code is rendered is justified. Not that my opinion matters to the browser vendors.

But when I dug in this morning to write this post, it all got weird. I’ve spent all morning on what I thought would be a twenty minute grumble.

First, the problem has nothing to do with CSS. This is all down to the way the code element is rendered…and here’s the great bit…if it has (or is the descendant of an element that has) a class attribute that contains “language-”.

I am not kidding.

(As it happens, the code in the XML Calabash documentation has a class of language-none.)

Here’s my test document:

<!DOCTYPE html>
<html>
<head>
<title>Paragraph code</title>
<style>
html { font-size: 24pt; }
</style>
</head>
<body>
<p class="language-"><code>
One<br>
Two<br>
Three<br>
</code>
</p>

</body>
</html>

And here’s how that renders on my Mac this morning:

Not what I was expecting, and not what happened a week or so ago, or today on Linux:

I observe that the WHAT WG documentation for HTML says of the code element:

There is no formal way to indicate the language of computer code being marked up. Authors […] can use the class attribute, e.g. by adding a class prefixed with "language-" to the element.

So there’s the smoking gun, I guess. I fixed the XML Calabash documentation by changing code to span and putting a font-family on an ancestor. Whatever.

Here are the results I got from a bit of experimentation this morning. (Where “correct” means the br elements introduce newlines, as I think they should.)

Browser	Version	Platform	Correct
Firefox	146.0.1 (aarch64)	macOS arm	No
Firefox	146.0.1 (64-bit)	macOS x86	No
Firefox	145.0.1 (64-bit)	macOS x86	Yes
Firefox	146.0.1 (aarch64)	Linux arm	Yes
Firefox	111.0.1 (64-bit)	Linux x86	Yes
Firefox	146.0.1 (64-bit)	Linux x86	Yes
Firefox	146.0.1 (aarch64)	Windows arm	No
Firefox	146.0.1 (64-bit)	Windows x86	Yes
Chrome	143.0.7499.170 (Official Build) (arm64)	Windows arm	Yes
Chrome	143.0.7499.170 (Official Build) (arm64)	macOS arm	No
Chrome	143.0.7499.170 (Official Build) (arm64)	macOS arm	Yes (file:)
Edge	143.0.3650.96 (Official Build) (arm64)	Windows arm	Yes

There are a couple of older versions in there because I got to see the rendering before letting Firefox update itself.

That business about Chrome and file: URIs is extra special.

Here’s Chrome on macOS with an https: URI:

And here’s the same damned document rendered from a file: URI:

I just don’t even.