CSS properties you should know for better text designs
master.dev
master.dev
1. many, MANY implementation bugs in `background-clip: text` across browsers, especially Firefox [1], basically safe only for simple cases with no additional transforms or filters.
2. `color: transparent` ensures the text will be invisible in every browser that does supports the `transparent` keyword (i.e. basically every single one, presumably) but not support background-clip:text yet, or fail to load or interpret the background-image (like in high contrast/forced colours mode). Use `-webit-text-fill-color: transparent` instead. (Yes, that vendor prefix is necessary, and yes, it is de-facto standardised and implemented in Chrome and Firefox [2]. And yes, it is as absurd as it gets.)
3. Touching the `letter-spacing` turns off all ligatures, logically. Could be a good thing, actually, but worth knowing. (Anthropic used to use negative letter-spacing thorough its webpages, but now it seems they abandoned that.)
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1656784 [2] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
Wrapping the rule in a feature query seems a lot cleaner and more reliable.
I fully agree, yet in this particular case it probably holds, with possible exception of 2009 Safari, IIRC [1]. And absolutely agree that defensive @supports is better and more robust way to go. Just aimed to ameliorate the, from my point of view wrong and dangerous pattern using `color: transparent` the easiest possible "drop-in" that would encourage keeping the "normal" `color` intact and only introducing `-webkit-text-fill-color: transparent` on top of that. It seemed like a pattern (lazy) develoers would follow more likely
[1] https://github.com/mdn/content/issues/2638 Made some research while suggesting to promote better approach and point to caveats in the "authoritative" MDN article and partially succeeded. (Sadly, there are `color: transparent`s used in examples there now, but… at least I've tried.)
There are only three places where I hold letter-spacing of any kind to be acceptable:
1. Art. (This is pretty much the intended context of the article, but I just know it’s going to be taken out of that context.)
2. In large headings, slightly reducing letter-spacing may be reasonable, as fonts are often spaced for smaller size usage. But whereas reducing line-height is all but essential, reducing letter-spacing is of marginal value at best. Ideally you have a variable font with optical sizing (the opsz axis), so this is handled automatically.
3. In all-caps, small-caps or all-small-caps text, as fonts are generally spaced for runs of lowercase letters. https://practicaltypography.com/letterspacing.html suggests 5–12% (which you can spell in CSS as 5% or 0.05em). Ideally you have a font that optimises this itself within the caps, smcp and/or c2sc features.
Do not, under any circumstances, set non-zero letter-spacing for body text. It’s just wrong. If you feel your preferred font is too spacious or too tight, fix or replace the font.
(If you want another reason: letter-spacing is incompatible with ligatures, not so often used in sans-serif faces, but in serifs things like fi not having the ascender and dot collide messily is often valuable.)
And really, I’d prefer problematic properties to have prefs whereby you can disable them outright, rather than trying to add a style on top to nullify it. Newer stuff often does, but the old stuff doesn’t. user_pref("layout.css.letter-spacing.enabled", false) would make me happy.
Three more that I'm aware of:
4. For emphasis in Fraktur text [0].
5. In very small amounts (< 2%) to improve paragraph breaking [1 §7.2].
6. For very large signs where readability is more important than aesthetics [2, 3].
These are all rather special cases though, so I still agree with your general point.
[0]: https://unifraktur.sourceforge.net/en/letterspacing.html
[1]: https://tug.org/TUGboat/tb21-4/tb69thanh.pdf#page=95
[2]: https://mutcd.fhwa.dot.gov/SHSe/Alphabets.pdf#%5B%7B%22num%2...
[3]: https://mutcd.fhwa.dot.gov/SHSe/shs_2004_2012_sup.pdf#SHS%20...
As for 5, I’m not convinced letter-spacing is the right tool for it: at those scales I’ve tended to prefer condensing or expanding the text, glyphs and all, which you can do in SVG. But I will allow it as a place where very careful letter-spacing use with kerning and ligature control can be acceptable.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
- did you know that https://master.dev/blog/page/65/ onwards till page 70 there is not a single article on any of your pages and yet the pagination keeps going to older posts?
- practise what you preach maybe?
I vividly remember IE and many hacks to have css elements properly working in it…
Imho this is a reason why markdown and other rich-textual formats appeared.
Btw is there a some “w3schools” for recent CSS?
No better resource than MDN: https://developer.mozilla.org/en-US/
I also like https://css-tricks.com
The common advice now is to only use CSS that is supported in the last two major versions of each major browser. You can check any css property's support here: https://caniuse.com/
> Imho this is a reason why markdown and other rich-textual formats appeared.
Markdown is a superset of html and through it contains css through the style element
> Btw is there a some “w3schools” for recent CSS?
CSS is constantly changing, I'd recommend the following for how to apply new CSS features:
- https://www.youtube.com/@KevinPowell
MDN is the best technical reference: https://developer.mozilla.org/en-US/
- You can search any css property in there and it will return all the rulesets for that property.
To see how people are using CSS, I'd recommend:
- Mastodon/fediverse
- Reason: All other social networks only have webdevs who sip the coolaid of whatever trend is happening at the moment, they're not actually interested in learning what CSS can do. However, the web devs in the fediverse are actually interested in what CSS can do.
- You can see the proposals here: https://github.com/w3c/csswg-drafts/issues
- Proposals often require experiments which you can find on mastodon/fediverse. For example: https://front-end.social/@kizu
There's also the yearly State of CSS survey to get an overall sense of it: https://2026.stateofcss.com/en-US/
There's a much easier way—Baseline: https://web.dev/baseline
CSS features that have been available for 30 months for Chrome, Edge, Firefox and Safari are "Widely Available" and are safe to use.
Commonly used tools like Browserslist and Stylelint support checking for Baseline compliance.
Browsers seem to release a major new version like every 2 weeks now. So this statement does no longer hold true. You'll have a lot of users with broken results, if you follow that advise (everyone who uses a ESR or is otherwise limited with updates and behind a month)
I'd say for safety one should target the browsers of the last 4 years at least. You easily can write new CSS —or Javascript— and then use a conversion during deployment to target the lower standards. That's more important for Javascript than for CSS though. If only half of the sites would deploy with `babel` and with some compatibility in mind 80% less of the web would be broken for users with older browsers.
Nope.
Safari only releases a major version once a year, so by only using features that are available in the last two major versions of each major browser, you're already waiting at least 2 years.
> I'd say for safety one should target the browsers of the last 4 years at least.
No.
Supporting browsers that old incentivises users not to update, which causes them to be insecure.
Better they know that something is broken so they have a greater incentive to update.
There's also https://modern-css.com/.
These days the most limiting factor is probably people on phones running out-of-date Android with an ancient browser version. If you aren't caring to test on mobile anyway, as many seem not to, or are happy to not spend time catering specifically for that fraction of a % of people in your target audience, this concern goes away and unless you are targetting an industry known for slowly updating its users desktops you are pretty safe using anything that has been in both Chromium and Firefox for two years or more (a couple of ESR releases ago).
The fact that modern CSS and native browser APIs can handle so much of this makes the web feel simpler and more capable at the same time.