[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’ stylesWhich 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 practice, !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.
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.
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.
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.
A different 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.
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.
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.
Clear intents should not be overridden. This requires JavaScript though, and it could be easier to manage exceptions than all the elements which must be overridden (less DOM manipulation).
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.
Typography-wise, it is OK to hyphenate body copy with text-align: left, it is critical to hyphenate body copy with text-align: justify.
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).
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 word-spacing and/or letter-spacing, which can help for dyslexia for instance.
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.
Implementers must enforce the user preference, as it is primarily related to a11y.