While perusing the programme on the National Theatre website I stumbled upon a little bug. The incredible Ronkẹ Adékọluẹ́jọ́ has her name rendered in a most unusual style:

It rendered just fine in Chrome - but both Firefox and Safari misrendered some of the accented characters.

Here's a minimum viable demo to show what's happening:

Fonts are hard, OK?!?!

Broadly speaking⁰, accented characters can be made in two way.

1. Pre-composed. There is a separate code for the character é
2. Combining. The plain letter e is immediately followed by the combining character ◌́ and the computer smushes them together.

Similarly, a font file can have separate little drawings for each accented character or it can have separate accents.

In this case, the National Theatre is using the font "Helvetica Now Display W04".

The web font contains é (U+00E9) and both ◌́ (U+0301) & ̣◌ (U+0323).

But doesn't include ẹ (U+1EB9) or ọ (U+1ECD).

So the ẹ́ and ọ́ have to be made by combining characters in the font.

On Chrome this works. On Firefox and Safari, it seems to break when the CSS is set to font-weight: normal;. This causes the browser to render those characters in the default fallback font - hence the slightly weird look.

Next Steps

I've raised a bug with Firefox and one with WebKit.

Of course, it might be that they're doing the right thing and Chrome is in the wrong - but I think that's unlikely.

Now, time to fix the font I use on this website to prevent any rendering errors!

Way back in 2011, jQuery mobile introduced the web to page-change animations. Clicking on a link would make your high-tech Nokia display a cool page-flip as you navigated from one page of a website to another. Just like an app!!!!

A decade-and-a-half later, and CSS has caught up (mostly). No more JavaScript, just spec-compliant CSS. Well, as long as you're using Chrome or Safari. Here's a quick quick MVP which will add some fancy animations as people browse your website.

Every page which wants animations has to "opt in". That means you need this:

@view-transition {
    navigation: auto;
}

Next, you'll probably want to define some animations. Here are two I use:

@keyframes slide-in {
    from {
        translate: 100vw 0;
    }
}

@keyframes fade-out {
    to {
        opacity: 0;
    }
}

Any standard CSS animation will work. Get creative!

Which elements do you want to animate? I'm just going to do the whole page.

html {
    view-transition-name: page;
}

If you have a fancy app-like site, you might only want to animate specific parts of it.

While the page is transitioning, you can have something in the background to prevent things looking odd.

::view-transition {
    background: black;
}

That's optional, but rather useful.

Next, we have to assign the animations to specific events. Here, I have the old page fade out and the new page slide in.

::view-transition-old(page) {
    animation-name: fade-out;
    animation-duration: 1s;
}

::view-transition-new(page) {
    animation-name: slide-in;
    animation-duration: 1s;
}

You can set the duration to whatever makes sense for your page and animation style.

Finally, and this is important, some people find animations painful or discombobulating. Make sure the animations are turned off for those who don't like them.

@media (prefers-reduced-motion: reduce) {
    ::view-transition-group(page) {
        animation-duration: 0s;
    }
}

And that's it! A couple of dozen lines of CSS and you've got started with view transitions.

For more information, you can see the Chrome Devs' demo page, or take a read of the MDN documentation. There's also a full spec document if you like that sort of thing.

Right, I'm off to create some delightful animations!

I want to draw some vertical bar charts. I don't want to use a 3rd party library, or bundle someone else's CSS, or learn how to build SVGs.

HTML contains a <meter> element. It is used like this:

<meter min="0" max="4000" value="1234">1234</meter>

Which looks like this: 1234

There isn't much you can do to style it. Browser manufacturers seem to have forgotten it exists and the CSS standard kind of ignores it.

It is possible to use CSS to rotate it using:

meter {
   transform: rotate(-90deg);
}

But then you have to mess about with origins and the box model gets a bit confused.

See what 1234 I mean?

You can hack your way around that with <div>s and bludgeoning your layout into submission.

But that is a bit tedious.

Luckily, there's another way. As suggested by Marius Gundersen, it's possible to set the writing direction of the element to be vertical.

That means you can have them "written" vertically, while having them laid out horizontally. Giving a nice(ish) bar-chart effect.

1000200030004000

As well as the normal sort of CSS spacing, there is basic colour support for values which are inside a specific range:

1000 2000 3000 4000

The background colour can also be set.

1000

I dare say they're slightly more accessible than a raster image - even with good alt text. They can be targetted with JS, if you want to do fancy things with them.

Or, if you just want a quick and dirty bar-chart, they're basically fine.

Of course, necking a few shots every time you update your website isn't great for your health - so is there another way?

Click the "🥴 Drunk" button at the top of the page and see what happens!

These are a relatively simple set of CSS rules which you can apply to any site in order to simulate inebriation.

(I may have changed these since writing the post. Check the source for the latest version.)

First, monkey around with the fonts. This sets all the lower-case vowels to be rendered in a different font - as discussed in "targetting specific characters with CSS rules":

/* Drunk */
@font-face {
    font-family: "Drunk";
    src: url("/blog/wp-content/themes/edent-wordpress-theme/assets/fonts/CommitMonoV143-Edent.woff2") format("woff2");
    /* Lower-Case Vowels */
    unicode-range: U+61, U+65, U+69, U+6F, U+75 ;
    size-adjust: 105%;
}

The rest of the characters will be rendered in the system's default Cursive font. Characters will also be slanted. The first character of every paragraph will be shrunk:

:root:has(input#drunk:checked) * {
    font-family: "Drunk", cursive;
    font-style: oblique -12deg;
    text-align: end;
}
:root:has(input#drunk:checked) p::first-letter {
    font-size: .5em;
}

Next, use the child selectors to rotate and skew various elements. While we wait for CSS randomness to come to all browsers this is a simple way to select various elements:

:root:has(input#drunk:checked) *:nth-child(3n) {
    transform: rotate(2deg);
}
:root:has(input#drunk:checked) *:nth-child(5n) {
    transform: skew(5deg, 5deg);
}
:root:has(input#drunk:checked) *:nth-child(7n) {
    transform: rotate(-3deg);
}

