Tufte CSS provides tools to style web articles using the ideas demonstrated by Edward Tufte's books and handouts. Tufte’s style is known for its simplicity, extensive use of sidenotes, tight integration of graphics with text, and carefully chosen typography.
The project lives at GitHub as tufte-css. The idea is essentially cribbed wholesale from Tufte-LATEX and R Markdown's Tufte Handout format...
The style was posted earlier to Hacker News.
First: I very much admire the spirit and concepts presented here, even where specific aspects strike me as less than ideal. In a world of Web designs which are both grossly overwrought and fragile, this is a compelling antidote.
Specific designs are born of their environment
Tufte's principles are born of their medium, print, and both message and format change as medium does. Understanding the why and wherefore is far more important than the what of design.
Borrow but don't ape
So take the concepts and use those which are applicable. But allow yourself leeway as well. Constraints of pagesize, contrast, and other aspects make some of Tufte's suggestions less advisible for online. I find the grey-field charts translate poorly, for example.
Layout doesn't fix bad writing, but it helps most, and exposes bad
jacobolus noted at HN:
Tufte’s books don’t look good because of the basic style choices, but because of the incredible care and attention he puts into writing and composing them. Crappy content is not going to suddenly become amazing when a different stylesheet is slapped onto it
Good writing can be killed by bad layout and presentation — this is a frequent observation in HN comments on overstyled articles. Middling writing, with good, well-structured layout, becomes easier to read. Bad writing lies naked on the screen when shorn of its shielding raiment. Further, I've found that small changes — drop-cap initials and a bold first line, help in acquiring content particularly when presented in a "cards" view. Even in a world where nobody writes decent microcontent, this helps structure arbitrarily-assembled short content snippets. Quite the accidental discovery, but one I find very useful.
Yes, much of the beauty of Tufte's books comes from the totality of how they're constructed: ideas, structure, presentation, layout, typography. But incremental steps help.
Embrace and Accept Media Properties
Print and online (Web, Mobile, App) have different capabilties. Play up strengths and avoid weaknesses.
Paper is fixed size. Online is dynamic. Inks are expensive, colour moreso. Online, however, pixels and rgba values are cheap, though too much flash is distracting. Images are no longer fixed-size but can offer zoom for detail on user actions.
A key aspect of both print and online is whitespace, or its absence. In print, particularly for books, in which size is largely dictated by human factors (what can be held, carried, and read comfortably, and with canons of page construction, often with broad margins. See especially the Van de Graaf caonon. Those margins then provide additional affordances, including both additional notes and context by the publisher and the reader.
Online, both proportions and total area vary, considerably, even on a single device. The viewport isn't a fixed size but can be varied. Designs which accommodate this flexibly are vastly more useful.
While it's possible to create works with just three levels of heading, I disagree with the advice and styling.
Tufte uses only chapters and section headings, but his books are also divided into Parts. His cited three-level example, Richard Feynman's Lectures on Physics contains "only" chapters and chapter sections ... but:
Is divided into three volumes: "Mainly mechanics, radiation and heat", "Mainly electromagnetism and matter", and "Quantum mechanics".
Each volume has a large number of chapters: 52 to the first, 42 to the second, and 21 to the last, totaling 115. That somewhat exceeds the usual size of short-term working memory, 7+/-2.
The chapters do far better: across the three volumes, they've a minimum of 3 sections, a maximum of 12, and a median of about 6.
It's obvious simply from how the volumes are named that each contains within it unacknowledged subdivisions: at least three in the first, two in the second, and possibly just a single one in the third. This is a case of representation obscuring actual structure.
So the Feynman example actually uses three levels of structure, and represents at least four, contrary to Tufte's representation.
In practice you'll find at least three, and frequently four, levels of hierarchy may need support: Part, Chapter, Subsection, and SubSubSection. Technical writing may have more levels of hierarchy.
Show deference to the user's stated preference, if it exists. If not, prefer rem and em units to
pt. Yes, MSIE back support and broken Android implementations mean you'll need workaround fixes, but you can at least build em/rem units in as your base.
I take exception with much of the font-bigotry noted at HN, though the specific choices of Tufte.css are fairly mediocre. I honestly Just Don't Fucking Care most of the time, though I find online font choices are occasionally spectacularly poor. Generally I prefer a decent, widely available, and good enough font for online presentation. Excessive fucking with dynamic Web fonts leads to many pages which fail to render text at all on older devices.
And if the default style makes a poor font choice, that's the most trivial of problems to fix.
Arguably as well: sans-serif fonts should be used for smaller devices (clearer presentation), serif for larger ones (clearer differentiation and hinting).
Text should be high, though not extreme, contrast. A slightly creamy background is preferable to lightening text. For Web-specific elements, particularly hyperlinks, some affordance indicated by colour is helpful. Also joining related items (e.g., sidenotes and related text) by highlighting both when one or the other is in focus.
A challenge with any UI/UX enhancement is that various clients don't support all features. Degrading gracefully, and providing maximum possible content and structure, really helps.
My own sidenote experiments fail somewhat in this regard. Without CSS parsing, they simply become inline, undifferentiated, text.
This also tends to automatically address most accessibility concerns.
Provide it. ContrastRebellion is frequently referenced and much loved by me.
Accomodate Variable Viewports
Responsive design is pretty much a necessity these days, and it's easier than you think.
In the case of Tufte.css, some principles, such as ample whitespace, make sense in the context of print where sizes are rigidly defined. For online content, sidebars, sadly, fail to remain viable as viewport widths shrink. My solution was to transition sidenotes to what are effectively callouts, with a gradually increasing background shading to identify these, as viewport size decreases.
Or rather, in a mobile-first design, you build callouts which become marginal sidenotes as space increases.
These take the manual tracking out of identifying content and references. Sections, headings, references (side / end notes), figures, tables, images, etc., can all be automatcially numbered. This is useful (though not universally supported). Tufte.css should make use of these.
CSS pseudo-selector elements
:active, and other interactive elements can be quite useful for online interactive content. While the design shouldn't rely on these (see above), offering additional hints by way of these mechanisms can be useful.
What HTML/CSS Needs
References. Seriously. Why are we hand-tooling fucking endnotes / sidenotes, still? And for a sytem which was designed for academic and technical papers?
Robert Nystrom's Game Programming Patterns
‹aside› sidenotes are interesting, see his HN comments. I'm not fully sold, but these could prove useful.
A client-manipulable comments / discussion structure is another element that I'm finding myself increasingly wanting, something that is structured by way of data (author, date, references, subject), but whose ultimate presentation (flat, nested, collapsed, semi-threaded, etc.) is ultimately under client control.
General page and content annotation. If you revisit Vannevar Bush's 1945 vision of the Memex, "As We May Think", a core functionality is the ability to comment on the text being viewed. This has been proposed and even implemented several times in online contexts, but largely been shot down through copyright and "author's integrity" concerns. A huge pity.
HTML5 is an awfully good start
Mark Pilgrim's Dive Into HTML5 is the guide you want to read if you haven't already. Extending that concept further are microformats, which allow for content to be semantically marked up: author, date, title, and more. Readability has an excellent publishers' guide, based on the hNews 0.1 draft microformat specification.
I'm given to railing on Web design, but under the hood there's some really good structural work going on. If you look at Pilgrim's online book itself, there is virtually no structure to it other than raw HTML5. The rest is supplied, beautifully, via CSS alone.
Good document templates are a useful thing
One of the best things about LaTeX is that the basic document structure is well-enough defined that you simply write what you want to say, then pick the presentation format (document style) in which to present it. In theory HTML + CSS offers this capability, but in practice, variations in fundamental page structure make this difficult to achieve in practice. Much of that variability is almost wholly unnecessary. Landing on a small set of fundamental page structures would help in this. It's a goal several projects seem to be fighting toward, most notably "Reader Mode" solutions — freestanding services such as Readability, Pocket, and Instapaper, and increasingly, browser-integrated support. Which makes one wonder what the stock stylying is suppossed to be: anti-reader mode?
It often seems it is.
A grab-bag of some of my own experiments
I've been playing with many of the ideas presented here as well as others.
Edward Morbius's Motherfucking Website — this is the bones of my own preferred site layout, though it lacks the responsive elements and much of the polish (which I'm still working on): Codepen
HREF sidenotes: similar to the reference sidenotes I use, and incorporating elments: ::before and ::after content, counters, and negative-margin offsets. Codepen
Ello CSS implmentation of HREF sidenotes:
Sample site design with table formatting at the dreddit. This adds greenbar and a current-line indicator but otherwise borrows from Tufte's table concepts.
And yes, I'm working toward a style (and corresponding document structure) which incorporates many of these thoughts. Not ready for prime time, as I'm learning while doing.... A goal is to minimise the amount of preprocessing required, and allow authoring in a minmimised language (e.g., Markdown), though those goals involve compromises.
This is also why I strongly favour sites which rely on Markdown or similar languages for authoring. Even if, as here on Ello, the present state of styling isn't all I'd like, I can create structured documents, and my own CSS modifications make that structure apparent.
On G+ I've neither option, and the result is frequently simply a mess.
Among the tools and examples listed in the HN discussion:
@ellowebdesign #css #webdesign