Tufte CSS | Hacker News Reader

Tufte CSS

daveliepmann.com

461 pointsisp103 comments

I think this:

a) looks like a reasonable simulation of Tufte's print style

b) is missing the point Tufte tries to make

Tufte isn't saying you have to make your presentation look like his, his basic thesis is "don't add unnecessary things that take away from the clarity of your presentation" and he's made a name by critically analyzing other people's presentation and work to show where they've gone overboard and why that detracts from the message they're trying to show.

I've sat in his class, read his books and website and followed him for years. His approach and critical analysis of web sites is actually fairly different from print. He understands that the web is a different medium and should be approached differently. His critiques of ESPN and various weather websites are fascinating not because he complains they aren't using enough whitespace or don't follow his print style, but because he actually likes how they clearly and concisely present summaries of dense, compact information.

I'm afraid this comes off a little like cargo-culting Tufte, going through the ceremony without actually grokking his meaning.

Yes, the first thing I've thought looking at the page on the computer was "I wonder how that looks on my iPhone." I've tried: not easily readable, for me.

Is it not the case that san-serif fonts are better on screen and serif better in print? Seems a bit strange that the webpage uses serif.

I actually like serif fonts on retina screens. The first "reader view" on the iPhone was serif and it was easy to read.

On the linked page the resulting size of the letters on the page is simply too small to allow easy reading. When the area to display text is so small, the designer shouldn't insist on the white margins or the comments on the side. On web page, the comments could be much better done in the "Wikipedia" style (showing on click). The design of the Wikipedia articles on the moment is actually good on iPhone. Much better than this, very natural to read.

Again, this statement just seems like cargo culting when taken as a rule.

The reason san-serifs were better on screen is that screens used to have lower DPI's, and thus can't actually show the serifs as well as on paper.

In the old days of CRT's and 72 dpi screens, the serifs would be distorted because the display can't show details fine enough. In those cases, san-serifs get you around the problem of low dpi screens.

Nowadays, with retina and high dpi displays, serif fonts can look as good as in print.

Just be aware of why these guidelines exist. It's not always a firm "it has to be this way" hard rules.

Seems readable on my HTC One M8s. http://imgur.com/JfRaLRJ

While I recognize that any mimicry of Tufte's print approach in CSS is going to come across as prescriptivism, that was not the point. Tufte CSS was a toy project that seemed worth sharing. It turns out, figuring out which of his methods translate from print to the web is not straightforward. It's an exercise. That process of implementing sidenotes (for instance), and thinking about what they mean in the modern web, is valuable. Sidenotes are but one technique, like data-"ink" ratios and minimal use of hierarchical headings are merely guiding ideas. My goal with Tufte CSS was not to say "this is how websites should look" but rather "here are some techniques we've found useful elsewhere; maybe you'll find them useful on the web" and "here is a sketch of implementing this set of ideas".

While I do think Tufte CSS could be a good starting point for a variety of webpages that want to communicate a point using text, tabular data, figures, and code, I don't think that websites should see Tufte CSS, or Tufte's print projects in general, as a design goal. Different projects, in whatever media, should present their information as best suits their particular circumstances.

Anyway, I apologize for giving the impression of cargo-culting. If there's any way I can change the wording in either the README or the demo doc to better reflect that this is not a design prescription, please let me know.

Cute idea. Needs a better example document to really be judged properly (for example, this document has a far too many large and imposing headings), but in any case, some comments:

Would be better with less leading, a smaller text size, smaller left margin, and more characters per line. This current version has a text block more like a newspaper column width than a book, and the large type and unnecessarily generous leading (especially in block quotations!) make it feel a bit like a children’s book. Not much content fits on screen at any time.

Small caps shouldn’t be used with a typeface/browsers that don’t properly support them and just shrink capital letters instead, they just look spindly and bad. Either find a real small caps font, or skip the idea. Likewise for italics: use a real italic font instead of a browser-generated oblique version of the roman font.

If you want it to look like a nicely typeset book, use an indented first line for new paragraphs rather than a blank line.

Lots of other parts need tweaks, but it would take making several sample documents and then judging how the parts interact.

Final note: 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, and any document that aspires to be as pretty as a Tufte book is going to take many hours of manual composition.