Make the entire page blurred and saturate the colours:

:root:has(input#drunk:checked) body {
    filter: blur(1px) saturate(2.5);
}

Make any hyperlink harder to click by having it gently bounce up and down:

:root:has(input#drunk:checked) a  {
    animation-name: bounce;
    animation-duration: 4s;
    animation-direction: alternate;
    animation-timing-function: ease-in-out;
    animation-iteration-count: infinite;
}
@keyframes bounce {
    0%   { margin-top:  0px; }
    25%  { margin-top:-10px; }
    50%  { margin-top:  0px; }
    75%  { margin-top: 10px; }
    100% { margin-top:  0px; }
}

Does this really simulate drunkenness? No. It is a pale simulacrum. What it is, however, is deliberately inaccessible to the majority of people.

How does it make you feel using the site in Drunk-Mode? Does it frustrate you? Do your eyes hurt due to the garish colour scheme? Do you keep missing the thing that you try and click on? Are the words so hard to read that it takes you extra time to do anything useful? Will you recommend this experience to your friends and family?

I've written before about cosplaying as being disabled. Strapping on a pair of Glaucoma Goggles will give you an idea of what a visual impairment is like. But it won't give you the experience of living that way for months or years.

You should test your stuff with people who have cognitive impairments or physical disabilities. Find out how usable your site is for someone lacking fine motor control or for those with learning disabilities. Pay disable people to take part in usability studies. Integrate their feedback.

Faffing around with CSS will only get you so far.

At least, that's what they want you to think…

What if I told you there was a secret and forbidden way to target specific characters in text and apply some styles to them?

As part of my experiments in creating a "drunk" CSS theme, I thought it would be useful to change the presentation of specific characters. Wouldn't it be fun to have every letter "a" look slightly different to the rest of the text?!

So here's how you can apply limited CSS styles to certain characters while leaving the rest of the text unchanged, and without having to wrap characters in extra markup.

@font-face {
    font-family: "Different";
    src: url("whatever.woff2") format("woff2");
    /* Lower-Case Vowels */
    unicode-range: U+61, U+65, U+69, U+6F, U+75 ;
}
body {
    font-family: "Different", sans;
}

This creates a new font-family called "Different". It loads a unique font. It is applied to specific Unicode characters - in this case: a, e, i , o, and u.

The body places this font-family first and then defaults to a different family. This means all the lower-case vowels will use one font, and every other character will use something else.

That's… OK. I guess? Having certain characters as Garamond and the others as Times New Roman isn't exactly exciting, is it?

Sadly, there only other thing we can do in CSS to spice things up is to monkey around with size-adjust which lets the text be scaled up or down.

But modern fonts are pretty magic, you know!

The WOFF2 format has a new(ish) COLR table which allows you to create multi-coloured fonts. That means it is possible to target specific characters and have them display in living colour.

For example, using this colourful pixel font by Patrick H. Lauke (CC BY), I can target the Unicode Range of upper-case characters.

The above CSS only changes the appearance of UPPER Case characters!

To wrap things up - yes, you can target specific characters with CSS rules. Sadly, you're pretty much limited to fiddling around with their fonts.

I think constraints lead to interesting, creative solutions […]. Instead of relying on built in elements a bit more, I decided to banish classes from my website completely.

Long time readers will know that I'm a big fan of using semantic HTML where possible. If you peek beneath the curtain of this website you'll only see a handful of <div> elements (mostly because WordPress hardcodes them) - all the other blocks are fully semantic. Regrettably, there are rather too many <span> elements for my liking - normally for accessibility or for supplementing the metadata.

Overall, my CSS contained about 134 rules which selected based on class. Is that a lot? It feels like a lot.

On the one hand, classes are an easy way of splitting and grouping elements. Some <img>s should be displayed one way, the rest another. There's no semantic way to say "This is a hero image and should take up the full width, but this is an icon and should float discretely to the right."

But, on the other hand, why do we need classes? Keith Cirkel's excellent post "CSS Classes considered harmful" goes through their history and brings together some proposed solutions for replacing them. I think his idea of using data- attributes is a neat hack - but ultimately isn't much different from using classes. It's still a scrap of metadata to be tied into a style-sheet.

Classes are great for when you reuse something. I have multiple <section> elements but most don't share anything in common with the others. So they probably oughtn't have classes.

Removing classes has some advantages. It makes the HTML fractionally smaller, sure, but it also forces the author to think about the logical structure of their page and the semantics behind it.

Looking through my HTML, lots of classes exist because of laziness. If I want to position all the <time> elements which are within a comment, I don't need to write <time class="whatever"> and to pair it with .whatever { … }. Instead, I can use modern CSS selectors and say #comments time { … }.

But this leads me on to another existential question.

Are IDs necessary in modern HTML?

Mayyyyybe? I only have one <main> element, so an ID on there is unnecessary. <input> elements need IDs in order to be properly targetted by <label>s - but the label can wrap around the input. I have multiple <aside> elements because there's no semantic <widget> element, so they need unique IDs.

In theory, as suggested by Adam above, I could use an autonomous custom element like <my-widget> - but that has none of the semantics and, frankly, feels like a bit of a cheat.

Trimming the fat

Any day where I can delete some code is a good day. This was an excellent exercise in going through (years) of HTML and CSS to see what cruft had built up.

The first CSS rule I changed was, as mentioned above:

time.commentmetadata {
    float: right;
}

Which became:

#comments time { 
    float: right;
}

Classless and slightly more brief. Is it more readable? Having the fact it was about the metadata in a class could have been slightly useful - but if I thought it would be confusing, I could stick a /* comment */ in there.

Next, I found <nav class="navigation posts-navigation"> - what a tautology! I have multiple <nav> elements, it is true. But none of them have the same style. So this swiftly became <nav id="posts-navigation"> with an accompanying CSS rewrite.

My theme switcher had a bunch of <label class=button>s. They were all within a container with a unique ID, so could they be changed? Yes. But seeing the class name in the HTML is a good reminder to the author of how they are meant to display. Does that co-mingle content and presentation too much?

