The zoomed-out font-size threshold in WebKit is a mysterious anomaly I’ve long had my suspicions about, but now have finally tested. Take some body copy, start zooming out the page, and observe how copy with smaller font-sizes seem to maintain some legible size, even though they should be much smaller. Try hitting ⌘- too see the effect on this fiddle.

View fiddle - zooming font-size threshold

Here’s how Chrome 16 renders the fiddle with Zoom Out hit twice. Zoomed-out font-sizes 13px-9px are all rendered as the same size. Smaller font-sizes return to proper proportions. Note that this is not Safari’s preference to limit small font-size, as the teeny-tiny font-sizes are still rendered.

Zooming out four times, it appears that the threshold is setting a font-size to 9px. Any text set to 9px font-size or greater will be rendered at least the minimally-legible size of 9px. Anything smaller will be rendered proportionally.

Along with WebKit hardware-accelerated anti-aliasing, CSS 3D transforms can have adverse effects on type rendering when translate X/Y values have subpixel, or decimal values.

View fiddle: Subpixel type rendering. Hover over elements to disable transforms.

In WebKit, the first two elements will have fuzzy type and borders, as rendered elements don’t exactly line up with pixels on the screen.

Just to be thorough, I took a look at 2D subpixel translation transforms (i.e. translateX(0.5px)). In WebKit, the type seems to render appropriately with the subpixel values. However the borders don’t look so good. They get positioned in between pixel spaces, rendering a 1px border with 2 pixels. Firefox doesn’t have any issues with borders.

The fix is to prevent decimal values when using translate and round those values to the nearest integer.

Activating hardware acceleration in WebKit with 3D CSS transforms changes the way WebKit renders text. WebKit composites the element so that when rendering the transform, it doesn’t have to re-render sub-pixel anti-aliasing for every frame. This feature is a good thing in that vastly improves performance of transitions and transforms in WebKit.

But this affects anti-aliasing when there is no actual transform and hardware-acceleration is active on a element. i.e. banal 3D transforms like translate3d( 0, 0, 0) or scale3d( 1, 1, 1 ).

The solution is the same one for IE’s opacity bug: add a matching background to the affected background.

View fiddle: resolving anti-aliasing with hardware acceleration.

Hover over the image below to see the comparison for TUAW.

See also Webkit Hardware acceleration bleeding into subsequent elements, and how to fix it - The Official Posterous Tech Blog.

Re: sans-serif differences, as of version 11.10, Opera now uses Helvetica as the default font for sans-serif for Macs. See changelog for Opera 11.10 beta. I’ve updated the previous post accordingly.

Thanks to Divya Manian for confirming the change and tracking down the changelog and being the awes.

Speaking of Helvetica, the current typography solution on the Boilerplate is to use just sans-serif for the base font-family. See Issue 42 on their reasoning. Windows gets its best sans-serif, Arial. Mac gets its champ, Helvetica. Or so you would think. On the Mac, it’s a bit of a mix.

• Chrome uses Helvetica Neue
• Firefox uses Helvetica
• Safari uses Helvetica
• Opera 11.0 and earlier uses Lucida Grande edited 19 Apr 2011
• Opera 11.10 and later uses Helvetica edited 19 Apr 2011

See sans-serif fiddle

The differences aren’t too drastic, but they’re enough that you should be aware of them. Usually I run into issues when some text is wrapping differently between browsers, and throwing off an elements height. I’m surprised by the difference between WebKit cousins Chrome and Safari. Helvetica Neue line-height is taller, and has tighter kerning.

Personally, my go-to sans-serif font stack is:

font-family: 'Helvetica Neue', Arial, sans-serif;

Kevin at minimali.st details why to use it in Better Helvetica Font Stack. I can’t definitively say it’s a better solution that vanilla sans-serif, but at least I know what to expect.

The Helvetica that ships with Mac OS X Snow Leopard comes with Light and Light Oblique styles. You can take a look by checking out /System/Library/Fonts/Helvetica.dfont

Discovered in the This pull request was closed message on GitHub. I knew about Helvetica Neue’s lighter styles, but this is the first I saw Helvetica Light in action.

For formatting code blocks, white-space: pre-wrap will preserve white spaces and also wrap lines inside the container.

white-space: pre-wrap fiddle

adam j.sontag:

@desandro just found dropshado.ws via @paul_irish …. pretty sure you need an “e” on that “minutia” ;)

Several items of note on this one.

• Mr. Sontag is correct. Minutia is the singular form. Minutiae is plural. I wish to use the plural form in the subtitle.
• After reading several thousand pages worth of the work of Neal Stephenson, I will pounce on any opportunity to use a word which has a derivation with æ.
• The HTML entity for æ is æ.
• Tumblr appropriately parsed the HTML entity from the subtitle field into the markup of the template.
• In the title field for this post, I had to enter Minutiæ. When I first tried Minutiæ the HTML entity was not parsed.
• While æ is a ligature of sorts, it is more appropriately considered a character like other vowels A, E, I, O, U. Wikipedia classifies Æ as a grapheme. I’m sure any typophile can put me in my place about this.