Challenges for CSS
What will CSS look like five, or even twenty, years from now?
Will there be a better style sheet language? Will there be a
better language for creating GUIs than the HTML+CSS pair? Impossible to
say. But CSS has a few gaps that someday will have to be filled,
by CSS itself or by its successor. Here are some:
I plan to update this page over the year, so that by 17 December
2017 it can serve as a program for CSS (or its successor…).
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.
- 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.
- 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
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
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
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:
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 text1, 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.
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
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
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
Brave […] specialty.</topic>
can be made to display like this <details> element in HTML:
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
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