Some of the WordPress default classes are ridiculous. The body_class() function injected this into every <body>

"wp-singular post-template-default single single-post postid-62959 single-format-standard wp-theme-edent-wordpress-theme"

Most of that is redundant - what's the difference between single and single-post? For my purposes, nothing! So they were all yeeted into the sun.

Rather than targetting IDs or classes, I targetted the presence or absence of Schema.org microdata.

For example:

main[itemprop="blogPost"] { … }
main:not([itemprop="blogPost"]) { … }

This can go to the extreme. I have lots of comments, each one has an author, the author's details are wrapped in <div class="authordetails">…</div>

That can be replaced with:

/* Comment Author */
li[itemtype="https://schema.org/Comment"] > article > div[itemprop="https://schema.org/author"] {
    margin-bottom: 0;
}

Is that sensible? It is more semantic, but feels a bit brittle.

Parent selector are also now a thing. If I want a paragraph to have centred text but only when there's a submit button inside it:

p:has(input#submit) {
  text-align: center;
}

Again, am I sure that my button will always be inside a paragraph?

Similarly, sibling selectors are sometimes superior - but they do suppose that your layout never changes.

What remains?

There are some bits of this site which are reusable and do need classes. The code-highlighting you see above requires text to be wrapped in spans with specific classes.

Image alignment was also heavily class based.

There are some accessibility things which are either hidden or exposed using classes.

A bunch of WordPress defaults use classes and, even if they are redundant, it's hard to exorcise them.

As much as I would have liked to get rid of all my IDs, many needed to stay for linking as well as CSS targetting.

All told, the changes I made were:

• 134 class selectors down to about 65.
• 35 ID selectors up to about 50.
• 5 attribute selectors up to to about 20.
• Deleted or combined a lot of redundant CSS and tidied up my markup considerably.

I have around 250 CSS rules, so now the majority target semantics rather than classes or IDs.

Is this really necessary?

No, of course not. This is an exercise in minimalism, creativity, and constraint. Feel free to litter your HTML with whatever attributes you want!

As I went through, it increasingly became apparent that I was fitting my CSS to my HTML's logical structure rather than to its conceptual structure.

Previously, my comments were targetted with a class. Now they have the slightly more tangled targetting of "divs with this schema attribute whose parent is an article and whose grandparent has this ID".

It is a delightful meditative exercise to go through your code and deeply consider whether something is unique, reusable, or obsolete.

You've probably seen something like this before:

<article
  class="card-section-background1-colorRed"
></article>

A single class over-encumbered by all sorts of things. The more modular way to write this would be:

<article
  class="card section box bg-base color-primary"
></article>

That's pretty good! Each one of those classes can have its own bit of CSS and everyone is happy. But… sometimes it is hard to spot the gaps. Is that a - or a spec of dirt on your screen? Is there a way to make it more visually obvious what the groupings are?

Andy proposed this:

<article
  class="[ card ] [ section box ] [ bg-base color-primary ]"
></article>

Or, if you don't like brackets, this:

<article
  class="card | section box | bg-base color-primary"
></article>

The nice thing about attributes values is that they can contain any character. The spec says:

An attribute value is a string. Except where otherwise specified, attribute values on HTML elements may be any string value, including the empty string, and there is no restriction on what text can be specified in such attribute values.

Obviously there are some little gotchas. Quotes may need to be encoded, and some attributes only take specific variables. For the class attribute, however, the spec says they can have:

A set of space-separated tokens is a string containing zero or more words (known as tokens) separated by one or more ASCII whitespace, where words consist of any string of one or more characters, none of which are ASCII whitespace.

If a string isn't referenced within the CSS, it is simply ignored. So let's get creative!

Space Cowboy

You can space your variables however you like. These are all perfectly valid and (might) be easier for a human to read.

Separating out primary and secondary classes:

<article
  class="card             section box  bg-base color-primary"
></article>

Newline classes:

<article
  class="card
         section
         box
         bg-base
         color-primary"
></article>

Vertically aligned classes:

<article
  class="card 
            section
            box
         bg-base 
            color-primary"
></article>

Specific call-outs

Remember, you can have any text in your class names. If you need to highlight something specific to a human, you could use emoji:

<article
  class="card ➡️ section box ⬅️ bg-base color-primary"
></article>

Or

<article
  class="card 👉 section box 👈 bg-base color-primary"
></article>

Unicode Abuses

Unicode contains lots of mathematical symbols which look like letters but aren't. You could write something like:

<article
  class="𝐜𝐚𝐫𝐝 𝑠𝑒𝑐𝑡𝑖𝑜𝑛 𝒃𝒐𝒙 𝘣𝘨-𝘣𝘢𝘴𝘦 c𝐨l𝐨r-p𝐫i𝐦a𝐫y"
></article>

But I wouldn't recommend it; you would need to change your CSS to target those particular values.

Commenting

All code should be self commenting. HTML allows <!-- comments in code --> but there's nothing stopping you from adding comments inside values.

<article
  class="
    'Cards_updated_with_2025_setting'
     card
    //section_box_to_be_deprecated_next_year
     section box
    #Colours_set_in_primary.css
     bg-base color-primary"
></article>

I'd suggesting using underscore spacing to keep things readable and avoid having words which are accidentally class names.

Or, go artstic:

<article
  class="
     / \
    / _ \
   | / \ |
   ||   || _______
   ||   || |\     \
   ||   || ||\     \
   ||   || || \    |
   ||   || ||  \__/
   ||   || ||   ||
    \\_/ \_/ \_//
   /   _     _   \
  /               \  Don't change this
  |    0     0    |  code without first
  |   \  ___  /   |  speaking to Sam 
 /     \ \_/ /     \ in front-end.
/  -----  |  --\    \
|     \__/|\__/ \   |
\       |_|_|       /
 \_____       _____/
       \     /
       |     |
     card section box bg-base color-primary"
></article>

Yes. That is perfectly valid HTML. It may not be sensible, but it won't cause any problems in the browser. It might make people grumpy though.

Caveats

There are a few things to be aware of here:

• Optimisers might strip spaces.
• Pre-processes might re-order values.
• This is unusual and humans might get confused.

<div class="a b">…</div>

<div class="a
b">…</div>

Is there any semantic difference between them? Is there any way to target one but not the other? In other words, are they logically different?

I think the answer is no. On every browser I've tested, both are the same. Whether using JS or CSS, there's no difference between them. You could replace every \n with a and nothing would break.

But is that true for every attribute? Are there some attributes where a newline is *significant"?

For the vast majority of attributes, the answer is no. Consider the alt attribute for providing alternate text on images. This:

<img src="" alt="First line.
Second Line.

Forth line.">

When rendered by a browser, the newlines become spaces. See:

But there's are three attributes where newlines do matter. Can you work out what they are?

Title

Hover your cursor over this text and a title will appear. It will look something like:

The HTML specification has a section on "space-separated tokens" which it defines as "ASCII whitespace":

• U+0009 TAB
• U+000A LF
• U+000C FF
• U+000D CR
• U+0020 SPACE

So tab, any newline, and space are all equivalent when it comes to tokenisation of content.

However, for title specifically:

If the title attribute's value contains U+000A LINE FEED (LF) characters, the content is split into multiple lines. Each U+000A LINE FEED (LF) character represents a line break.

3.2.6.1 The title attribute

Placeholder

There's another similar case:

The good old <textarea> element has a placeholder attribute. That also allows newlines - although in a subtly different way to the title element!

All U+000D CARRIAGE RETURN U+000A LINE FEED character pairs (CRLF) in the hint, as well as all other U+000D CARRIAGE RETURN (CR) and U+000A LINE FEED (LF) characters in the hint, must be treated as line breaks when rendering the hint.

4.10.11 The textarea element

Quite why carriage returns are allowed here, but not in title, I don't know!

Also note, the textarea's placeholder is different from the <input>'s placeholder, which doesn't support newlines.

ID

I warn you though, this one is pretty nasty!

Consider this piece of HTML:

<p id="test
">Hello</p>

I know! What sort of sicko would include a newline in their ID?! But, it turns out, that is significant.

Try to select that element using CSS like:

#test {
   color: red;
}

It won't work! The literal ID is not test. If you run:

document.querySelector("p")

It will return <p id="test\n"> - which means you can only select it with:

document.getElementById("test\n")

Or with CSS using special character selectors:

#test\a {
  color: blue;
}

The spec says

The id attribute specifies its element's unique identifier (ID).

There are no other restrictions on what form an ID can take; in particular, IDs can consist of just digits, start with a digit, start with an underscore, consist of just punctuation, etc.

While it doesn't specifically mention newlines, it seems clear that the attribute can contain *anything".

Any others?

I'm pretty sure those three are the only attributes which treat newlines in their values as significant. Think I'm wrong? Please leave a comment.

After skimming through a few options, I found Tempest Highlight. It has nearly everything I want in a code highlighter:

•  PHP with no 3rd party dependencies.
•  Lots of common languages.
•  Modern, with regular updates.
•  Easy to use functions.
•  Range of difference style sheets.

But, on the downside:

•  No WordPress plugin.
•  Not all languages supported.
•  CSS embedded in HTML.

I can live without some esoteric languages, but I don't really want to run composer install on my blog. I just want a quick WordPress plugin. So, here's how I did it.

Here Be Dragons

This is a quick prototype. It has an audience of one; me. It may break in unexpected ways. Use at your own risk.

The file layout is relatively simple:

WordPress Plugins
├── Highlight_Plugin
│   ├── src/
│   ├── autoload.php
│   ├── index.php
│   └── base.css

The src/ directory contains the src/ directory from Tempest Highlight.

The Art of Loading without Loading

Normally, to install a PHP package, the composer app creates an autoloader which will magically import everything you need into your project. We can't do that here. Instead, we need to manually load the library.

Create a file in the plugin's directory called autoload.php - its job is to autoload everything in the src/ directory.

<?php
spl_autoload_register( function ( $class ) {
    //  Project-specific namespace prefix
    $prefix = "Tempest\\Highlight\\";

    //  Base directory for the namespace prefix
    $base_dir = __DIR__ . "/src/";

    //  Does the class use the namespace prefix?
    $len = strlen( $prefix );
    if ( strncmp( $prefix, $class, $len ) !== 0) {
        //  No, move to the next registered autoloader
        return;
    }

    //  Get the relative class name
    $relative_class = substr( $class, $len );

    //  Replace namespace separators with directory separators, append with .php
    $file = $base_dir . str_replace( "\\", "/", $relative_class ) . ".php";

    //  If the file exists, require it
    if ( file_exists( $file ) ) {
        require $file;
    }
});

I don't know if that's the easiest way to do it. But it works!

Testing

The index.php file can now be tested:

//  Load the Tempest Highlight library
require_once __DIR__ . "/autoload.php";

//  Set up the namespace
use Tempest\Highlight\Highlighter;

//  Define the theme.
$theme = new Tempest\Highlight\Themes\InlineTheme( __DIR__ . "/src/Themes/Css/light-plus.css");

//  Create the highlighter.
$highlighter = new Tempest\Highlight\Highlighter( $theme );

//  Print some formatted HTML
echo $highlighter->parse("<em id='foo' class='bar'>test</em>", "html" );

All being well, that should produce this:

&lt;<span style="color: #0000ff;">em</span> id='foo' class='bar'&gt;test&lt;/<span style="color: #0000ff;">em</span>&gt;

That has the CSS embedded. Not ideal, but certainly good enough. I picked "light-plus" because it was the only theme which seemed to meet at least WCAG AA when on a white background.

OK, so how do we go from printing out a scrap of HTML to extracting all the code snippets from a WordPress blog?

Draw The Rest of the Owl

In theory the code is relatively straightforward.

Find code snippets

My Markdown plugin transforms this:

 ```javascript
 var a = 2.0;
 ``` 

Into this:

<pre><code class="language-javascript">
var a = 2.0;
</code></pre>

No need to use a regex, the new PHP 8.4 HTMLDocument gives us direct programmatic access to the HTML.