I get why people want their web sites to look as good as Tufte's books, but since they can't, I wish they wouldn't try. Make things that look good in the medium you're working in; don't blindly copy the rules from other media.

Fine advice for experts, surely. Those who recognize they are blind should copy. Copying Tufte seems like a reasonable way to open their eyes and save everyone else's.

I agree that design is medium-specific, but I think the idea of "looking as good as Tufte's books" is an underspecified one. Can a webpage be a better book than a book? No. Can a webpage be a better webpage by borrowing some ideas from books, then modifying those ideas to fit its own purposes? I think yes.

I find that columns with smaller width and larger text are far more readable - any text that is the raison d'être for the page should be readable first, with worries about looking like a "children's book" becoming second concern.

“Critics who treat 'adult' as a term of approval, instead of as a merely descriptive term, cannot be adult themselves. To be concerned about being grown up, to admire the grown up because it is grown up, to blush at the suspicion of being childish; these things are the marks of childhood and adolescence. And in childhood and adolescence they are, in moderation, healthy symptoms. Young things ought to want to grow. But to carry on into middle life or even into early manhood this concern about being adult is a mark of really arrested development. When I was ten, I read fairy tales in secret and would have been ashamed if I had been found doing so. Now that I am fifty I read them openly. When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up.” - C.S. Lewis

> I find that columns with smaller width and larger text are far more readable

The 55-75 CPL seems to stem from research done on readability on paper. 95 CPL seems more apt for the desktop browser when it comes to reading speed. When it comes to overall satisfaction the result is interesting. http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng...

That article is a bit suspect, since it found the max to be more readable. I would like to see what the curve is really like...how do lengths above 95 CPL begin to get harder to read?

I don’t have anything against children’s books; I love children’s books! If the goal is to fit 2 sentences on a page with a big picture and individual letters that are easy to discriminate to help when just learning to read, then large text is a perfectly reasonable part of the design. Large widely spaced text is just not necessarily appropriate for other types of material, where fitting more text on the screen is an important design feature.

This is especially relevant when we’re talking about Edward Tufte: Tufte devotes a huge portion of his books to emphasizing that information presentation is improved when more information is presented in a smaller space, to facilitate references and comparisons between different items/sections. “Information wants to be spatially adjacent so as facilitate comparisons made within the common eyespan of the viewer.”

As a concrete comparison, here’s what fits in my browser view in this “Tufte CSS” document: http://imgur.com/iLNgoaU

Here’s what fits on a page in an Edward Tufte book: http://imgur.com/dTLcDx2

This is where portrait-orientated displays excel: http://i.imgur.com/D9MfvQN.png

This will obviously depend upon what device you're using, but hold a book up in front of you at about the distance you would typically read it (this should be MUCH closer than your screen!). Now compare the size of the text (admittedly, this is tricky because of focus, but it's just about possible) - the font size in the example is pretty much exactly the same as in a typical book, for me at least.

Designers have, for a long time, thought that 'small text is cool/looks better' but there has been a pushback on this by web designers over the past few years. Maybe even HN will one day update its styles for readability; at least a shorter line-length/larger leading would be a great start.

Totally agree. At least with italics, you can use CSS to instruct the browser to not create fake italics using the font-synthesis property: https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthe....

Also, setting the document font size to 11px is a bad idea for a whole lot of accessibility reasons. The current best practice is to leave the global font size at 100%, which in most browsers is 16px by default.

This allows users to scale the type up (or down) as needed, unlike various versions of IE which won’t allow this if the base font-size is set in pixels. This allows the media queries to work correctly, since they always assume 1em = 16px. Resizing the fonts should be done in rems, with pixels as a fallback for non-supporting browsers.

I found this post useful regarding small caps. It seems as though if the typeface contains the glyphs and you're using Chrome or Safari, you can use font-feature-settings: "smcp"

http://usabilitypost.com/2014/05/10/using-small-caps-and-tex...

I agree regarding the example document. It's been troubling, because the fact of the matter is that those headings are legitimate, it's just that there's a mismatch between the goals of the description document and the goals of the kinds of documents that Tufte CSS is best suited for. I agree strongly with your idea of making several sample documents to experiment with. See https://github.com/daveliepmann/tufte-css/issues/26

