A Touch of Class

fantasai
2019-04-02

Designing CSS

If you are looking for the CSS Day 2019 talk on Vertical Rhythm, Slides are here. [CSS Day website is currently linking to the wrong slides.]

Translations: 日本語のビデオ(すみません質の悪い)

Last September, I participated in the W3C Workshop on Digital Publication Layout and Presentation in Tokyo, where I had the opportunity to expand on the design principles of CSS I first presented in my Evolution of CSS Layout talk in 2011. I re-presented in the afternoon with Florian providing sequental translation into Japanese for the APL symposium. Luckily someone took (a very terrible but somewhat intelligible) webcam recording of the talk, so now I can present it to you! This is a slightly-polished transcript of that afternoon presentation. (It's slightly different from the morning edition, due to the different audience.) Maybe one day I will turn it into a properly-written article. [Slide Deck]


    Table of Contents

  1. Introduction

Designing CSS

Presented by fantasai

Introduction

I work on CSS, so my talk will be about CSS. But we will also talk about Web technology architecture at a higher level as well.

What is CSS

First I want to address the question of, “What is CSS?”

A basic Web page is composed of HTML and CSS.

If we have a document like this, then the HTML looks like this.

You can see the text, and you can see annotations explaining the structure of the document, which part of the text represents which part of the document.

CSS is just annotations, which are keyed off the HTML, that describe its presentation. For example, headings should use font, paragraphs should use this much spacing, this part should be arranged as a sidebar... Fundamentally CSS is this simple.

Designing for Web vs Print

Designing for the web is very different from designing for print.

You often don't have any control over the content.

You almost never have control over the display size or orientation.

However, even with all of these possibilities, we can create interesting designs that are meaningful and interesting at all different levels of screen size without designing separately for every single possible size.

Principles of Web Architecture

Because of the environment of the Web, there are five principles of Web architecture.

Cross-Device & Cross-Platform

The first one is that the Web is cross-device and cross-platform.

You can take one page and display it to the reader on the screen, in print, in braille, through a terminal window, through speech synthesis, on mobile devices, etc.

We can display the Web page on any screen screen size, in any orientation, any resolution.

We can display the Web on any operating system. There have been Web browsers for all of these and more, whereas proprietary systems will typically only run on one or maybe two operating systems.

The Web is renderable on multiple different implementation architectures. The design of technology we build for the Web must not be specific to any specific browser's architecture so that every browser can render the Web and also future browsers with architectures we have not considered can also render the Web.

The Web has to work on many devices including with many different input types. Whether you have a mouse or a keyboard or both or a touchscreen or all three or something else, we should always be able to interact with the Web. It's not enough to make it possible to interact with the Web with each of these devices; but they must work by default, so that when the author creates a page they don't have to be specific about which input device to support. This also means that when we create new input devices, they automatically work with the Web.

World-Wide Web is World-Wide

Another principle is that the Web is world-wide. That means it needs to work for all writing systems, for all languages, and for all combinations of languages. In our increasingly interconnected world, there are many more examples of documents or parts of documents with mixed languages and writing systems.

Forwards- and Backwards-Compatibility

Another principle is forwards- and backwards-compatibility. Backwards-compatibility means that content that works right now will continue to work in the future. Forwards-compatibility means that an implementation that reads a document from the future will be able to process as much as it can understand without failing immediately when it encounters new stuff.

This allows a transition from the old technology to the new technology by making it possible for authors to use new technology even before it is completely available everywhere. The techniques for authoring in this manner: one is called progressive enhancement, in which you write for the most basic implementation and add enhancements for the new ones; The opposite approache is graceful degradation, where you write for the new browser, and create a fallback behavior for the older ones that don't support the feature that you want to use.

We enable this ability of the Web through two techniques.

The first one is forwards-compatbile parsing. This means that when an implementation encounters syntax that it doesn't understand, instead of aborting and failing render the document entirely, it skips the part it does not understand and continues after that part to finish.

The other technique is that we have levels and not versions in our software. For HTML and CSS, what has been created already and deployed, it does not change. We can add to the capabilities of the language, but we do not change how previously-existing syntax was interpreted. This is a very severe limitation on what we can do in developing the language, because whatever we have done is set in stone. But what it enables is the longevity of content authored for the Web: a Web page authored in 1996 will still work today.

No Dataloss

Another principle is no dataloss by default. The content should always be visible by default. If you did not try to hide it, then you will see it somewhere on the page. This also means we want the content to be readable by default. Even if it “visible”, if you put everything on top of each other, it's not readable. A layout system that by default places everything in the top left corner on top of each other is not a system that we want to have. This is also why the boxes in CSS automatically grow to fit their content, unlike other design systems where you create a fixed-size box, and if there is too much content, it overflows or is clipped.

Separation of Content & Style

Another core principle of Web architecture is the separation of content and style. The HTML gives the structure and the content. CSS is for the presentation. We don't mix the two up.

Why do we do this?

One reason is efficiency: because when you're creating your design, you don't want to, for every paragraph, go and set the style. You set the style once, and for all the paragraphs on the entire website. This is easier to create and to implement, but it also makes it easier to maintain if you want to make a change; and it also saves memory and bandwidth on the website.

Another reason to make this distinction is accessibility. We can access the page not just visually, but also through speech; we can search the content because it is real text; we can display it alternate modes such as reader mode; and we can re-use it for other purpose because we understand the structure of the content rather than only just what it looks like.

Another reason to create this distinction is for variability. It allows us to explore different choices; allow the reader to have different choices; create different renderings on different devices; and to change the design over time without having to go back and change the content.

How do we do this?

We have to figure out the distinction between the structure and the presentation.

This is an example which came up recently, ruby markup. Jukugo ruby can be rendered in two different ways. Actually this is a stylistic preference. So, you should be able to choose between them at the CSS level. The rendering choice should not be encoded in the markup. For example, the original HTML Ruby specification imagined that this rendering of jukugo (compound-word) ruby was equivalent to group (multi-character–word) ruby and should be marked up the same way. And that this one was equivalent to mono ruby, so the characters would be marked up as if they were separate words.

But to make this a stylistic choice, we need to encode two sets of information: both the correspondance of the base character to its pronunciation, but also which characters together form a word. This allows us the choice of these two renderings, but also to allow the ruby inline in parenthese after the word. The same document can be rendered different ways without changing the content, but, when it provides this information, just by changing the properties in the CSS layer. This decision can be made by the stylist rather than the content author, and it can be changed depending on the device or the audience or any other parameter.

[For more information on the design of ruby markup, see Towards a Unified Ruby Model, 2011]

Superpowers of Separation

So we also talked about choices at a higher level. CSS, because it is separate from HTML, can allow the design of a site to change dramatically without changing the markup. Many years ago this website (CSS Zen Garden) was created to demonstrate this power of CSS. This same HTML document has been rendered in many many different styles by different designers. I will show you three of them.

Fundamental Goal of the Web = Accessibility of Information

So, why do we have these principles? We have these principles because the fundamental goal of the Web is the accessibility of information. All devices, all people, all countries, all modes of access.

The Genesis of CSS

Constraints of CSS

What the Web creates for CSS is a very difficult set of constraints:

Unknown display size and orientation
We don't know the display size or orientation when we design our page.
Unknown font availability
We don't know which fonts will be available; even if we request one, it might not be downloaded.
Unknown content
We might not even know what content we are rendering; it could be user-generated or database-generated.
Unknown language / writing system
In some cases we might not even know the language or writing system.
No post-processing
And finally, there is no post-processing. Once we have rendered the page, the user sees it. The author cannot look at it and be like, “Oh, no, that's not quite right. Let me tweak it and then you can see it!” The designer has to tell the computer what to do, and the computer has to figure it out.

Purpose of CSS

The goal of CSS is to be the language in which to express the desires of the author/designer, in a way that the computer can understand, for all of these devices and environments. We can't do this by being very precise and saying “this size, and this position”. We have to express the higher-level constraints, to understand the why of the design, to express the why of this size and this position, for the computer so the computer can say, “Now I will calculate the exact numbers.”

Design Principles of CSS

To create a good, an excellent system that can solve this problem, we have some design principles of CSS.

Flexible
The first one is that all layout system must be flexible. They have to be able to adapt to different sizes without the authors having to explicitly give a different layout for each pixel size.
Powerful
It needs to be powerful, so that the author can express all of the relationships that they care to express in this language.
Robust
It needs to be robust, so that when something is not as the author expected, it still works for the reader. If the content is longer than the author expected; if the longest word is wider; if the line wraps; if the font did not load; if the screen size is smaller, or larger, or a different aspect ratio; the layout must not break. Even if the resulting layout is not optimal and beautiful, it must still be readable for the user. But ideally, at every level it should “fit”, as if it was meant to be at that size.
Understandable
We also need it to be understandable, so the author is able to do these things! If CSS is too confusing and poorly expresses the author’s intent, then we will not be able to achieve these goals.
Performant
And lastly, it needs to be performant, because the user wants to see the page instantaneously, not tomorrow. So certain approaches to doing automatic layout that would be appropriate for a desktop publishing system would not be appropriate for CSS.

I will show you some examples of how we apply these principles to CSS.

Multi-column Layout

This is a multi-column layout. The first case we asked for two columns; the second case we asked for columns of 15em regardless of how many; the last case we asked for columns of 15em, prefereably three of them. At every size, we will fit as many columns as will fit, in the last case up to three, but we will not leave extra space. We increase the size of the columns to fit the container so that it always looks as if they were meant to be that size. And if there's not enough room... then we only have one column.

Flexbox

Flexbox is another layout model that tries to distribute space in a way that is flexible and robust. There are many ways to distribute extra space. You can center or left/right align it. You can distribute it around the items. You can distribute it within the items: in this case each item must have the same outer width, in this case each item has the same amount of extra space around its content.

Initial Letters

At a smaller level, we have initial letters. In the past, a typesetter would have to figure out the correct size and line spacing in order to make the top and bottom of the large letter align with the top and bottom of the letters on the first and third lines of text. But we don't know which font will load, so we don't know this exact relationship. For this reason, we have to use metrics in the font. Using this information, the computer can make the calculations of the correct height and position of the initial letter. We have to also consider what happens when things are not exactly lined up. For example, the design of the capital J in this font has a descender that goes below the alphabetical baseline. In this case, although the drop-cap is a three-line drop cap, we need to make space for the bottom of the J. Overlapping like this is unacceptable. So CSS has rules that say, when it goes below that line, we also clear further below the line. Using a lot of thought and attention to detail like this, we can make initial letters work for many different fonts and many different writing systems.

Automatic Sizing

Another tool we have is what we call “automatic sizes” or “content-based sizes”. This is a famous poster from the 20th century. It was rendered to print, so this is not resizable. But if we study the poster, we can understand the relationships of the different parts of the poster to each other. When we understand these relationships we can express them in CSS, and then the browser can make these relationships be true for the various different sizes. Jen Simmons made this example, where she took those principles and uses CSS Grid Layout to recreate this poster. As you can see, this is a resizable and flexible design; but it preserves the relationships among the different parts of the poster.

So the relationships: we have the content sizes... We can tell that there's an overlap here. The overlap is equivalent to the width of the longer of this phrase and this word. The red box is the same size as this phrase. We can see how this changes as we resize the page: These relationships are constant, but other parts can overlap, wrap, and stretch.

Interoperability

In order for all of this to work, we have to get interoperablity. The specifications, the layout engines, the test suites, and the web content, they all need to agree and have the same interpretation of what CSS is. This is a constant process of giving feedback to each other about what's not working, and we adjust until it stabilizes.

CSS is an open standard. It means that we have multiple implementations. We have to adhere to all these constraints. It takes longer. But, it lasts longer-- because it's not tied to the success of any one company.

This is how we create one Web for the world. HeavenBelowOneWeb