//  Load the content into PHP 8.4's HTML DOM.
$dom = Dom\HTMLDocument::createFromString( $content, LIBXML_NOERROR | LIBXML_HTML_NOIMPLIED, "UTF-8" );

//  Select the code snippets.
//  `<pre><code class="language-*">`
$codeSnippets = $dom->querySelectorAll( "pre>code[class^=language-]" );

Replace the snippets

From the above, I have the language and code, so it can "easily" be replaced.

//  Iterate through each snippet.
foreach ( $codeSnippets as $code ) {
    //  Get the HTML from within the <code>.
    $originalCode = $code->textContent;
    //  Replace the contents of <code> with the highlighted HTML.
    $code->innerHTML = $highlighter->parse( $originalCode, $language )
}

Replacing the code in that node manipulates the original DOM. Which means, after looping through all the snippets, I can return the altered HTML like so:

return $dom->saveHTML();

And then…

Obviously, there's a bit more too it than that. It ignores RSS feeds, it adds a base CSS style to the head, some SVGs get embedded, semantic metadata is included, and it all gets a bit tangled and complicated.

ToDo

A few things need to happen to make this even better.

• Encoded comments as well and posts.
• Add new languages.
• Don't in-line the CSS into the HTML, but add it as a separate stylesheet.

But, for now, it is running on my blog and that's good enough for me!

Get the code

You can play about with the WordPress plugin. Bugs reports, pull requests, and suggestions all warmly welcomed.

Here's a thought experiment for you. Consider these two HTML elements:

<p class="alpha bravo charlie">………</p>
<p class="bravo charlie alpha">………</p>

Is there any semantic difference between them? Does the ordering of the values inside the class attribute matter?

Both can be targetted with CSS like:

.bravo {
   color: red;
}

They can also be targetted using:

.charlie.bravo {
   color: green;
}

Or using a Selector List

.bravo, .alpha {
   color: yellow;
}

So order doesn't matter, right?

Well, it's a bit more complicated than that

Consider Presence Selectors.

This CSS will only select the first element:

p[class="alpha bravo charlie"] {
  font-size: 2em;
}

It targets the class name in that exact order. No other.

Similarly, Substring Selectors can be used in an order-specific manner.

This CSS will only select the second element:

p[class^="b"] {
  display: block;
}

It looks for a class attribute where the value starts with b

Where ordering matters

The HTML spec has a (non-normative) section on attributes. Those which accept multiple values are (broadly) in three categories.

1. A set of space-separated tokens is a string containing zero or more words (known as tokens) separated by one or more ASCII whitespace, where words consist of any string of one or more characters, none of which are ASCII whitespace.
2. An unordered set of unique space-separated tokens is a set of space-separated tokens where none of the tokens are duplicated.
3. An ordered set of unique space-separated tokens is a set of space-separated tokens where none of the tokens are duplicated but where the order of the tokens is meaningful.

The class attribute belongs to the first group. While ordering isn't meaningful, it also isn't irrelevant.

The only attributes which are specifically unordered are:

• All elements:
  • itemprop=, itemref=, itemtype=
• <link>, <script>, <style>
  • blocking=
• <output>
  • for=
• <td>, <th>
  • headers=
• <a>, <area>, <link>
  • rel=
• <iframe>
  • sandbox=
• <link>
  • sizes=

The only attribute specifically listed as "Ordered" is the accesskey attribute.

There are a few others which do require an order, although it is not immediately obvious.

Both imagesrcset and srcset require a "Comma-separated list of image candidate strings". The comma separated strings can be in any order, but the text within them has a strict ordering.

For example:

<img srcset="header640.png 640w, header960.png 960w, header1024.png 1024w" …

Similarly, the type attribute requires its value to be a valid MIME type. But MIME types can also include a codec. So it's possible to end up with HTML like:

<video>
  <source 
    src="movie.webm"
    type="video/webm; codecs='vp8, vorbis'">

Assuming those attributes were whitespace separated tokens would lead to nonsense!

The autocomplete type is another complex example. The spec just says "Autofill field name and related tokens", but MDN makes it clear that it requires:

An ordered set of space-separated tokens consisting of autofill detail tokens preceded by optional sectioning and either billing or shipping grouping tokens. Phone numbers, email addresses, and messaging protocol tokens are preceded by a token identifying the type of recipient.

For example autocomplete="home email" says to suggest the user's home email address whereas autocomplete="work email" suggests their work email. The ordering is necessary and autocomplete="email home" will not be understood.

Where else might ordering matter?

Rather obviously, alt text should always remain in order. No one wants to read alphabetically ordered image descriptions!

As mentioned by Nathan Knowler some ARIA attributes require ordering for accessibility.

And, as Kagan MacTane pointed out, sometimes the ordering is important for a human - even if it is irrelevant for a machine.

What have we learned today?

I originally asked this question on Mastodon. About two-thirds of respondents thought that attribute ordering was irrelevant.

Post by @Edent@mastodon.social

View on Mastodon

I hope I've demonstrated that it is slightly more complicated than it may appear at first.

If you're on a desktop, you might notice that hovering your mouse over it displays the destination somewhere on your screen. If you're a geek, you could view the source-code of a page.

Can we improve the experience for users? Here's an attempt.

Try hovering your cursor over this link to a popular website.

This is what it should look like:

Here's how it works.

Cursor Styles

CSS allows us to change the icon displayed by a cursor. There are dozens of built-in icons, but you can also supply your own image file.

#link {
   cursor: url("/path/to/image.png"), auto;
}

Anything hovering over that link will get that .png as its cursor. Nifty!

Favicons

Most websites have a Favicon - it is a little image that you see in your browser bar, or when you save a website to your favourites. It is usually found at /favicon.ico - but can be in a variety of places.

There are dozens of free and paid services which let you quickly grab a favicon from any site.

The one I tend to use is DuckDuckGo's service. It takes any domain name, like Google.com, and returns an icon. It looks like this https://icons.duckduckgo.com/ip9/google.com.ico

Putting it all together

You can put the CSS anywhere - including inline with your links:

