Default styles approach

[JayPanoz]

Since the default stylesheet is the next phase, I’d like to anticipate a little bit. It would be useful to collect feedbacks while I’m testing pagination and page margins.

Contrary to what one may think at first sight, this is something for which I’ll have to take authors expectations into account. Indeed, there is a bunch of people relying entirely on default styles (think about hr for instance) and, consequently, they won’t bother embedding a custom stylesheet. Others might rely on default styles and only customize some elements (e.g. :link color or small-capitals, etc.).

The good news is that we already have a default stylesheet, the UA’s. I validated UA stylesheets against HTML5 suggested rendering and can report there are some differences, but it doesn’t impact default styles (flow and phrasing content, quotes, headings, lists, tables, embedded content, images, etc.).

The bad news is we don’t necessarily want to use it AS-IS. HTML5 suggested rendering doesn’t have to deal with user settings (font size, line height, margins, etc.), fragmentation (i.e. page breaks, widows and orphans), hyphenation and reading modes (especially night modes).

Please note I still have to check HTML4 Suggested Rendering for ePub 2.

I can probably save us a lot of issues by adapting and modernizing HTML5 suggested rendering a little bit:

1. use a smaller type scale so that headings don’t become an issue when the user sets a bigger font-size;
2. redefine colors so that borders become white in night modes;
3. tweak sup and sub so that they don’t break the line height;
4. redefine horizontal margins and paddings for block quotes, figures, lists, etc. to accommodate smartphones (40px is really really huge, especially when you start nesting lists since it can grow to 120px or 160px);
5. redefine tab-size so that one tab is not 8 spaces in pre (I understand why this default value but find it quite stupid considering smartphones exist);
6. as far as I can tell, although it’s not managed via UA stylesheets, some browsers default font-variant-* quite well but I can normalize it to make sure all UAs have the same values (that’s like 5 or 6 lines of CSS);
7. take care of basic fragmentation + hyphenation.

Then the question will be “do we make it more bookish?”

Bookish implies stuff as:

• picking a font-stack and defining a font-family for body (some UAs default to Times New Roman, which has been heavily criticized by Matthew Carter because it’s way too thin for HD displays, and it doesn’t ship with Open Type Features which could improve legibility, while more modern fonts do)
• replacing paragraphs’ margins with a text indent (we would be quite possibly be breaking authors’ expectations there);
• in that case, you could also reset the text-indent for paragraphs following a heading (more elegant, visual harmony, etc.);
• Forcing pre to pre-wrap so that we don’t have overflow-x (probably more readable though not perfect);
• centering figures;
• taking care of vertical rhythm so that page baselines are aligned, at least for text (images are another issue CSS Rhythmic Sizing is trying to solve);
• etc.

My opinion at the moment is that we should probably improve HTML5 Suggested Rendering (think about it as EPUB Suggested Rendering if this can help conceptualize it) and use themes for the bookish changes. In other words, power to the user. On the other hand, there is bookish stuff which could be part of defaults, especially declaring a font-stack since the default font-family may not support all languages (anticipating CJK/RTL there).

I know the idea is to provide default styles for unstyled publications but we could use this stylesheet to improve/help authors a little bit (thinking about Open Type, hr + night modes, etc.).

I’ll also have to deal with CJK and RTL. I’ve done some Japanese in the past, am familiar with some best practices, but it was in western publications. In other words, I’ll have to do extended research to make sure we can manage CJK and RTL well. In addition, we could probably write “best practices” for this so that it can help both implementers and authors.

On a related note, there is the W3C Typography repo which could be useful. It points to typographic information relevant to the web platform.

The “help wanted” label is precisely for CJK and RTL. I can find ressources, best practices, examples, etc. but I’d like to make sure we have bulletproof styles there. Typography experts dealing with CJK and RTL are warmly welcome to weigh in this issue, and do “styles review” once the default stylesheet is created.

For instance, my assumption is that we could manage that by targeting lang but that approach may be completely wrong for various reasons. So I’d like to know how experts manage that in practice.

[JayPanoz]

Here’s something you could consider an early draft of the “Improved Suggested Rendering” approach if it can help.

It’s relying on HTML4 and HTML5 suggested rendering because I have to deal with ePub2 and EPUB3.

Please note it’s only managing latin at the moment but feel free to annotate if you see some declarations must be overridden for CJK/RTL.

/* We could do without this, line-height + unit => computed value is inherited, it is not recomputed for each font-size. */
body {
  font-size: 100%;
  line-height: 1.5rem; /* normal might be a little bit too solid, especially since we’ll have fonts with different x-heights in user settings */
}