I'll try to look into your points about leading, text size, and so on, but it would help a lot more if you could open a GH issue for them. As I've noted elsewhere in this thread, a real italic font has been added, and I'm considering what to do about small caps. To me it doesn't look so bad as-is.

I don't want Tufte CSS to look like a nicely typeset book, and it would take a lot to convince me to indent the first line of new paragraphs. I find that repulsive on the web.

Your last paragraph is gold. I wrote something similar about the table style earlier today. For me, I think this project is an exercise in making style choices using a rough template as a guiding star. I too worry that others will focus more on the finger than that star it is pointing at, by slapping this on top of existing content and calling it a day.

Honestly, this is really rough. The impulse is admirable, but the implementation has a lot of rough edges and ugliness. A web author looking for good typography is going to be better served reading Butterick's Practical Typography (http://practicaltypography.com/).

It doesn't have the meticulous shine of Tufte's books, but this is a straightfoward CSS guide. It's a starting point, don't you think?

Butterick's implementation is more than a CSS guide though, right? I thought his design was to show off the power of Pollen[0], his online-book-publishing system.

[0] http://pollenpub.com/

It's a starting point, but a starting point that directs users to fake italic, fake small-caps, mismatched mono text, inconsistent apostrophes, and ugly underlines. (Oh, and sidenotes and other margin content just disappears on a phone.) If you're going to start from a template, it at least shouldn't lead you astray in multiple ways.

It also doesn't maintain your current position in the document if the viewport changes width, which... I'm not even sure how you break that. The user agent usually does a very good job of handling scroll position.

There's a lot of stuff you'd want to clean up before you let Mr Tufte see it.

I'm not sure what browser(s) or site(s) you're referring to, but just now double checking a few sites in current FF and Chrome I don't see them maintaining scroll position at all. I realize that this agrees with my developed expecations for text heavy pages. Text reflow as the page narrows dominates the viewport position -- content getting longer effectively pushes the viewport up the page. To the user, content appears to flow "downward" as the page narrows.

Do you have an example of a site and/or browser that exhibits the behavior you're describing? I'm quite curious if there's an approach to structuring a page that preserves position sensibly.