<a
  href="https://google.com/"
  style='cursor:url("https://icons.duckduckgo.com/ip9/google.com.ico"), auto;'
>Visit this website</a>!

Is this a good idea?

Well… maybe? If you have lots of links to various destinations and don't want to clutter up your prose with "(Wikipedia)" or other things like that, it could be useful.

Not everyone will recognise the logo for every service - so it may not add anything useful.

It doesn't work on mobile.

This isn't a common UI pattern - which might be a little confusing for users.

Loading images from remote sites is probably not a security concern. But if a website is hacked, you might have unwanted images on your site.

A site could lie to you about its destination.

Automating it should be possible, but it could be a bit of a faff to maintain.

But it looks so pretty!

This very long headline ends with a single
word

Having a dangling word doesn't always look great. Using text-wrap:balance would give us something like:

This very long headline ends
with balanced lines

Hurrah!

But the name is, I think, slightly misleading. It doesn't only work on text. It will work on any content. For example - I have a row of icons at the bottom of this page. If the viewport is too narrow, a single icon might drop to the next line. That can look a bit weird.

Here's a video demo:

So feel free to use text-wrap: balance; on any items which need to be balanced over multiple lines.

Yes!

This scrap of code will turn all those links red:

a[href^="https://example.com"] {
   color: red;
}

Now, there are a few gotchas with this code.

• It matches the string exactly. So https://example.com will not match https://www.example.com
• The match will occur at the start of the string.

To match more lazily, you can use a substring match:

a[href*="example.com"] {
   color: red;
}

That will match www.example.com as well - but it will also match https://wikipedia.org/wiki/example.com

Is this useful?

I use it to ensure all the links which point to the Internet Archive are properly labelled:

a[href^="https://web.archive.org"]::after {
  content: " (archived)";
  vertical-align: super;
  font-size: .9em;
}

For example, this link points to the earliest version of my website.

