Just recently, some front-end code Clearleft delivered to a client was making its way through acceptance testing. We were slightly surprised to discover that their standards required our code to be supported by the two latest versions of web browsers. And then we realised we didn’t have a browser support policy of our own – something we set about rectifying.

When considering browser versions, we were fairly sure our client didn’t mean, for example, versions 124 and 125 of Chrome (released on 16 April and 14 May 2024 respectively). Instead their support standard would most likely be harking back to the days when Internet Explorer was a thing, and major browsers were updated once a year at best. To put this in context, the final version of Internet Explorer shipped in 2013.

It’s at this point we noted that Clearleft didn’t have a written browser support policy to counter or complement that of our clients. We probably did in the dim and distant past, but in recent years we’ve just built accessible, progressively enhanced websites without feeling the need to codify what that means. For the sake of professionalism and good client relationships, we decided to rectify that.

But where to start? Using browser versions clearly doesn’t make any sense, so what do we turn to instead? As it turned out, Jeremy had already nailed it in a recent blog post. We wanted a browser support policy that would focus on outcomes for the user. Rather than being fixated on specific browsers, we needed to consider capabilities, using the mindset that sees modern coding use feature detection in preference to browser detection. It turns out there’s an initiative for that.

The Baseline initiative is a joint effort by Google, Microsoft, Apple, and Mozilla to categorise browser support for web standards. Baseline provides clear information about which web standards features are ready to use in websites. It designates new features into two categories:

• Newly available – a feature is supported by the latest versions of all core browsers
• Widely available – a feature has been supported across browsers for at least 30 months

We use the Baseline project to determine which browser features to use in production. If a feature is widely available according to Baseline, we can use it.

Quoting directly from our browser support policy:

Progressive enhancement

If a feature is newly available, we might still use it, but we’ll ask a follow-up question:

“Can this feature be used as a progressive enhancement?”

In other words, will using this feature harm browsers that don’t support it? If a newly-available feature can be used as a progressive enhancement, we might well use it. If not, we’ll wait until the feature becomes widely available and choose a different method in the meantime.

This approach restricts usage of new features to nice-to-have additions rather than mission-critical requirements. But it also means we don’t necessarily have to wait for every browser to support a feature before using it.

Access for all

Underlying our browser support policy are two foundational principles:

1. Website content and core functionality should be accessible to everyone.
2. It’s okay for websites to look different in different browsers.

If content is unreadable in some browsers, that’s a bug that we will fix. If content is displayed slightly differently in some browsers, we consider that to be a facet of the web, not a bug. This means that there will sometimes be subtle visual and functional differences from browser to browser. We deem this acceptable provided that content and core functionality are unaffected.

We think this the right approach to browser support, and it’s something we believe the whole industry should follow in principle. To that end we’ve made our browser support policy available under a Creative Commons license, meaning you can use it for your own purposes if you find it helpful.

Originally published on the Clearleft blog.

Update: The title of this post was originally a knowing nod to the considered harmful cliché. I thought it might be amusing and get a bit of attention. However it was brought to my attention by a few people I respect that the title as written might be harmful in itself, so I changed it. However I believe that the subtle point I’m trying to make still stands:

When did we start using the ch unit to specify the maximum length for a line of text? Many places you look nowadays you'll see a variation on:

.prose {
  max-inline-size: 60ch;
}

Is it because of a direct reading of Bringhurst and people (like me) who’ve quoted him:

Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple column work, a better average is 40 to 50 characters.

I get it: there’s all that talk of ’characters’. But that’s not what Bringhurst means literally. I’ll come back to that shortly.

Firstly let’s remind ourselves about the CSS ch unit. While ch sounds like it should equate to a number of characters or a character width, that’s not strictly the case. The ch unit specifically refers to the width of the zero ’0’ character within the selected font, or 0.5em if no ’0’ is present. So unless you have a line made up entirely of zeroes, or are using a monospaced font, a width of 66ch will probably not give you a line containing 66 characters. What’s more, the rendered width of that line will vary with the font design, sometimes significantly.

The important part of Bringhurst’s guideline is not the ’66-characters’ but the ’satisfactory length’. This is about readability, and readability is affected by the length of a line more so than the number of characters in it.

A consistent finding is that long line lengths on screen are least preferred or judged as least easy to read [my emphasis]

With that in mind, restricting your line length using rem would be a far more appropriate unit to use:

.prose {
  max-inline-size: 30rem;
}

This would give you a line length accessibly tied to text size, but independent of font design.

But is using ch harmful?

Bringhurst’s guideline includes this little caveat: a page set in a serifed text face in a text size. This enables him to equate the number of characters in a line with its length. So if you are using a fairly standard typeface for your text then you’ll probably be fine. However that ’standard typeface’ assumption is implicit anytime you use ch to set the width of a column of text. Using rem removes that assumption and gives you what you are probably really after – a consistent, predictable limit on line length.

It didn’t surprise me to find that Eric Meyer had written about this six years ago. I’ll leave you with an important observation from his post:

If you’re working with multiple typefaces, say one for headlines and another for body copy, be careful about setting ch measures and thinking they’ll be equivalent between the two fonts. The odds are very, very high they won’t be.

So is using ch harmful? At the risk of saying it depends, it might not be harmful, but it could be, and there is a far more reliable and appropriate unit to use by way of the rem when it comes to limiting line length in a column of text.