Challenges for CSS

Page templates

One example is page templates. It should be possible to designate a number of regions on a page each of which gets a certain kind of content. That can be on a single, scrolling page, or on one of the pages in a paged rendering. Those regions can be aligned to a virtual grid, or placed arbitrarily (although that could be a grid, too, just a less regular one). And the regions can be of several types:

Body text

The most common region, the kind that holds most of the content of a typical document, is a region that can contain a part of a stream of text. Such a stream is made up of a subset of the elements of the document. The stream is divided over a chain of regions, those on previous pages, zero or more on the current page, and those on following pages.

Running headers

A region can contain a copy of the first or last header on the page, or, if there is none, of the most recent page that had one.

Pull-quote

A region can contain an element flagged for display as a pull-quote. Unlike running headers, which take an element from a previous page if there is none on the current page, a pull-quote region will just not be displayed if there is no element. On the other hand, if there are more elements on the current page flagged for pull-quote than there are pull-quote regions, the extra elements will simply not be displayed.

Footnotes

A footnote stream is like body text, in that it fills a chain of regions, except that footnotes may not appear on an earlier page than where the footnote is referenced from, i.e., footnote regions will be omitted from pages if the next text in the footnote stream is referenced from body text that is on a later page.

The current running headers in CSS, apart from being limited to being at the edges of a page, also only contain text in a single style. That is surprisingly often good enough, but clearly not always: It should be possible to make running headers with text in a mix of font styles and also containing such things as superscripts, tables and mathematical formulas.

Punctuation, or: semantic vs typographic mark-up

In some cases that currently pose problems, CSS would be enough if we could assume a transformation step, e.g., with XSLT, before CSS is applied. E.g., the flexbox properties are powerful, but can only align sibling elements. But transformations make the style sheet much harder to write. A solution inside CSS and that just allows visual rearrangements and alignments would probably be easier and enough in many cases.

The following is such a case and could probably be solved with a transformation to transform the source document into a set of display elements prior to styling (what XSL calls formatting objects).

There are often cases where typographic, i.e., aesthetic rules clash with the logical structure of text. Usually, these clashes involve punctuation: quote marks, commas, etc.

E.g., it is common in many typographic traditions that punctuation that immediately follows a word takes on the same style (bold, italic) as that word. But if that word is in italics because it is, e.g., a metaphor, then the logical mark-up would enclose just the word, not the colon or other punctuation after it. Current CSS cannot put a colon in italics simply because it follows a word in italics.

If, because of this restriction in CSS, you put the closing tag after the colon (<em>hat:</em>), it may be that the mark-up has to be changed in a translation (French: <em>chapeau</em> :)

A (probably) related problem in CSS is that spaces are treated as characters, rather than as mark-up and thus it is difficult to get rid of them. E.g., if the mark-up is … some text <note>a footnote</note> we would like to render that as … some text¹, but there is a space after text that gets in the way.

Maybe a special rule for footnote markers can solve this case, but there are are other places where we want to remove spaces and control the space with exactly specified margins instead.

Copy-fitting

In some strict, grid-based layouts, it is common to make text completely fill a given space. If the text is too short, the extra space isn't left below the last line, but is somehow distributed: slightly larger line height, slightly larger font size, bigger header font, or a bigger image (if there is an image that can be scaled).

The problem is when a document is displayed with somewhat unknown fonts, font sizes and viewport sizes (the normal case on the Web) and the designer isn't there himself to adjust the various parameters. In that case there should be a way to specify in the style sheet what the goal is (fit the text to the available space) and which parameters the designer wants to be variable (font size, line height, word spacing, hyphenation, etc.), in what order and by how much.

Some perfectionist authors might even want to go as far as providing alternative texts (shorter or longer synonyms, abbreviations, alternative spellings, such as 9 instead of nine, etc.). That requires not just features in CSS, but also in the mark-up (typically HTML), in the form of elements that provide alternatives. There are some elements in HTML already that encode alternatives: <img> with its alt attribute, and nested <object> elements. But they provide alternatives for different situations.

HTML5's <details> element

The <details> element in HTML5 is meant to allow a reader to choose between, typically, a short phrase and a long text. However, CSS cannot control which of the two is rendered. And CSS also cannot cause another element to behave like the >details> element.

That is not something new. The <img> element is likewise magic. Whether the image or its text alternative is displayed is not under the control of CSS.

It seems useful, however, to have the possibility to declare that an element in generic XML that looks like this

<topic><name>Three choices</name>
Brave […] specialty.</topic>

can be made to display like this <details> element in HTML:

<details><summary>Three choices</summary>
Brave […] specialty.</details>

Probably this can be done with new keywords on the 'display' and/or 'content' properties.

CSS should also have the possibility to style the element differently when the contents after the <summary> are shown or not shown. HTML's <details> element has a magic open attribute, which is present when the contents is shown and absent when it isn't. That doesn't work for generic XML, of course. CSS could instead have pseudo-classes for the two states.

Properties to determine whether content is initially shown or hidden are also needed. These could, in fact, make any element into an element with two (or more?) states, between which the user can toggle.