You could also use it to indicate when a link takes you to a specific filetype (note, this may need to be case insensitive:

/* URl ends with .pdf or .PDF */
a[href$=".pdf" i]::after  {
  content: " (PDF)";
  vertical-align: super;
  font-size: .9em;
}

It is also possible to add something to show people are leaving this site:

a[href]:not([href^="https://shkspr.mobi" i]) {
    content: "↗️";
}

I had a site which, for various boring reasons, was printing a <style> element in the middle of the HTML's body. Because <style> is a metadata element, it should only appear within the <head> element.

This is OK:

<!doctype html>
<html>
   <head>
      <style> a { color: #f00; } </style>
   </head>
   <body>
      …

This is an error:

<!doctype html>
<html>
   <head>
   </head>
   <body>
      <style> a { color: #f00; } </style>
      …

Most modern browsers will parse the stylesheet and not complain. But I like doing things properly and to spec because I am a massive boring nerd who is no fun at parties.

There is another way to include CSS in a document - via the <link> element.

<link rel="stylesheet" type="text/css" href="https://example.com/style.css">

It is sometimes OK to have a <link> element in the <body> - but can you spot the problem? Yes! The href points to an external resource. That's no good because we want to put the CSS inline.

The href needs to point to a URl. But it can point to a data URl!!!!

So, if the CSS is first Base64 encoded, it's possible to place inline CSS within the body of the HTML document!!!!!!!

<!doctype html>
<html>
   <head>
   </head>
   <body>
      <link rel="stylesheet" type="text/css" href="data:text/css;base64,Q29uZ3JhdHVsYXRpb25zISBZb3UgZm91bmQgbXkgc2VjcmV0IG1lc3NhZ2UhIFlvdSByZWNlaXZlICs1IEludGVybmV0IHBvaW50cy4=">
      …

This also works with URl encoding, if you prefer that, thusly:

<!doctype html>
<html>
   <head>
   </head>
   <body>
      <link rel="stylesheet" type="text/css" href="data:text/css,%2F%2A%0AThis%20is%20my%20CSS%0A%2A%2F%0Aa%20%20%7Bfont-family%3Amonospace%3B%7D">
      …

Obviously, the correct thing to do is to change your rendering path so that the styles are all placed within the correct metadata section of the document. But, if you need to, this will work across all browsers in a standards compliant way.

Is there a way to use CSS to increase the font size of specific characters without having to wrap them in an extra <span> or similar?

Yes! Although it is a bit of a hack.

This relies on 3 CSS features: src: local(), unicode-range,and size-adjust. Let me walk you through it.

@font-face {
    font-family: "emoji";

    src: local('Apple Color Emoji'),
         local('Android Emoji'),
         local('Segoe UI Emoji'),
         local('Noto Color Emoji'),
         local(EmojiSymbols),
         local(Symbola);

    unicode-range: U+231A-231B, U+23E9-23EC, U+23F0, U+23F3, U+25FD-25FE, U+2614-2615, U+2648-2653, U+267F, U+2693, U+26A1, U+26AA-26AB, U+26BD-26BE, U+26C4-26C5, U+26CE, U+26D4, U+26EA, U+26F2-26F3, U+26F5, U+26FA, U+26FD, U+2705, U+270A-270B, U+2728, U+274C, U+274E, U+2753-2755, U+2757, U+2795-2797, U+27B0, U+27BF, U+2B1B-2B1C, U+2B50, U+2B55, U+FE0F, U+1F004, U+1F0CF, U+1F18E, U+1F191-1F19A, U+1F1E6-1F1FF, U+1F201, U+1F21A, U+1F22F, U+1F232-1F236, U+1F238-1F23A, U+1F250-1F251, U+1F300-1F320, U+1F32D-1F335, U+1F337-1F393, U+1F3A0-1F3CA, U+1F3CF-1F3D3, U+1F3E0-1F3F0, U+1F3F4, U+1F3F8-1F43E, U+1F440, U+1F442-1F4FC, U+1F4FF-1F53D, U+1F54B-1F567, U+1F57A, U+1F595-1F596, U+1F5A4, U+1F5FB-1F64F, U+1F680-1F6CC, U+1F6D0-1F6D2, U+1F6D5-1F6D7, U+1F6DC-1F6DF, U+1F6EB-1F6EC, U+1F6F4-1F6FC, U+1F7E0-1F7EB, U+1F7F0, U+1F90C-1F93A, U+1F93C-1F945, U+1F947-1FA7C, U+1FA80-1FAC5, U+1FACE-1FADB, U+1FAE0-1FAE8, U+1FAF0-1FAF8;

    size-adjust: 300%;
}

body {
    font-family: "emoji", sans-serif;
}

Here's how it works.

@font-face this tells the browser that we're defining a new font which will be referenced later.

font-family this is the name we're going to be using as a reference.

src: local('Apple Color Emoji') ... CSS can reference local fonts. We don't know what device this page is being viewed on, so we've included a number of popular fallback fonts which should work with all major browsers. You can also reference a webfont if you want - although Emoji fonts tend to have a large filesize. I've adapted this from Marc Fornós' CSS and added a few more common default emoji fonts.

unicode-range this tells the browser to use this font only for the specific codepoints mentioned. This is where the magic happens.

Emoji codepoints are complicated - especially when it comes to combining characters. You can see a full list of every sequence in Unicode 15.1. There are currently 3,782 different emoji.

There was some talk of using named ranges but that doesn't seem to have gone anywhere. So, instead, I've extracted all the Emoji codepoints and manually grouped them. It's a pretty long sequence, and I'm sure I've made a few mistakes.

size-adjust this is used to increase or decrease the apparent size of a font.

Finally, the body { font-family: "emoji", sans-serif; } tells the browser to use the Emoji font (remember, this will only work on the specified Unicode range) and then fall back to the defaults sans-serif font. Obviously, you can specify whatever fonts you like.

Have a play with it

This is a nifty little hack if you want to make Emoji (or any other text) bigger than its surroundings.

I am indebted to Šime Vidas who demonstrated this trick to me.

Do you know about the EURion constellation? It is a pattern which is embedded into some modern banknotes and has a curious property. Most modern photocopiers will, if they detect the pattern, refuse to make a copy.

Try it for yourself - stick a €20 note into your nearest Xerox machine and try to print out some illicit currency - see what happens!

It goes a little further Some printers will refuse to print anything which contains this pattern. Lots of image editing software will throw up dire warnings if you try to open a file with it embedded.

Now, I know what you're thinking. Usually web browsers won't print background images. Even if you mark them as !important. And don't try using @media print because that won't work either.

Instead, you need to use print-color-adjust: exact; to tell the browser that you want to print exactly what is seen on screen.

If you can print this blog post in colour - and then photocopy it - do please let me know 😉

Some websites don't contain dates in their URls. There may not be a © date or publication date shown on the page. And the <meta> tags might not contain anything useful. If you're lucky, the site will look old fashioned:

Unlike the BBC, most sites have adopted the "Eternal CSS" pattern. When fashions change, the entire site gets a facelift - which means ancient articles look modern. This can mislead readers into thinking old information is new.

Here's (one way) this can be fixed - inspired by Moriel Schottlender fabulous historic CSS selector.

Get the page's publication date

A page might have a date published on it. For example:

Published on <time id="published" datetime="2005-02-14">Valentine's Day</time>

CSS has an attribute selector which can see the year encoded in that datetime:

[attr|=value] Represents elements with an attribute name of attr whose value can be exactly value or can begin with value immediately followed by a hyphen, - (U+002D). It is often used for language subcode matches.

That means, the element can be styled based on its year. For example, make the year 2005 green, and the year 2006 blue:

time[datetime|="2005"] {
  color: green;
}

time[datetime|="2006"] {
  color: blue;
}

That's fine for styling a specific element, but using the CSS property has() it is possible to set variables based on the date. For example, this code sets a variable which can be used anywhere on the page:

:root:has( time[datetime|="2005"] )  {
    --timeColor: green;
}

:root:has( time[datetime|="2006"] )  {
    --timeColor: blue;
}

p {
  color: var(--timeColor);
}

(Note that has() is only available in Chrome. It is coming soon to Firefox.)

Variables from Metadata

If the published date is in the metadata, rather than the body, it can still be used in CSS. This is how WordPress adds the original published date to a page's <head>:

<meta property="article:published_time" name="article:published_time" content="2007-11-16T12:34:41+00:00" />

The date can be accessed and used to set specific variables depending on the year:

:root:has( [name="article:published_time"][content|="2007"] ) {
    --font: "Old Fashioned";
    --bgColor: green;
    --fontColor: red;
    ...
}
:root:has( [name="article:published_time"][content|="2023"] ) {
    --font: "Modern";
    --bgColor: white;
    --fontColor: black;
    ...
}

Using this pattern, it is possible to have a single style-sheet which has a different look and feel depending on the age of the article.

Imagine that! You could set old pages to have a 1990's look and feel while keeping modern markup.

Maths limitations

It isn't yet possible to use the attr() CSS Function to get the date. And it is impossible to do if/else or use less than / greater than in CSS.

But we can cheat!

A variable can be set depending on the year published:

:root:has( [name="article:published_time"][content|="1998"] ) {
    --publishedYear: 1997;
}
:root:has( [name="article:published_time"][content|="1999"] ) {
    --publishedYear: 1999;
}
:root:has( [name="article:published_time"][content|="2000"] ) {
    --publishedYear: 2000;
}
...

That pattern can be repeated as far back as your site goes - and as far forward as you think you'll still be publishing.

CSS has no access to the computer's datetime functions - that requires JavaScript. But if the website does expose the date it was generated, it should be possible to calculate the age of the page.

For example, if the <body> contains:

<time id="RomanYear" datetime="2023">ⅯⅯⅩⅩⅠⅠⅠ</time>

The year can be turned into a variable using a similar pattern:

:root:has( #RomanYear[datetime|="2023"] ) {
    --currentYear: 2023;
}
:root:has( #RomanYear[datetime|="2024"] ) {
    --currentYear: 2024;
}
:root:has( #RomanYear[datetime|="2025"] ) {
    --currentYear: 2025;
}
...

It is then possible to use the calc() CSS function to calculate the age of the page:

--age: calc( var(--currentYear) - var(--publishedYear) );

From this, it's possible to work out how old the page is as a percentage of the site's history. For example, if the earliest publication on the site is from 2001:

--oldestYear:    2001;
--currentYear:   2023;
--publishedYear: 2014;

--siteAge: calc( var(--currentYear) - var(--oldestYear) ); /* 16 */

--pageAge: calc( var(--currentYear) - var(--publishedYear) ); /* 9 */

Finally, a sepia filter can be placed over the page - with its intensity higher the older a page is.

--percentAge: calc( var(--pageAge) / var(--site-age) );

--filterRatio: calc( var(--percentAge) );

filter: sepia( var(--filterRatio) );

What's next

What will you do with this forbidden information?

Here's a scrap of HTML which present a dropdown for a user to choose their colour scheme:

<select id="colour-mode">
  <option value="">Theme Selector</option>
  <option value="dark">Dark Mode</option>
  <option value="light">Light and Bright</option>
  <option value="eink">eInk</option>
</select>

It will look something like this: Theme Selector Dark Mode Light and Bright eInk

Modern CSS gives us a way to see which of those options have been chosen by the user:

#colour-mode option:checked[value="dark"]

That can be combined with the new :has() CSS pseudo class. This allows the CSS to say "If the body has a checked elements with this specific value, then apply these CSS rules" - like so:

body:has( > #colour-mode option:checked[value="dark"] ) {
  background: ...
}

OK! So, depending on which option the user selects, the CSS can be made to do all sorts of weird and wonderful things. But, that will require...

CSS variables

Here's some CSS which will set various colours for light mode and dark mode. Then it sets the default colours to the light mode:

:root {
  /* Light mode variables */
  --light-background: beige;
  --light-text: #000;
  --light-bg: #0F0;

  /* Dark mode variables */
  --dark-background: #000;
  --dark-text: #FFF;
  --dark-bg: #FF0;

    /*  Default variables */
  --background: var(--light-background);
  --text: var(--light-text);
  --bg: var(--light-bg);
}

So the rest of the CSS can have things like:

p {
   color: var(--text);
}

The <p> will be set to use the colour from --text which, at first, is the same as --light-text.

That can be changed with both :has() and :checked like so:

body:has( > #colour-mode option:checked[value="dark"] ) {
  --text: var(--dark-text);
}

That says "If the body element has a child which has the ID "colour-mode", and if "colour-mode" has a child option with the checked value of "dark", then set the --text variable to be the value of --dark-text.

String enough of those together and that will make a pretty capable theme switcher!

User Preferences

Some browsers will know whether their user has a preference for dark or light mode. Perhaps the user has set their phone to dark mode, or flipped a switch somewhere for light mode. This preference can be determined in CSS using the prefers-color-scheme media feature.

A site can set the default value of the colour variables like so:

@media (prefers-color-scheme: light) {
  :root {
    --text: var(--light-text);
  }
}

@media (prefers-color-scheme: dark) {
  :root {
    --text: var(--dark-text);
  }
}

Demo

Caveats

A few issues:

1. This doesn't yet work on Firefox. Even if you enable layout.css.has-selector.enabled in about:config. Support is coming soon™.
2. This doesn't remember your user's choice. So they'll need to toggle it on every page load.
3. Choosing a sensible colour scheme means you should test it for accessibility.

Saving the selection

Sadly, this does require JS. This uses localstorage rather than a cookie. If a user doesn't have JS enabled, this will gracefully degrade; the theme will follow the user's preferences, switching will work but won't be remembered.

//  Get the theme switcher
var themeSelect = document.getElementById('theme');

//  If a theme has previously been selected, set it
if (localStorage.theme) {
    themeSelect.value = localStorage.theme;
}

//  Listen for any changes and save them
if(themeSelect) {
    themeSelect.addEventListener('change', function(event){
        localStorage.setItem('theme', themeSelect.value);
    });
}

Further Reading

• Do you know color-scheme?
• How to Make Dark Mode for Websites Using Only CSS
• Prefers Color Scheme
• Pure CSS dark mode toggle switcher
• How to store theme color preferences using the Local Storage API

It relies on the new-ish :has() CSS pseudo class and the positively ancient filter() CSS function.

Here's the code in all its glory:

body:has( > #dark-mode-checkbox:checked ) {
  filter: invert(1);
  background: #000;
}

#dark-mode-checkbox:checked ~ img {
  filter: invert(1);
}

That does three things. If the body has an <input id="dark-mode-checkbox" type="checkbox"> which is selected, then:

• Invert all the colours on everything on the site.
• Manually set the background of the body, because the above is only filtering the descendants of the body.
• Find any images and invert them, so they're the right colour.

Here's some minimum viable HTML:

<body>
  <input id="dark-mode-checkbox" type="checkbox">
  <label class="dark-mode-label" for="dark-mode-checkbox">Enable dark mode</label>
  <h1>Heading</h1>
  <p>Test</p>
  <img src="https://placecats.com/128/128" alt="A cute cat">
</body>

Demo

You can play with the demo.

It should look like this:

Caveat

A few issues:

1. This doesn't yet work on Firefox. Even if you enable layout.css.has-selector.enabled in about:config. Support is coming soon™.
2. Inverting colours isn't the same as a properly designed dark mode. You absolutely shouldn't use this in production.
3. There are no accessibility guarantees. Please test this before subjecting your users to it.
4. This doesn't remember your user's choice. So they'll need to toggle it on every page load.
5. Who knows what eldritch horrors this will unleash upon humanity.

I wanted a <select multiple> element where the <options> were laid out in a grid. I nearly got there.

It's possible to have the <option>s in a horizontal row - but only on Chrome and Firefox.

Here's a quick fiddle showing the results:

As you can see, it's possible to do some pretty extravagant styling of the individual <options> you can even change how they look when they're selected.

But it's impossible to get them to wrap using a flexbox or grid approach. It seems the only layout options are a vertical or horizontal list.

Why, yes, I should probably have used <input type="checkbox"> instead!