Djangocon: typography and the web, the state of the art - Idan Gazit¶

Tags: djangocon, django

(One of the summaries of a talk at the 2014 djangocon.eu.)

Idan Gazit is someone I really like to hear at django conferences. I’ll simply point at two earlier talks. Design for developers (2010) and compass and less (2011).

There’s a nice book “thinking fast and slow”. A general principle is that anything you can to to reduce cognitive strain is worthwhile. One of them is making your text readable. This is mentioned explicitly.

The printing press was invented 600 years ago and we did a lot of writing beforehand, so we have a lot of experience.

There are two kinds of factors:

• Micro. Typeface, kerning.

• Macro: measure (“width”), leading (“spacing”), flow of type on a page.

There’s a lot of common wisdom for books. How to lay it out, the ideal size of margins. But on the web we have a huge problem: we do not have control. There’s no fixed page size, we have many screen sizes and screen resolutions and screen quality. But still… there’s a lot that we can learn from the existing body of knowledge.

• Type size. 16 pixels is the default size in browsers. In books it is often smaller. But it is 16 for a reason: the screen is further away than books, so it needs to be larger. Simple physics: something further away looks smaller.

• Try working with proportional sizes. Humans love proportions. Often you’ll use an “em”: 1 em is the width of an uppercase letter “M”. If you later change your font, the proportions are still right.

  Watch out: those measurements multiply. If something is 2em inside a div with 3em, it’ll be 2x3=6em.

  Solution: “rem”, “root em”. They work in all the browsers (IE9+, otherwise you can use a polyfill). A root em always is relative to the topmost type size.

• Type faces. Watch out with the regular font-face: helvetica, arial, sans-serif; type of font stack. For every individual character, the browser tries to find the best font. So if a character isn’t found in your top font, your string might be composed of several different fonts.

  You can hack around a bit with the unicode-range attribute of font-face. This way you can use a specific font for a specific range (like using a specific font just for Hebrew characters).

• Watch out for faux-bold and faux-italic. Those are fonts that are hacked by the browser to make them bold or italic when there’s no real bold or italic version.

• A problem can be the “flash of unstyled content”. Before the browser has the font, it often displays it in another font and re-draw the page afterwards.

  Some browsers don’t like this redraw and don’t display anything until the font has been loaded.

  Others wait for max 3 seconds and then display the unstyled content anyway.

  Cache your fonts aggressively. Don’t make your browser load the font twice.**

• CSS3 has nice new font loading behaviour. Work in progress.

• Fonts are vector-based and are rendered as a raster by the OS. And there are quite some different ways you can do it. OSX’s renderer is beautiful, but on windows the fonts often don’t look as good. So what looks good on your mac might not look good on windows. So check it.

There is quite a lot of nice stuff that’s slowly coming our way:

• Slowly there’s support for ligature.

• There are different kinds of numerals. Oldstyle? Proportional? Fixed width? CSS’s font-feature-settings allow you to set this.

• Many of these new things degrade gracefully, so they’re safe to use. You can always look at http://caniuse.com/ to see if you can use a specific feature for a certain browser.