Hacker News

CSS properties you should know for better text designs

132 points by ibobev ago | 22 comments

myfonj |next [-]

Some caveats worth mentioning yet missing there:

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...

masklinn |root |parent [-]

Recommendation (2) assumes any UA which supports background-clip supports -webkit-text-fill-color. That seems rather dodgy.

Wrapping the rule in a feature query seems a lot cleaner and more reliable.

myfonj |root |parent [-]

> That seems rather dodgy.

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.)

chrismorgan |next |previous [-]

letter-spacing is massively overused. I have Firefox set to only use my chosen fonts (and highly recommend it: it makes the web much better), and this reduction in variation makes non-zero letter-spacing much more obvious to me. At typical body sizes, I will tend to notice (and be displeased by) letter-spacing changes of less than 1% (I notice even 0.1px often).

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.)

robin_reala |root |parent |next [-]

*:not(h1,h2,h3,h4,h5,h6) { letter-spacing: initial !important } in your user styles should fix point 2. Point 3 slightly harder to fix yourself.

chrismorgan |root |parent [-]

I have seriously considered blocking letter-spacing outright in user stylesheet a few types over the last four or five years, but decided to keep it to keep an eye on how badly people are doing things.

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.

gucci-on-fleek |root |parent |previous [-]

> There are only three places where I hold letter-spacing of any kind to be acceptable:

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...

chrismorgan |root |parent [-]

I should clarify that I speak only of English and general web content CSS. I’m happy to disqualify 4 and 6 on those grounds (you decide which grounds I use for Fraktur!).

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.

addedlovely |next |previous [-]

Was expecting to see text-wrap:balance there. Solve away your orphans! https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

montroser |next |previous [-]

I think their heading `box-decoration-mode` is actually meant to be `box-decoration-break`. That's the real property that exists, and is documented on MDN.

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

vivzkestrel |next |previous [-]

- for a website that talks a lot about web, css your pagination is broken

- 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?

sixtyj |next |previous [-]

I always tell myself that I should use backwards-compatible CSS only.

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?

mostlysimilar |root |parent |next [-]

> 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

alwillis |root |parent |next |previous [-]

An excellent list of modern CSS: https://nerdy.dev/cascading-secret-sauce.

There's also https://modern-css.com/.

dspillett |root |parent |next |previous [-]

> I vividly remember IE and many hacks to have css elements properly working in it…

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).

spartanatreyu |root |parent |previous [-]

> I always tell myself that I should use backwards-compatible CSS only. > > I vividly remember IE and many hacks to have css elements properly working in it…

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

- https://ishadeed.com

- https://www.joshwcomeau.com

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:

- https://codepen.io/

- 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.
To see future CSS:

- 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/

alwillis |root |parent |next [-]

> The common advice now is to only use CSS that is supported in the last two major versions of each major browser.

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.

spartanatreyu |root |parent [-]

Baseline is already shown on both caniuse and mdn, which is why I suggested them.

binaryturtle |root |parent |previous [-]

> The common advice now is to only use CSS that is supported in the last two major versions of each major browser.

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.

spartanatreyu |root |parent [-]

> 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)

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.

iammrpayments |next |previous [-]

At this point I don’t use photoshop anymore, I just make a html document to make the image and then I can easily translate it to 50+ languages

searchstefano |previous [-]

CSS has come a long way. On several sites I’ve been able to completely remove JS for things like popups, mobile menus, and open/close interactions.

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.