It means “desk” or “work table” in french : how metaphoric for a blog discussing what my work's about. Get the RSS feed.


I'm Thibaut Sailly, an independant interface designer based in Paris. Say hello on twitter or by email at bonjour ✉ tsailly ◦ net.



© 2010-2014 Thibaut Sailly · Powered by Movable Type · RSS


Wow Adobe is really cool

John Nack linked to a video on his blog today about Adobe's work on CSS (thanks to @jasperhauser for the link). It demonstrates complex and dynamic text wrapping on a mobile touch screen, and pretends to "enhance Webkit for better typography".

The example is so technically remarkable, the result so miserable in a design sense, and the communication strings so entangled it's comical.

Technically, shaping a text block organically in CSS today is a time sink, and it's not dynamic at all. It has to be custom made, and the markup has to be adjusted too much to reach the intended result. Consequently, having a CSS rule establishing some shape relations between two blocks and letting the browser deal with the rendering issues will allow more creativity in layout design. Congratulations to the Adobe team for building this and hopefully contributing their brain power to Webkit.

However, you can't decently use this with the current state of browser justification rendering if you're serious about typography and graphic design. The example on the video shows a text crippled with holes and rivers. The resulting text very uncomfortable to read, as much as this video was to watch (by the way, it's called a tripod, you fix the camera to it and then the image stops shaking). Enhancing typography? How about some work on justification rendering first? Less impressive than text flowing around a giraffe, but it would actually "make the web a better place", and make this demo more convincing to practicing web designers who care about legibility.

As for the communication part, there is a name which, because it is omitted with so much efforts, can only be noticed: Apple. They are working with Google to enhance Webkit, not Google and Apple, the originator of Webkit. Their demo about text flow would have been much more convincing, and would have made more sense really, on a tablet sized device like the... iPad. And the use of a giraffe must refer to the Pages for iPad demo - or is it a common reference in layout design, like the teapot in 3D modeling?
This mix of untold and omitted but obvious references to Apple shows a lack of voice control surprising for a corporation like they are.

Adobe is trying real hard to be on the picture hand in hand with every single cool kid around these days: tablet publishing, "HTML5", web typography, and now Webkit. It looks more like desperate tries to solve a branding problem rather than a genuine effort to solve users problems: a sad waste of talents.

Update: I've left a comment on John Nack's blog post

Honey, I shrunk the pixels

This is a question that has probably been debated at length by the great people building web standards and browsers, and it's very possible the real scope of the problem lays beyond my understanding. But, as a person building websites and observing technology evolve, I really have some trouble with this: will it make any sense to use pixels as a unit in a not so distant future?
Here are some facts and thoughts around this question. Be advised this is pretty nerdy and it won't change anything in your daily proceeds as a web designer – if you happen to be one anyway.

Two problems

One: the physical dimensions of a pixel remained nearly the same for some years (early 2000s), mainly because screen technology didn't evolve that much in this period of time. But pixel density has risen up recently and unevenly: we now have a wide variety of pixel physical sizes. Declaring that a font has a size of 16 pixels is therefore like saying a wall is 16 bricks high: this wall will have as much different heights as there are different kind of bricks. It's kind of dumb.

Two: if technology continues to improve at the same rate, physical pixels are going to disappear from our visible world in about a decade or so. What sense does it make to use a unit you can't physically refer to anymore ? Add 10 to your current age and picture yourself at this lovely age, training a kid to CSS. How are you going to explain pixels to him – if he doesn't understand it – without going "well, back in the days…"?

It was meaningful and eye straining.

Using pixels as a unit for type makes a lot of sense when computer screens have a density of 72ppi. At this scale, 10 pixels have the exact same physical dimension as 10 points, a unit used in the print industry for a long time (there are 72 points in one inch). The printing industry was used to points and it made the transition to screen based work much easier. It seems this is part of the reason why Apple chose this resolution when they introduced the Macintosh: "wysiwyg". Also, you couldn't really produce CRT screens with a much better definition at the time, so it came handy.

There was one expense to this choice though: the glyphs were not as well drawn and as defined as a comfortable read would want them to be. Windows chose to set the software resolution of their screens at 96dpi in order to improve readability: letters were a bit better drawn, and the perceived size of text was closer to what you get from books.

Under these physical conditions, using pixels as a unit for the web when it came around made sense because it made things easier. You could use the same unit to size the layout, set the type, and size images. I guess that if IE6 had gotten a decent webpage zooming engine, we wouldn't have had to use ems at all in CSS and could have stuck with pixels to achieve decent results, but I might be wrong here.

Readability improvements

However, these conditions do not provide for a comfortable read, and R&D went on to mass produce screens with a higher density in order to address that. The side effect of this comfort increase is that it breaks the units correlation described above: a physical pixels no longer has the same dimensions as a point. Meanwhile, the mobile industry boost is introducing new device types along with many new screen sizes. Combine the two and you get lots of different screen dimensions to work with, when expressed in pixels.

Legibility on the other hand is very constant driven. And the main constant here is the size of your retina, or more precisely your fovea. The physiology of the human eye dictates the size of what's legible and what's not. Physiology – and our cultural habits – define legibility: we know that at arms length, labour text sized at 11 points (depending on the font) provides a optimized reading experience. Years of practice have lead to this result; not a point below, not a point above, it is this precise size that works. If we care about legibility and user comfort in our projects, we should be able to precisely and consistently size text in terms of physical rendering dimensions. But we are using a none constant unit to size elements requiring a constant behavior.

Pixel pot

side by side comparison of 4 different screens

I did some basic tests with some text set at Verdana 16px and 16pt on a 2px/2px checkerboard background. You can try them for yourself (view source to get the differences) if you want (if you can make screenshots on Android and send them to me, that would be greatly appreciated). To my surprise (or not), the point size doesn't quite match the pixel size. To your discontent, I did not inquire for the reasons behind this fact, sorry. But I will.

side by side comparison of 4 different screens

The screenshots of the MacBookPro, iPhone 3GS, the iPad and the iPod 4G reduced at 50% show a very consistent rendering of the font and background, in terms of pixel count. The background on the iPad and on the iPod 4G show some fuzzy aberrations, but very light. Given the pixel density difference between the MBP and the iPhone 3GS though, there is a very big difference of font size measured in a proper distance unit. The uppercase L is 12 pixels high or 2,3mm on the MBP, and 1,87mm on the 3GS. On a 24" iMac it would be 3.22mm. So if you want a 16px MBP verdana on a 3GS, set it at 18px. And for the iMac, set it at 14px (if you can). Glancing at this situation, one would be tempted to just go {font-size: whatever;} and don't look any further.

How about we leave the pixels where they belong?

If pixels are going to get smaller and smaller, and if the devices are recomputing text / layout sizes for an appropriate display anyway (through the viewport meta tag), couldn't we consider our screens as paper and use the point unit as in print work? We could set the font size at 10 points, the browser's rendering engine would grab the device's ppi and compute the necessary number of pixels needed to display the text at this physical size on the screen. Wether we have last year's Samsung, this year's iPhone or next year's LG, the text would have exactly the same size to the eyes of the reader and that's what counts most.

In the same vein, maybe we should detect screen sizes in inches or mm, rather than in pixels. The screen size of a device dictate how we interact with it. You hold a smartphone a little closer than arm's length, a tablet more like a book, a laptop 1/3 further and a 24 inches display a little further again. Grouping devices by families of physical screen sizes would allow us to create families of reading context (and distance) in a more effective way than having to take into consideration the screen resolution and density. And we wouldn't have to worry about LG's next popular screen settings and update our css for it. Each new device would fit into the palm, tablet, laptop or desktop family you would have cared about initially, which is already enough work in itself.

These are just suggestions from someone who's been tinkering with the idea for a few weeks, so as said above, I surely miss the whole picture and all the constraints involved in rendering a font at a specific size on all screens in ten years from now. Watch this entry for updates here if you feel concerned by this question. Any knowledgeable input is welcomed via @thibautsailly and will be transcribed here.

@dpkendal says : "CSS’s px doesn't mean exact ‘pixels’—the actual number of screen pixels shown is relative to resolution. http://cl.ly/2l4S." @AlanHogan pointed out the same fact.
From the working draft I should have read before posting the article: "However, if the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length." In these conditions, you would have to take in consideration every possible screen resolution and create a style sheet for each one, if you wanted your text to appear at a precise physical dimension. Also, the expression "typical computer display" is a problem in a field where everything moves so fast; what's typical today wasn't 5 years ago and won't be in another 5 years.