We've fixed the fake italics, I think I've fixed the mono text (if you're talking about sizing), I've consistentified apostrophes, and changed how underlines are handled. Sidenotes are still a thorny issue (I'd appreciate any suggestions; we're discussing it in the GitHub Issues for the project) and small-caps are still on the to-fix list.

For someone well versed in typography, his monospace font Triplicate is absolutely terrible looking to me. The t's, f's, and a's all look oddly slanted and upset the balance.

Thank you; that's an excellent resource! A couple of other good ones:

http://www.markboulton.co.uk/journal/five-simple-steps-to-be... http://webtypography.net/toc/

I agree that Butterick is a better resource for general web typography. I was aiming less as a prescriptive resource (which Tufte's work definitely is, and which Butterick's is a good example of for the web) but as a way to work out web analogies to some techniques Tufte used.

I'd really appreciate if you could add a GitHub issue or two for the problems you list in your other comment https://news.ycombinator.com/item?id=10012953

Tufte-Latex, mentioned in the article, is a really nice template that produces some gorgeous Latex handouts with very little effort (I've used it a couple times when I wanted something to not look like the standard Latex article class). I thought it worth linking here for those that didn't read the link: https://tufte-latex.github.io/tufte-latex/

I agree -- I use that template for writing most of my documents now.

It's also available to try out online on Overleaf if you don't fancy installing LaTeX: https://www.overleaf.com/latex/templates/handout-design-insp...

(Note: I'm one of the co-founders of Overleaf, so any feedback appreciated, thanks!)

I went to one of Mr. Tufte's workshops several months ago, and I do believe he mentioned Overleaf while discussing LaTeX. I must admit I had forgotten about it until just now, so thanks for the reminder. It looks like a fairly slick interface (and a nice solution for what I recall was a relatively painful problem i.e. installing and using LaTeX).

Thanks -- yes, I believe he's used Overleaf in his workshops for the past couple of years (starting back when we were called writeLaTeX). The Tufte handout and book templates are ones we use again and again when we're asked for examples of such layouts, and they're very popular.

As an interesting tidbit re Overleaf, we recently passed the 3 billion pages compiled mark :) If you stacked up all those pages, you'd have a pile that's (roughly!) the height of Pluto: https://www.overleaf.com/blog/219-youve-created-three-millio...

Resizing the window reduces the user's desired font size: I don't know how many web readability rules this breaks.

If the user then increases the font size, the web page obliges, expanding beyond the window boundary, yet doesn't provide a horizontal scroller! Very bad.

The thing is: Tufte's style isn't designed for webpages. It's designed for books. Books have defined margins, a fixed size, and pages with a defined length. (Good) web pages don't necessarily have any of that. This is where sidenotes fall down, for example: the CSS author has to jump through a variety of hoops, breaking various conventions, in order to make them usable when the user narrows his window width.

It's very nice looking.

Everyone criticizing the implementation, here, let me help you:

https://github.com/daveliepmann/tufte-css

I like the idea but turned away when I saw those ugly fake italic headings. Never italicize fonts that are missing italic type styles.

Sorry! Does this help? https://github.com/pyrocat101/tufte-css/commit/0a810a7d5f470...

No need to say sorry :) It does help, awesome!

For a typography-centric project, it pains me to see that you're not including the proper italic version of the font used in the article, forcing my browser to do ugly guesswork [1].

[1]: http://i.imgur.com/CNBSMVH.png

I feel your pain. I think Linjie Ding's contribution resolved the issue, let me know your thoughts: https://github.com/daveliepmann/tufte-css/pull/8

Personally, I feel like the text is too big.

Medium's site is already on the upper end of what I consider to be a usable font size (22px), and this is even larger (24px). At some point, larger type makes it difficult to quickly scan the page.

For comparison, even Tufte's own site is rendered with a 16px font.

The font appears to scale (in a step function?) related to pixel-width of your window. Try using a narrower window. (This may or may not be related to retina resolution. I didn't read the code to find out.)

The font size _does_ scale, in ways I find quite annoying. Smaller scaling range would likely be better. Or stick to device/user defaults.

Needs sparklines.

https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...

At the moment I think sparklines are outside the scope of this project. However:

https://github.com/daveliepmann/tufte-css/issues/22

I love the margin diagrams, and would happily use this for print based output, but I fear the mobile world would have meant Tufte would redesign his approach to suit the smaller uni-column world, and the best layout on page is very different to that on a four inch screen

Looks quite good on desktop, but even on my Note 3 -- the space used for sidebars take way too much horizontal space.

It will take some work, but with proper collapsing rules for narrow screens, this would be very nice.

One problem might be (as others have indicated) that what works in print doesn't have to be the best solution for digital -- especially where the page size/width (window size) can vary substantially. Personally I typically give my web browser 2/3 of the screen on my laptop, half on my desktop -- unless I'm using it for reference in which case my "work window(s)" -- terminal and/or editor get the 2/3 width slot.

This layout would therefore be useless in code documentation for my use-case -- the window would be ~50% padding, with an anemic main-column that'd be almost unreadable due to fitting only a single word per line.

[ed: At the very least tufte.css and/or latex.css should enable/use CSS3 hyphens in order to get word hyphenation that is a little more like LaTeX, and not completely broken! As is the ragged right is painful in narrow viewports.]

I've always taken a liking to sidenotes, but the main problem with them is they are complicated by Markdown's rendering of footnotes.

It's great for many other purposes, but a lot of people will probably prefer doing things in Markdown.

I use sidenotes very heavily in my book[1], which is written in Markdown[2]. Instead of putting the contents of the asides in the middle of a paragraph, I pull them out into separate <aside> tags. Inside the paragraph, I have a little <span> with a name to indicate which text the <aside> should be positioned to line up with.

There is some CSS to put the asides on the side[3] (with a ton of variations to make it play nice on mobile). Then there's a bit of JS to correctly line them up with <span> markers[4]. It was a bit more effort than I expected, and I don't like having to rely on JS, but the output is really nice, I think.

For example, take a look at this chapter[5], and try resizing your browser window or hitting it on a mobile device.

[1]: http://gameprogrammingpatterns.com/

[2]: https://github.com/munificent/game-programming-patterns/blob...

[3]: https://github.com/munificent/game-programming-patterns/blob...

[4]: https://github.com/munificent/game-programming-patterns/blob...

[5]: http://gameprogrammingpatterns.com/double-buffer.html

I like how your asides move into paragraph flow as the page narrows. The Tufte CSS page hides the sidebar content completely as the page narrows, which eliminates access to crucial information.

(Aside: I really love using the Mobile Design View in Firefox and Chrome for inspecting responsive behavior. You can drag the viewport size by hand, or switch it to presets that represent target devices easily. All while keeping the full width of the browser pane for developer/inspector UI. FF even has a nice toggle shortcut, ⌥⌘M on OS X.)

I’ve seen Tufte CSS before when I tried to search for HTML/CSS sidenote implementations. I’m happy to see a responsive one, even though it uses JS.

Another responsive sidenote implementation, screenshots:

http://imgur.com/a/TXpis

> screenshots

What help. /s

It's not ready for prime time. I thought I'd posted some sample code. I'll dig for it. That was while I was doing anonymous codepens, so they're not on my profile there.

Searching "css sidenote edward morbius" on G+ might turn up something and basic CSS.

Basic sidenotes http://codepen.io/dredmorbius/pen/OVmKZX?editors=110

Not responsive, but @media queries on width and re-scaling width, margin, background colour, and border colour is what gets you that.

Motherfucking Website. No sidenotes. but other bones of my basic design. http://codepen.io/dredmorbius/pen/KpMqqB

Daniel Bos's sidenote implementation: http://loadingdata.nl/waves/

(Degrades nicely for non-CSS viewers, not responsive.)

> I like how your asides move into paragraph flow as the page narrows.

Yup. This is a nice (deliberate) side effect of using separate <aside> blocks instead of jamming them in the middle of the paragraph. The original location of the <aside> tag determines where the sidebar appears in the text flow if there's no room for it on the side. In some cases, it may be a few paragraphs distant from where it shows up on the side if that leads to better reading.

This is also the fallback for users who don't have JS enabled. (Well, all both of them, at this point.)

> I really love using the Mobile Design View in Firefox and Chrome for inspecting responsive behavior.

Oh, yeah. I basically lived in that for a few days when I was tweaking the CSS.

One of the things I love most about Tufte is the way his text introduces every single graphic. He tells you what he's about to show you; then he shows you. This stands in stark contrast in most books where the figures are only very loosely coupled to the text. I didn't realize how jarring I found the convention until Tufte! And it makes perfect sense in hindsight: why did we think it's okay to put figures "within a page or two" of the relevant text?

This handout, by contrast, doesn't do this, and so it throws away something that, to me, is central to Tufte's appeal.

That's a great point. I added some text to the demo document making that point, but I don't have actually relevant graphics or figures to add to it. If you have any suggestions for wording, just email me or open a GitHub issue. Cheers!

I like it as a starting point, a minor sidenote though: What you perceive and describe as bright red links, code and sidenotes is for me, as a color blind, almost indistinguishable from the body text if it wasn't for the underlines and monospaced font. Those off-black and red colors are for me just very similar dark hues on an off-white background. If you want to highlight these elements the current red does a poor job for colorblind people like me.

I'm colorblind as well, and did a little double-take when I read this comment, but I think you misunderstood. "Other forms of text—for instance, links and code—are slightly lighter and sidenote numbers are bright red to distinguish them from inline text." Only the sidenote numbers are bright red.

Yes, I can confirm to you that only the sidenote numbers are colored.

Well done. Though shouldn't the sidenotes use HTML5's <aside></aside>? How does the vertical alignment of sidenote callout and sidenote work?

I agree.

It looks like sidenotes are floated right and given negative right margin. (https://github.com/daveliepmann/tufte-css/blob/master/tufte....)

aside doesn't position relative to text.

There really ought to be a native HTML reference / footnote / sidenote entity with appropriate default styling.

My take, responsive:

http://imgur.com/a/TXpis

(Using floats and negative margins.)

I must have missed something. Since when does HTML have elements called article and section?

HTML5 introduced article, section, footer, nav... and many other semantic elements

See Mark Pilgrim's Dive into HTML5

http://diveintohtml5.info/table-of-contents.html

It actually is quite good semantically.

See also Readability's publisher's guidelines:

https://readability.com/developers/guidelines#publisher

And the hNews microformat:

http://microformats.org/wiki/ hnews

I hope someone follows this up with Doumont CSS.

http://www.treesmapsandtheorems.com/

This would make a great IPython notebook style as well...

To the haters: this looks like something you could hand tweak to get a great result.

They're not haters. This is the type of discussion you should expect when discussing typography. It may seem like endless nit-picking, but it's the sum of nit-picking over all the tiny details that adds up to great typographical design.

I understand this type of thread doesn't really fit HN's "no gratuitous negativity" guideline, but IMO there's really no other way to constructively discuss typography. The whole field is made of attention to excruciatingly tiny details, but taken together, it adds up to great and beautiful design. It's one of the things I love about it.

Maybe note that none of the criticisms are entirely dismissive or unnecessarily harsh, but well-argumented, just about tiny details.

This seems like an okay idea, but does anyone feel that the italics used in the headings (font family: ETBembo) are generated and are quite ugly?

In general, I'm not a fan of the font. It doesn't seem to have very good hinting, so the horizontal strokes are blurry. It's also way bolder on a Mac than on Windows.

The italics are basically the only thing that looks OK here: http://i.imgur.com/H9X3Hpl.png

Linux/Firefox FWIW.

Linux / Firefox has long been the most horrible combo for font rendering - check out Chrome on OSX http://imgur.com/jsHwIk7

Seems fine with Linux / Firefox for me:

Work: http://paste.click/LKBLqt

Home: http://paste.click/zfhnYG

Something is wrong with your Linux/Firefox, because it looks ok for me: http://i.imgur.com/txKbMfF.png

Firefox 39 on Ubuntu 15.04

Indeed, that's a faux italic[1] created by the browser in the absence of a real italic font. Perhaps the author forgot to include Bembo Italic[2] in the @font-face declaration (or simply decided not to pay for it)?

[1] http://alistapart.com/article/say-no-to-faux-bold

[2] https://www.myfonts.com/fonts/mti/bembo/

They are generated. The only web-font being loaded is the Roman style (upright), and the browser is mechanically skewing it to try to replicate the italic. This is really noticeable when it's done to serifed typefaces, because the italic forms are based on a different model of writing and change significantly.

I'm surprised how critical people are on this thread.

Perhaps it touched a nerve because there are quite a lot being done in a relatively small space that makes it look messy.

An option would be to show some features that gel together and list the others in the git markdown page.

For lack of a better word, this implementation is half-assed. If the whole point is typography that's both gorgeous and legible, then you had better dot your i's and cross your t's, and this doesn't. As a very simple example, look at the capital B here in the name of the font:

http://snag.gy/yup65.jpg

There's a chunk missing at the top, and it looks like crap! It should look like this:

https://upload.wikimedia.org/wikipedia/commons/4/49/BemboMT....

Now I understand full well that it's very difficult to make something that looks good on every OS, browser, screen size, resolution, yadda yadda -- but in this case, that's the entire point!

great implementation of tufte's look, though i disagree with much of what tufte believes is great information design.

Could you elaborate? What struck me was the limitation to two levels of section/subsection. Perhaps I'm deluding myself, but I think I prefer my information in clearly layered abstractions, with the presentation following the contours of the abstractions.

Tufte-LaTeX link: " ... the style of Edward R. Tufte and Richard Feynman."

Woah! wait a minute. Style of Richard Feynman? When did Feynman get involved with typography/typesetting work?

I don't know if RPF himself had anything much to do with it, but the typesetting of the /The Feynman Lectures on Physics/ is beautiful.

It features the main column / side column design as discussed, with notes, diagrams and navigation hints in the side column and is a great demonstration of the value of whitespace!

It's referring to the Feynman Lectures on Physics http://www.feynmanlectures.info/, he was presumably involved in the presentation aspects of that (the books I mean, not the site).

I don't know who Edward Tufte is, but this seems to me like a place where we could be living rather well without classes.