Overview of new CSS specs of interest

[JayPanoz]

For the sake of transparency, I'm submitting a snippet of documentation on CSS specs that could be of interest in the context of user settings/overrides, and their impact.

The goal is to publish this overview and start a discussion.

As a reminder, a list of impactful specs was documented in ReadiumCSS back in the days.

There may be use cases that have been overlooked, or specs that flew under the radar and could have helped solve issues implementers encountered. It’s also a lot healthier to have the conclusions challenged whenever possible as that can also at least show there’s a need to clarify.

Logical Properties

This could help simplify internationalization by replacing physical dimensions (margin-top, padding-left, width, max-height, etc.) with axes (block and inline) tied to direction, text-orientation, and writing-mode.

In other words, the same styles could theoretically be used for LTR, RTL, and vertical writing.

However, the impact is limited as only a handful of ReadiumCSS’ declarations (mainly but not all “vertical” modules and submodules) would benefit from it, and it wouldn’t help get rid of CJK and RTL stylesheets as they also differ in user settings.

MDN docs

Support : Chrome 89, Safari 15, FF 66 (late 2021)

Container queries

This has no impact on ReadiumCSS. While it could be used to fine-tune the default stylesheet for unstyled publications – and font-size normalize module –, it doesn’t make much sense considering these were designed with small screens in mind.

Container queries may be more interesting to authors/publishers, given they can serve as media queries of sorts in the multicolumn context, something they have not been able to target reliably so far.

MDN Docs

:has pseudo-class

This pseudo-class allows to style an element based on its descendants, but can also be combined with CSS selectors like +, ~, > or other pseudo-selectors like :not.

In theory, it could be primarily used to handle exceptions when applying overrides/user settings, although use cases are unknown at this point.

It’s important to note it could be used as a progressive enhancement, but create inconsistencies as a side-effect e.g. app handling things differently based on the browser/OS version used, which could in turn result in additional bug reports.

MDN docs

Support: Chrome 105, Safari 15.4, FF 121 (late 2023)

Comparison functions

The comparison functions of min(), max(), and clamp() compare multiple calculations and represent the value of one of them.

The major use case is fluid design, including fluid typography, which implies these functions can be very useful for authors/publishers but not so much for reading systems.

Since we don’t have access to the authors/publishers’ value, this can’t be used to get rid of the font-size normalisation required for the font size user setting. Indeed, one could have imagined using min() for elements’ font-size to force some sort of normalisation only if the value is set using absolute units in authors/publishers’ stylesheet. But we can’t retrieve this value using CSS…

Another use case could be to force a floor or a ceiling for font-sizes when applying font-size normalisation and changing the font-size so that headings are not too huge or other elements too small. However, that would imply some UX weirdness as increasing/decreasing font-size would result in an inconsistent result – with headings’ size not increasing for instance. This is probably not what users expect.

MDN Docs

Support: Chrome 79, Safari 13.4, FF 75 (mid 2020)

Cascade layers

Cascade layers offer to create separated cascades you can access anywhere in the files, and to layer them in the order we want. This doesn’t mean that each layer is scoped though, it’s more of an organization tool, not a scoping mechanism.

In theory, this could have ended the “before/after mechanism” ReadiumCSS is relying upon by using layers instead, and provide a single dist stylesheet.

But this wouldn’t save Reading Systems from doing some work since un-layered styles always have the priority on layered styles. In other words, they would have to layer authors/publishers’ stylesheets.

In practice, this is consequently just an alternative option with its own pros and cons. It doesn’t really solve this issue more efficiently, only in a different manner and doesn’t offer more reliability (no scoping) nor ease-of-implementation (Reading Systems don’t get rid of something, they replace option A with option B).

MDN Docs

Support: Chrome 99, Safari 15.4, FF 97 (early 2022)

[JayPanoz]

Note: CSS features – as opposed to whole specs – to follow e.g. i18n in Chromium

[JayPanoz]

Not much seems to be of interest in new CSS Features in existing specifications, but a handful of new properties related to
text.

Text wrapping mode

CSS Spec

Pretty

As described in this Blink dev conversation:

Value pretty adjusts line breaking to avoid a short single word on the last line (also known as typographic orphans.)

When text-wrap: pretty is specified, paragraphs that will end up with a short single word on the last line are adjusted so that the last line has two or more words.

The algorithm is based on the Knuth-Plass algorithm, as used by TeX. It computes scores for all candidates, and chooses the best one. To balance between the typographic benefits and the performance impacts, it adjusts the last 4 lines of paragraphs that meet certain conditions.

There are several issues though:

• Support is limited to Blink/Chromium-based browsers and webviews
• it specifies the UA should bias for better layout over speed, which may result in performance issues, especially for larger HTML files.

While that could help achieve a more book-like experience in terms of typography, it’s worth investigating the possible performance impacts before adding it into ReadiumCSS.

MDN Docs

Support: Chrome 117, ❌ Safari, ❌ FF (Late 2023)

Balance

This value allows multiple lines of text to have their lines broken in such a way that each line is roughly the same width, often used to make headlines more readable and visually appealing.

Support is better, and it could be used for headings in the default stylesheet used when publications don’t ship with one.

For publications with their own styles, it would probably create confusion and generate issues from authors.

MDN Docs

Support: Chrome 114, Safari 17.5, FF 121(mid 2024)

Text i18n

Internationalization features are making their way into CSS Text Module Level 4, with some bound to become a default, according to this presentation article from Chrome.

The most interesting one would be word-break: auto-phrase, as it has the same effect as text-wrap: balance for headings in Japanese.

Others should probably not be tinkered with, unless requested by customers/consumers if the browsers’ default has any negative impact on existing publications.

CSS Spec

Support: Chrome 119, ❌ Safari, ❌ FF (Late 2023)

Text A11y

Unlike books for adults, Japanese books for young children often feature spaces between sentence segments, to facilitate reading. People with dyslexia also tend to find this style easier to read.

It seems word-space-transform: ideographic-space could be used as a way to implement a word-spacing user setting in Japanese, although it looks like an on/off switch that you can’t fine-tune to a specific length, so it wouldn’t be an alternative to what was implemented in Thorium.

CSS Spec

Support: missing in Caniuse