‘Quand le code rencontre l’interface…’, Strasbourg, France, 25–26 June 2026
The CS department where I (Bert) studied bought a first-generation Macintosh
It came with MacWrite
I saw how it enabled people to create much more interesting documents
But it also seemed to encourage ransom letter typography ☺︎
As a math student, I also learned ChiWriter (WYSIWYG) and TEX (text)
The Macintosh was released in 1984, so this was probably 1985.
For this talk I'l take a slightly different angle:
How much GUIs influenced CSS and in particular CSS Grid
When Håkon Lie proposed Cascading HTML Style Sheets and I proposed Stream-based Style Sheets (both 1994), we weren't the only ones proposing style sheets for HTML, but all proposals assumed a structured documents (either HTML or SGML).
Håkon and I combined our ideas into Cascading Style Sheets, without the ‘HTML’, because my proposal was for a larger subset of SGML, which I called SGML-Lite. (SGML-Lite looked rather like current XML, and indeed was one of the inputs for XML.)
Our combined proposal had a very different syntax from both our initial proposals, but the ideas (cascading, contextual selectors, floats, properties, inheritance, extensibility…) were still there.
We thought the primary way for people to style documents would be by writing CSS by hand, in a text editor, because the contextual selectors made WYSIWYG a bit difficult. But we thought a WYSIWYG interface might still be possible with something like examples and generalization (take one element and style it, then apply this element's style to all ‘similar’ elements, where ‘similar’ could be a combo box with a choice of selectors).
Anecdote: As part of a project for the Faculty of Arts where I worked, I developed a browser called Argo, which, thanks to a system of plugins, gave access to sources that scholars might need, such as FTP sites and the university library. (The browser was running, but not finished when I left the university and joined W3C.)
I called them applets rather than plugins. And when Sun Microsystems read about them, they contacted me to ask me if I was willing to review a project of theirs, which consisted of adding applets to HTML (rather than to a browser, as I did). Their applets had an <applet> tag for HTML and a programming language with the code name Oak.
I did, and I could only say that it was a very nice project and that the programming language looked well-designed and easy to use. A little later Sun published the project, but renaming the language to Java.
(At some point, Java was so popular, that Netscape decided to rename its LiveScript scripting language to JavaScript.)
CSS is involved in three kinds of user interfaces:
Julie Blanc has written about CSS as fundamentally a code-based interface to layout in ‘Designing with Abstractions: CSS and the Case of Masonry Layouts’.
CSS Grid is very much a result of balancing requirements, e.g:
| Documents | Applications |
|---|---|
| Same layout for different document trees (different nesting or order…) | The CSS and HTML are designed together |
| Requires complex selectors | Can just use an ID or class |
| Requires ways to reorder elements | No need to reorder with CSS (can reorder the HTML) |
| Non-rectangular regions (concave, convex, disconnected) | Rectangular only |
Also: Both screen and print (pagination) vs screen only.
Aligning related things helps to see the connection.
We automatically see a connecting line when things align.
Alignments don't need to be horizontal or vertical, diagonal works, too. But our tools, and our screens and sheets of paper, make horizontal and vertical easier.
Back to the history of CSS.
Before CSS, and before the web, there were already ways to layout and print electronic documents. Some of those influenced us (Håkon, me, and other people who contributed to CSS).
It is correct that Håkon and I invented CSS…
… but that doesn't mean CSS came out of the blue
We combined and adapted many existing ideas
CSS wasn't even the only style sheet language proposed for the the web (And we studied those other proposals, too)
Let's look at some influences
RUNOFF (1964), roff (1971), troff & nroff (±1972) are typesetting systems. A roff file consists of text interspersed with typesetting commands (select a font, set a margin, etc.) and macros that expand to typesetting commands. Nroff is notably used to format Unix man pages. Linux comes with the GNU version of troff/nroff, called groff (originally by James Clark).
I've written some software for Unix and thus also some Unix manual pages with nroff.
The sample macros (plain.tex) that come with TEX mostly do not have semantic names. LATEX (Leslie Lamport, 1984) is a collection of macros for TEX that goes much further. Many macro sets share macro names, so you can change the style just by using a different macro set, effectively making the macro set into a style sheet.
This also makes latex2html possible
Anecdote: When I wrote my thesis, I thought I could do better than plain TEX and so I wrote my own macros with semantic names. Except that, when HTML arrived, I couldn't use latex2html, because my macro names weren't the same as LATEX's…
GML (1979) and SGML (1986) by Charles Goldfarb, Edward Mosher and Raymond Lorie
GML (Generalized Markup Language, but also Goldfarb, Mosher and Lorie) was developed at IBM and then standardized as SGML (Standard GML).
HTML (before HTML5) was an application of SGML
Harry Gaylord, a colleague at Groningen University, was a member of the ISO committee for SGML (and HyTime & DSSSL).
So when I learned that HTML was SGML, I already knew how it worked… Unfortunately, the browser makers didn't. The HTML documents I wrote worked perfectly in the SGML tools we had, but they never displayed correctly in any browser.
At the end of the 1980s, some SGML companies had ways to define style sheets or transformations to typesetter formats. E.g., SoftQuad's Author/Editor had a style language, as did EBT's DynaText.
Scribe (1980) by Brian Reid, known as the first system to explicitly separate structure and style.
I never used it or saw any examples, but I encountered Texinfo, which is apparently somewhat based on it, because I use Emacs.
Texinfo (1986) by Richard Stallman is in part derived from Scribe.
GNU software usually comes with manuals written in Texinfo.
They can be viewed as hypertext with Emacs or with the info program, or converted to nroff to make traditional Unix manual pages, or to TEX for printing.
The syntax of configuration files for the X Window System.
They have contextual selectors, properties and values.
My Stream-based Style Sheets proposal used their syntax.
As far as I know, only my proposal and DSSSL Lite (see below) had contextual selectors. All others only had simple selectors, i.e., element names.
ISO standard style sheet language, developed by James Clark starting in or before 1993, standardized in 1996. It does layout in two stages:
(XSL, i.e., XSLT + XSL-FO, is the W3C standard that succeeded DSSSL. It uses XML syntax instead of Scheme and borrows many of the style properties from CSS.
XSL was going to be the advanced style sheet system for the web. It is based on DSSSL and thus consists of two parts: transformations (XSLT) and formatting objects (XSL-FO). Where DSSSL used Scheme syntax, XSL uses XML. The style properties are largely harmonized with CSS.
Even apart from the transformations, XSL can still do things that CSS cannot, such as styling individual characters (not just elements) and inserting ‘leaders’ (rows of dots, like before page numbers in a table of contents). On the other hand, CSS has now overtaken XSL for internationalization (e.g., vertical writing and other non-western typography).
Styling at the character level is sometimes needed, because typographic traditions often require specific styles for certain characters or character sequences that are normally not marked-up as separate elements. (To support those in CSS, Håkon and I invoked ‘magic’, i.e., the implementation should automatically do the necessary.)
XSLT has been in browsers, but will be removed this year. XSL-FO is only used outside the web.
A simplification of DSSSL with some extensions for web-based documents, such as scrolling regions and hyperlinks.
Later renamed DSSSL-Online or DSSSL-O.
P (for ‘Presentation’) was a style sheet language developed at Inria Grenoble and implemented in Grif and Thot, two WYSIWYG editors.
Grif (GRenoble Interactive Formatter) was one of the 1st projects to apply WYSIWYG and Direct Manipulation to structured documents.
Documents were written in S (for ‘Structure’) and could be transformed into other documents with T (for ‘Transformation’).
S was not SGML, but also defined tree-structured documents.
The same team made the Amaya editor (1996–2012) within W3C.
P, like CSS, drew inspiration from TeX 's ‘boxes’ and ‘glue’.
There was a demo by Louis Weitzman (MIT) of automatic layout at the 1995 W3C Workshop on Style Sheets. Constraints on the layout can take into account both the context (screen or page size) and the content.
The demo showed how to make different magazine layouts from the same document and change between them interactively by resizing the window and by drag and drop of objects on the screen. (It was written in Lisp and a bit slow, on the computers of 1995.)
The system used the DeltaBlue constraint solver by Alan Borning and others at the University of Washinton.
Kim Marriott and Peter Moulder (Monash University Melbourne) used constraint solving for all kinds of things, and at some point also for automatic layout.
E.g., in 2005 they showed that constraint solving allowed for much better automatic layout of tables than what browser traditionally did, and without loss of speed.
Protect HTML from becoming bloated and from becoming a formatting language
We wanted to keep the document structure and content separate from the style.
We needed something fast
Browsers had already begun adding elements for colors, alignment, background color, fonts, spacing, blink... We needed something to replace those and that offered even a bit more, so as to convince the browser makers.
Something simple (level 1) that could be extended later (level 2)
Easy to understand and easy to use for as many people as possible
A style sheet necessarily introduces a level of indirection, but apart from that, it should be very readable.
WYSIWYG and Direct Manipulation possible
We tried to keep in mind, when designing the language, that people might want to create interactive WYSIWYG tools to style documents and that such tools would need to write, and ideally also read CSS.
Good typography, but not necessarily complex typography
This was just the first style sheet language. There was surely going to be another one in a few years with all the capabilities needed for laying out magazines, newspapers, posters, and what not. It would build on the experience with CSS one and either complement it or replace it.
(Indeed, in 1998, W3C started work on an advanced style sheet language, XSL. But it never replaced CSS.)
Not limited to HTML.
It should be usable for a large class of structured documents (which at the time meant applications of SGML).
Works on different (including future) devices
A big challenge was that designers on the web had to design without knowing the capabilities (colors, fonts, resolution, dimensions) of the output medium, and also had to take user preferences into account. Hence the important role of percentages and the em unit in CSS. We predicted that CSS would not just be used to display documents on desktop computers, but also on text terminals, organizers with very small screens, TV sets, braille displays, speech synthesizers and printers.
Allows interactivity
Another challenge was how to style interactivity, which traditional style sheet never had to deal with. In the early years, we tried a number of things: behavior of hyperlinks (including folding text, popups and tooltips, such as later added with <details> and <dialog>), multi-state elements (click to cycle through different styles), different scrolling mechanisms (including page flipping and panning), navigating with a TV remote…
One limitation of styling interactivity is that, for security reasons (phishing), the style sheet is neither allowed to pop up a dialog outside the viewport nor to style anything outside the viewport.
About keeping the syntax simple:
I initially didn't want curly braces but just a period (.) at the end, to avoid scaring away non-programmers. But Tim Berners-Lee convinced us that curly braces would be easier if we ever needed to have nested rules in the future.)
About good typography:
It turned out that our approach to reach good typography didn't work.
We thought we couldn't impose particular algorithms, such as those used by TeX, because not all computers were fast enough and browsers needed to format in real time. So we specified only minimal constraints and urged implementers to try and do better. We thought faster computers and competition among implementers would eventually lead to higher quality.
In reality, they didn't compete on quality, they just emulated the market leader, prompted in part by designers who didn't want browsers to be in charge of quality, but wanted to be in control themselves. They only wanted all browsers to render exactly the same, to the pixel.)
CSS level 1 became a W3C Recommendation in 1996.
We (Håkon and I) had several more ideas for CSS.
Many other people had, too.
Several ideas never went beyond the proposal stage.
Let's look at some of them.
Although we didn't aim CSS at complex layouts, we (Håkon, Dave Raggett and myself) thought it was possible to create a richer layout (two-dimensional, rather than a single column with some floats) without making CSS hard to use, by introducing the idea of a layout template with slots (called ‘frames’) for putting parts of a document.
The layout templates were defined with @-rules in the style sheet and each frame had a name. You could then set a ‘flow’ property on an element to put that element in the frame with a given name.
A template basically consisted of boxes containing other boxes, stacked as a column, laid out in a row, or positioned at (x,y) coordinates. Boxes could have borders and backgrounds.
Boxes could be defined to allow resizing by the user (by dragging on the border with the mouse), causing reflow of the content.
The note also defined how templates could be used in paged media to define page layouts, basically by repeating a template on the next page when some slot did not have enough room for all content.
And the note defined how to open links in a frame (like in Netscape's frames, but all in CSS, without requiring new markup).
What we didn't know was that this was far beyond what the browser makers of that time were capable of. We had experience with tree-structured documents, had built browsers, had worked with automatic layout system based on style sheets, transformations and constraint solving, and thus we assumed that browsers were built around a document tree and tree transformations. They weren't. For the browsers of that time, HTML was a stream of text interspersed with formatting instructions: <p> means a blank line, <li> is a bullet, <ul> means indent more, </ul> means indent less, etc.
To do richer layout, Netscape had invented the <frameset> and <frame> elements for HTML and just wanted to use those. Microsoft had countered with <iframe>, and wanted only that. After a lot of negotiation, much of it mediated by Robert Stevahn of HP, they both agreed to do one idea from the Note, viz., absolute positioning. The rest was too difficult.
In 2005 I thought we could try again to define layout grids for CSS. Computers were a lot faster and browsers now had a DOM. So I proposed Template Layout.
It didn't use @-rules to define the templates, but defined templates as the value of a property called ‘grid’. The syntax, I hoped, was more readable than the old @-rules.
It allowed automatic optimal sizing by means of constraints.
And the slots of a grid could be chained, so that, if there is too much content for a slot, the content can continue in the next slot in the chain.
And he has a lot more images on his slides than me, too.
The effort for GUIs built on flexbox, proposed by David Baron (then at Mozilla).
Flexbox ported the layout model of XUL to CSS. XUL was an XML application developed by Mozilla starting in 1997 for building GUIs. (Mozilla abandoned XUL in 2017.)
Tab Atkins (Google) took over as editor of Flexbox and gave it the syntax that we know now.
In 2011, Vincent Hardy and others from Adobe proposed CSS Regions, another way to define templates (a.k.a. regions) with slots into which to flow different parts of a document. Except that these templates were defined partly in CSS and partly in HTML.
You would add a handful, potentially nested, elements without textual content to the document, define their layout with CSS and then use the ‘flow-into’ property on the other elements of the document to make them flow into elements of the templates. The spec left open the possibility to define regions purely in CSS at a later stage, with something like the @-rules from the Frame-based Layout note.
Like in Template Layout, regions can be chained, so that content that overflows one region continues in the next region in the chain. (If the last region in a chain overflows, it gets a scrollbar.)
In 2012, Alan Stearns, also of Adobe, proposed a syntax for defining regions with @-rules in CSS instead of with elements in the HTML document, in CSS Pagination Templates, but only for paged displays, such as print or ebooks.
CSS Regions were discussed and tried (thanks to experimental browser extensions) for a few years, but eventually there wasn't enough interest, and, I think, people were too busy making CSS suitable for GUIs.
Kevin Donnot mentioned earlier today how the experimental implementation of Regions helped him to layout books.
GCPM (2006) defined running() and element() functions, which together allow an element to be removed and then inserted elsewhere.
It is another way of making the layout structure different from the document tree. In this case especially to create multiple copies of some content, such as for running headers and footers.
position: running(foo) is like flow: foo. It takes an element out of its parent's flow and puts it in the slot ‘foo’. It extends the ‘position’ property instead of adding a new ‘flow’ property.
content: element(foo) is a bit like grid: "foo". It creates a slot where an element can be placed. But where ‘grid’ defines both the grid structure and the slots, ‘content’ only defines the slot, because @-rules define the grid, or more precisely in this case: the page grid.
The ‘contents’ value for the ‘display’ property is a (very little) step to making layout less dependent on the document structure, without general transformations as in DSSSL and XSL, or a ‘flow’ poroprty as in Regions and Template Layout.
display: contents moves the children of an element to the element's parent and discards the element itself.
CSS Grid level 1 borrows syntax and ideas from Template Layout and from Flexbox, but is more limited than Template Layout. It does not do automatic optimization of sizes based on constraints, and the ‘grid-area’ property (which replaces ‘flow’) may only be put on the child elements of the element that defines a grid. I.e., grid level 1 is not independent of the document structure. E.g., you cannot use grids to layout a table, because the table cells aren't children of the table.
(You can, if you set display: contents on TBODY, THEAD, TFOOT & TR, which makes all TH and TD into children of the TABLE.)
Also, while Template Layout says that putting two elements in the same slot means they are concatenated, CSS Grid says that putting two elements in the same slot just means they are put in the same position, i.e., on top of one another. (In Template Layout elements are on top of one another only if they are absolutely positioned.)
As a consequence, there is also no way to chain slots together to let content that is too long for one slot continue in another.
CSS Grid level 2 allows, to some extent, placing nested elements instead of children in the grid, by defining sub-grids.
If you define a child of a grid element to be a sub-grid, than a child of that sub-grid can be put in the grid. It it is still limited, because to put an element in the grid, all its ancestors up to the grid must be sub-grids, and you can only put an element inside the area covered by its parent. In Template Layout and Frame-based Layout, you could take an element and put it in the different slot than its parents. For example, you can put a section of a document in a slot of the template and pull out all images from that section and put those in a different slot.
Grid level 3 adds ‘grid lanes’ layout (a.k.a. masonry layout), a kind of automatic layout where each additional element is added to the shortest column (or row) so far.
(A kind of tetris, although all blocks are rectangular.
Around 1998 or so, Håkon and I toyed with the idea of boxes connected by virtual rubber bands.
A traditional float in CSS is placed as high as possible without overlapping other floats but not higher than any preceding element or its parent.
We could generalize that to say that a float must be as close as possible to where it would be if it weren't floating, without overlapping other floats and with zero or more other constraints (not on the preceding page, not higher than a preceding heading, etc.)
Håkon more recently worked on floats in paged media that take some of those ideas. Constraints in this case include such things as: must be at the top of a page, must not be on a preceding page, must be either at the top or at the bottom of a page. The Prince formatter implements this.
Anchor Positioning, by Tab Atkins, tries to provide similar ‘rubber band’ effects, but for absolutely positioned elements rather than floats. You define an element to be an anchor by giving it a name, and then other elements can be positioned above, below, next to or on top of the anchor element. If the anchor element moves, the anchored element moves with it. And you can specify fallback positions in case there is no room on the chosen side of the anchor.
Cette présentation :
https://www.w3.org/Talks/2026/0625-CSS-Strasbourg/
César :
Bert :
Soutenez-nous !Votre soutien fait une énorme différence pour nos activités en tant qu'organisation à but non lucratif d'intérêt public et pour faire fonctionner le Web – pour tous.
Pour en savoir plus, rendez-vous sur : www.w3.org/support-us
We'll talk about the history of CSS, with a special focus on grid-based layouts.
The talk will start with me talking about the history up to a proposal called Template Layout. (Nothing to do with the WordPress templates that Eric Schrijver talked about yesterday ☺︎.)
Then César will talk about Template Layout, which is not (yet?) part of CSS, but is important because it was the first grid layout in CSS that we had a working implementation of and could get designers to play with.
And then I'll talk about what happened after, leading to the current grid modules of CSS and some other, recent proposals to expand the possibilities of alignment in CSS.
So we're going back in time again, almost as far as Clémence Imbert yesterday, when she talked about ease of use of DTP in the 1980s.