Currently Being ModeratedJun 23, 2012 7:38 AM (in response to oliverj)
This looks to be a WebKit bug rather than a Safari bug – I get the same result with iCab 5.
I found "[u]sing fractional
emvalues that result in less than 1px of letter-spacing are also not honored on Webkit, but work just as well on Firefox" at <http://stackoverflow.com/questions/7811225/is-there-a-way-to-make-css-letter-spa cing-0-5-px> That's from the last post in the thread which also has a link to a test page.
Currently Being ModeratedJun 23, 2012 8:08 AM (in response to oliverj)
Fractional spacings work with both my WebKit and Mozilla browsers but it appears that Mozilla is slightly more accurate for very small quantities. Here is a demonstration with a font size of 5 em but it works as well with px sizes.
My Safari is version 5.0.6 - I assume is should be the same for later versions but here is an image of what I see - the site has scaled the image:
Currently Being ModeratedJun 23, 2012 10:03 AM (in response to K.S.)
So yeah, looks like a 4 year old rounding-error bug in Webkit, which probably explains why the error is amplified at smaller point fonts.
Currently Being ModeratedJun 23, 2012 12:50 PM (in response to oliverj)
Are you sure it is that simple?
This page is food for thought: http://ejohn.org/blog/sub-pixel-problems-in-css
There is no single definition of pixel: http://en.wikipedia.org/wiki/Pixel
My view is that css should never have divided into screen and print but should have defined an infinitely scalable standard like postscript.
Life was simple in the days of my Mac Plus - 1 pixel was the same as 1 point and both were 72 per inch - all screen text was rendered as 1 point dots and many printers did the same thing. As an Electrical Engineer I knew how this corresponded to the electronics. You would think that with separate addressable elements on modern flat screens life would be even simpler - alas no. In the meantime MS confused the situation with scalable screens and their 96 dpi.
I would prefer all calculations to be reasonably high precision with any rounding done at the last moment and preferable by the output device. This would minimise rounding errors and reduce the need for separate print css. I arrived here after hand coding postscript and marveling at its scalable elegance. Before the days of email I used to customise Word 5.1 memos with a quarter pixel line a quarter inch in from the edge. It had 45 degree corners. The next year I used double lines a few pixels apart. These printed well on 300 dpi laser printers.
The sad fact is that the fault lies with CSS standards which give little guidance about resolution and hence browsers do as they please.
Another quirk - early browser scaling functions always scaled points and never pixels - not only did this preserve image sizes but it was easy to protect critical css items from scaling - whilst the modern 'Zoom text only' protects images there is no longer any css control.
In relation to the original post here. I have noticed that all my browsers stop reducing character spacing at the point where the characters touch - ie the characters do not compress or overlap. This depends upon what the characters are and which font is used.
Currently Being ModeratedJun 23, 2012 1:08 PM (in response to Neville Hillyer)
I did actually look at some of the Webkit source and it does look like the data type is mispecified for letter-spacing (ie. it's not a float when multiplying). However, it might be a more difficult fix because simply changing the data type may cause cascading failures (no pun intended).
Anyhow, to answer your question, yes, it's definitely a bug in Webkit and not a technical limitation. Thanks for the all the great feedback though! Great community!