[Implementers’ doc] [Authors’ doc]
User settings are a complex issue as CSS authoring is liberal by nature.
In theory, this issue should be easily solvable using UA and user stylesheets as they turn precedence upside down for
!important. In practice, we don’t have any universal mechanism to set a stylesheet as an UA or user stylesheet: all the stylesheets we manipulate are created equal in scope; they are considered authors’ stylesheets by the rendering engine.
The following list is the order of priority we should emulate:
We’re referring to the W3C’s priority of constituencies. In other words:
Users’ styles > Authors’ styles > Implementers’ styles
Which is why conceptualizing this issue as intents may help.
Typography is not just a set of settings though, it’s a complex system in which some settings impact others. For instance, font-size impacts line-height and line-length, which impacts the number of columns.
It is up to implementers to pick their preferred approach (minimal set, presets, minimal set/presets with advanced settings, maximal set) since it is primarily an UX issue.
Does not apply as we basically manage important declarations for them.
In theory, using
!important is a clear intent the author is willing to enforce some specific style.
!important may be abused, it may be a quick fix to solve a cascading issue – and the author didn’t bother taking user settings into account –, it may be used to enforce some styles in Reading Systems overridding a lot of styles by default, etc.
This case is a complex one. We’re designing Readium CSS with the minimum amount of overrides possible but authors’
!important may conflict with some user settings. Please refer to the following cases.
The user intends to set a personnal preference. They may be used to reading newspapers, where the column length is quite small, but that can create extra issues on the implementers’ side.
Does not apply to authors.
It depends on the implementers’ approach (presets with typographic rules as references Vs. the user can override on a setting-by-setting basis).
The user intends to adjust line-length.
We have to override margins for pagination so the most important style is
max-width, if set.
The author intends to limit line-length, but it is unclear they are doing it because some Reading Systems don’t or because they want to enforce one specific (max) line-length.
The user intends to improve visual comfort.
Does not apply to authors but it could if we create a public “API” for authors to express intents related to reading modes.
Since authors have filed very few use cases at the moment, this is highly conditional.
Implementers should take two main variables into account: contrast and luminosity, which means they might want to invert some images or get rid of backgrounds in night mode.
Inverting images that should be inverted in night mode can’t be done well without an author’s intent though.
Please note Readium CSS provides two extra options to manage images in night mode:
Those are two opt-in mechanisms for users, ideally set on a book-by-book basis since they may work well with some publications but badly with others.
The user intends to at least override the typeface used for body copy.
For a11y-related typefaces (Open Dyslexic, bold style of sans-serif family), the user probably intends to replace headings, scripts and italics as well.
p.class is so common that it should not be considered an intent per se. While
p.class is debatable, it is so widespread in practice (some authoring tools output
font-family for every paragraph style) that it can’t be considered an intent in pure CSS. Implementers indeed have to validate it against the document’s
font-family can be set for headings (
font-family for specific elements should be considered a proper intent: a font may indeed be used to make the structure clearer, achieve visual effects (e.g. manuscript letter) or make sure different languages are displayed correctly.
For a11y-related settings (e.g. Open Dyslexic), you should override those elements too, as not doing it will impact the reading experience negatively. Please make sure to provide a font-stack that covers a large amount of different languages though.
In any case, math and SVG contents should not be overridden.
The user intends to adjust the font-size, either because it is too small or too large by default.
This may be considered an intent if a
font-family is set for body copy.
The author could be trying to compensate for a smaller or larger x-height.
You might want to normalize
font-size (à la iBooks) if the user changes the typeface.
The user intends to adjust line height, either because it is too solid or too loose by default.
The author may be trying to enforce vertical rhythm but you really can’t tell if you don’t analyze the entire stylesheet.
Common elements for the body copy should be overridden (paragraphs, lists…).
The user intends to set a personnal preference. Although it is a bad practice in typography, some may prefer justified text without hyphenation.
If set for body copy, this is a publisher’s or author’s preference.
If explicitly set to
center for paragraphs, to which
left is added for headings, it is a clear intent.
Elements such as headings, tables, pre, etc. should not be overridden: declaring
text-align: justify for those elements would indeed degrade legibility.
The user intends to enable/disable justification, possibly depending on the default/author’s styles.
Since hyphenation works in combination with justification in proper typography, this should be considered a preference or the enforcement of a typographic rule.
Typography-wise, it is OK to hyphenate body copy with
text-align: left, it is critical to hyphenate body copy with
We are taking care of elements which should not be hyphenated in the patch stylesheet so that you don’t have to.
The user intends to change the paragraph styling i.e.
text-indent and vertical margins. Problem is this can either be a preference or a specific need (e.g. dyslexia).
This is a publisher’s or author’s preference.
There indeed is two accepted options for styling paragraphs:
Ideally, paragraphs’ formatting should be handled as a whole. There is nothing preventing implementers to provide users with both settings though.
The user intents to customize
letter-spacing, which can help for dyslexia for instance.
It is very rare authors’ will use those CSS properties for body copy. They may use it for headings though (small capitals, large font-size, etc.).
In any case, implementers should force those settings for body copy.
The user intends to disable ligatures. This setting applies to the Arabic and Persian scripts, and is believed to help dyslexic readers as
word-spacing in Latin.
In those scripts, ligatures will be enabled by default. It’s neither an intent or preference, it is just the way it works.
Implementers must enforce the user preference, as it is primarily related to a11y.