Live data from Hacker News

Tufte CSS

daveliepmann.com

71–80 of 107 posts

Re: Tufte CSS

#71
Would have been nice if they had updated it more for the web. When I make my browser very narrow, for example, the side figure is squished so tiny it is unreadable. Good web sites are reactive and would have moved it below the section at that point instead of keeping it at the side. Seems like they just aped a book style and ended up with something not good for the web.

Re: Tufte CSS

#72
I really like it. Unfortunately, it is not clear what license ETBembo carries, if any. In fact Tufte indicated that ETBembo is not public. So it may not be legal to use it. I think that Dejavu serif is an acceptable (superior?) substitution.

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

Re: Tufte CSS

#73
post #61

Earlier quoted context omitted.

Another responsive sidenote implementation, screenshots: http://imgur.com/a/TXpis

> screenshots What help. /s

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.)

Re: Tufte CSS

#74
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, 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

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. 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. Quite the accidental discovery, but one I find very useful.

https://ello.co/dredmorbius/post/QGKKdiuqUw6O7ROl-V3uJA

Yes, much of the beauty of Tufte's books comes from the totality of how they're architected: ideas, structure, presentation, layout, typography. But incremental steps help.

Embrace and Accept Medium Properties

Paper is fixed size. Online is dynamic. Inks are expensive, colour moreso. Pixels and rgba values are cheap, though too much flash is distracting. Images can offer zoom for detail on hover or click.

Sections. While Tufte uses only chapters and section headings, his books are also divided into Parts. As are Feynman's Lectures as I recall. 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.

Font sizes: show deference to the user's stated preference, if it exists. If not, prefer rem and em units to px or 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.

Font faces. I take exception with much of the font-bigotry noted here. 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.

Colour. Text should be high, though not extreme, contrast. A slightly creamy background is preferable to lighter text. For Web-specific elements, particularly hyperlinks, some affordance indicated by colour is helpful. Also joining related items (e.g., sidenotes and related text).

CSS counters. 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).

Graceful degredation. 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.)

:hover, :active, and other interactive elements. While the design shouldn't rely on these (see above), offering additional hints by way of these mechanisms can be useful.

Contrast. Provide it. ContrastRebellion is a frequently referenced site.

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.

What HTML/CSS Needs*

References. Seriously. Why are we hand-tooling fucking endnotes / sidenotes, still?

Robert Nystrom's Game Programming Patterns sidenotes are interesting, see his comments elsewhere. I'm not fully sold, but these could prove useful.

A client-manipulable comments / discussion aspect 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.

HTML5 is an awfully good start

A grab-bag of some of my own experiments

I've been playing with many of the ideas presented here as well as others.

Sidenotes: http://imgur.com/a/TXpis

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): http://codepen.io/dredmorbius/pen/KpMqqB?editors=110

HREF sidenotes: similar to the reference sidenotes I use, and incorporating elments: ::before and ::after content, counters, and negative-margin offsets. http://codepen.io/dredmorbius/pen/XJGwQv

Ello CSS implmentation of HREF sidenotes: http://i.imgur.com/YA0cCNs.png http://i.imgur.com/QNygLE8.png

Sample site design with table formatting: this adds greenbar and a current-line indicator but otherwise borrows from Tufte's table concepts.

https://www.reddit.com/r/dredmorbius/comments/3832wx/occupat...

Re: Tufte CSS

#75
post #62

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

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

Re: Tufte CSS

#76
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.

Re: Tufte CSS

#77

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 j…

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.

Re: Tufte CSS

#78
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.

Re: Tufte CSS

#79
My feeling is that it looks great compared to most of the stuff I see on the web. It's a good start for a plain minimalistic website. The content needs more work (one "Tufte's" is fine, while the other don't) and all "don't" have incorrect '.

Re: Tufte CSS

#80
Biggest issue for me is that on mobile all the side notes go away (on portrait) and there is no fallback.
Post reply on HN