Cross-Device & Cross-Platform

[Slide] 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

[Slide] 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

[Slide] 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

[Slide] 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

[Slide] 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?

[Slide]

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. [Slide]

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

[Slide] 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. [Link] [Link] [Link]

Constraints of CSS

[Slide] 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

[Slide] 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

[Slide Demo] 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

[Slide Demo] 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

[Slide] At a smaller level, we have initial letters. [Slide] 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. [Slide] 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

[Slide] 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.