/* Fragmentation */

body {
  orphans: 2; /* Default is 3 */
  widows: 2;
}

figcaption, th, td {
  orphans: 1;
  widows: 1;
}

/* May work someday but currently doesn’t */
h2, h3, h4, h5, h6, dt, hr {
  -webkit-column-break-after: avoid; 
  page-break-after: avoid;
  break-after: avoid;
}

h1, h2, h3, h4, h5, h6, dt, 
figure, tr {
  -webkit-column-break-inside: avoid;
  page-break-inside: avoid;
  break-inside: avoid;
}

/* Hyphenation */

body {
  -webkit-hyphenate-limit-lines: 3;
  -ms-hyphenate-limit-lines: 3;
  hyphenate-limit-lines: 3;
}

/* Making sure hyphens are disabled for some elements */
h1, h2, h3, h4, h5, h6, dt,
figcaption, pre, caption, address,
center {
  -ms-hyphens: none;
  -moz-hyphens: none;
  -webkit-hyphens: none;
  -epub-hyphens: none;
  hyphens: none;
}

/* OTF — Normalization */

body {
  font-variant-numeric: oldstyle-nums proportional-nums;
}

h1, h2, h3, h4, h5, h6, dt {
  font-variant-numeric: lining-nums proportional-nums;
}

table {
  font-variant-numeric: lining-nums tabular-nums;
}

code {
  font-variant-ligatures: none;
  font-variant-numeric: lining-nums tabular-nums slashed-zero;
}

rt {
  font-variant-east-asian: ruby;
}

/* Common — Corrected type scale + modernizing margins with rem */

h1 {
  font-size: 1.4375rem;
  margin: 2rem 0;
}

h2 {
  font-size: 1.3125rem;
  margin: 2rem 0 1rem 0;
}

h3 {
  font-size: 1.125rem;
  margin: 1rem 0;
}

h4 {
  font-size: 1rem;
  margin: 1rem 0 0 0;
}

/* h5 and h6 have always been a pain to style but their suggested font-sizes are an abomination for readability/legibility, especially in bold */

h5 {
  font-size: 1rem;
  margin: 1rem 0 0 0;
  font-weight: normal;  /* debatable */
  font-style: italic; /* debatable */
}

h6 {
  font-size: 0.875rem;
  margin: 1rem 0 0 0;
  font-weight: normal;  /* debatable */
  text-transform: uppercase;  /* debatable */
}

p {
  margin: 1rem 0;
}

/* Can’t declare a width, it’s an horizontal rule in HTML4, not a thematic break like in HTML5 */

hr {
  color: inherit; /* night mode */
  margin: 1rem auto;
  border: none;
  border-top: 1px solid currentColor; /* night mode */
}

figure {
  margin: 1rem 0;
  text-align: center; /* debatable */
}

figcaption {
  font-size: smaller; /* debatable */
}

blockquote {
  margin: 1rem 5%; /* 5% = 5% of the container’s width, not an absolute margin of 40px */
}

ul, ol {
  margin: 1rem 0;
  padding-left: 5%;
}

table {
  border: 1px solid currentColor; /* night mode */
  border-collapse: collapse;
  empty-cells: show;
}

thead, tbody, tfoot, table > tr {
  vertical-align: top; /* may be more natural */
}

th {
  text-align: center; /* HTML4 */
}

th, td {
  border: 1px solid currentColor; /* night mode */
  padding: 4px; /* 2px default may clearly not be enough for legibility */
}

aside {
  margin: 1rem 0; /* aside may be used for a variety of use cases, max I can do */
}

dd {
  margin-left: 5%;
}

pre {
  margin: 1rem 0 1rem 5%;
  white-space: pre-wrap; /* Preventing overflow, which might help with JS */
  -ms-tab-size: 2;
  -moz-tab-size: 2;
  -webkit-tab-size: 2;
  tab-size: 2; /* default is 8 */
}

abbr[title], acronym[title] {
  text-decoration: dotted underline; /* Normalization */
}

/* Preventing line-height breaking */

sub, sup {
  position: relative;
  line-height: 1;
}

sub {
  bottom: -0.2ex;
}

sup {
  bottom: 0.5ex;
}

nobr wbr {
  white-space: normal; /* enforcing HTML5 SR */
}

Please note I can fine-tune values depending on media queries but it will add complexity.

[JayPanoz]

FYI, we discussed this during the Readium 2 Engineering Meeting. For unstyled publications, we agreed:

• For EPUB, we’d like ebook-oriented default styles;
• For more generic publications, an HTML5 generic style would maybe be better but we don’t know much about generic Web Publications, so we can postpone this.

What I’m very likely to do:

• design a minimal base module, built upon UA Stylesheets and helping us deal with some issues (night mode, margins);
• treat the ebook-oriented default styles as a “theme”, which means designing the boilerplate a few phases in advance. That will make the default styles customizable but it won’t be like others themes per se. Implementers could for instance load this css only if they don’t find styles in the EPUB file.

Section and headings will be managed in the second stylesheet, as will vertical rhythm, etc.

[llemeurfr]

I personally like the idea. Any comment on this?

[whmccoy]

I think we should strive for convergence (ultimately, zero distinction between "user agent" and "reading system"). Browsers already can "mangle" style preferences set by content (web pages) on behalf of the user, it's just that they don't do it by default but only if the user is in Chrome "Reader Mode", Safari "Reader View", Edge "Reading Mode", etc. We can consider EPUB 2/3 as implicitly expecting the renderer to defaults to such "reading mode" (unless "leave me alone" bit is set for a content element), unlike generic web pages which default to respecting the style preferences in the content. As far as future Web Publications, we shouldn't make any assumptions yet (I suspect we may have the opposite bit - an optional metadata setting to request a reading-optimized presentation, since the expected default for regular web pages is not to do that) but if we set expectation that R2 Navigators should accommodate both respecting style preferences in the content and overriding them to give a reading-optimized presentation then the question of which to choose as a default is kind of a detail.

[JayPanoz]

@whmccoy You’re right and this is my preferred approach as well.

For EPUB2/3, I’ve started analyzing the samples we have and it seems they are also expectations to be read between the lines of CSS authors: content will be paginated by default, the “page” size and ratio will be constrained, such tag is using those styles by default and it suits me, etc. So we have to take those expectations into account.

The “base” stylesheet would be just adjusting HTML5 Suggested Rendering for some specific expectations (pagination → page-breaks, page sizing → horizontal spacing, night mode → border colors set in HTML5 SR, etc.)—of course it will also work for scroll. It could be consider a little helper: it helps with pagination but doesn’t alter the nature of UA stylesheets.

And the default would be up to implementers.

More generally, for the CSS design itself, we’re referring to the priority of constituencies so, basically,

User styles > Author’s styles > Implementers’ styles. 

For Web Publications, I checked UA stylesheets and can report you can rely on HTML5 Suggested Rendering. So AFAIC, the scope of default styles is limited to EPUB2/3.

[JayPanoz]

I’ve just created a “patch” stylesheet, which implies it isn’t a base per se but a utility you can use for paginated content.

You can find it on the pagination branch: https://github.com/readium/readium-css/blob/phase1-pagination/readiumCSS/pagination/readiumCSS-html5patch.css

At the moment, it is designed with EPUB-as-we-know-it in mind, it manages:

• fragmentation (widows, orphans, page-break);
• hyphenation;
• open type features normalization;
• night modes (border-color);
• horizontal spacing (5% is ± the value you get when taking 40px in a desktop context);
• HTML5 Suggested Rendering enforcement when User Agents have different styles.

It extends HTML5 suggested rendering when needed (fragmentation, hyphenation) and only if needed. Else, it adjusts styles that are currently defined in the HTML5 spec.

This obviously is a first version, we can agree on different values.

[JayPanoz]

References for upcoming work related to CJK:

• Styling vertical Chinese, Japanese, Korean and Mongolian text
• Best Practices for Chinese Layout
• Seven rules for perfect Japanese typography
• Better together: Displaying Japanese and English text on the web

References for upcoming work related to RTL:

• Creating HTML Pages in Arabic, Hebrew and Other Right-to-left Scripts

[JayPanoz]

More references for CJK:

• Typesetting conventions and best practices for CJK
• Chinese typesetting basics
• Japanese typesetting with English version InDesign
• Requirements for Japanese Text Layout
• Getting started with Korean typesetting

From the various references I can find in english, it now looks pretty clear to me that we might build some kind of “minimum viable support” but not much more.

Docs in languages I speak are few and far between, most are summaries, and we obviously need expertise there.

I would say that adapting pagination, scroll, base and default so that they can play nicely with vertical-writing and RTL would be a good foundation (we would then be on par with other advanced Reading Systems).

For everything else (user settings, typefaces selection, etc.), we definitely need native speakers knowledgeable in typesetting. Ideally, that should be “fork and pull request” though, as it is really really difficult to get an idea of browsers’ interop if you don’t typeset those languages yourself.