Using Google Chrome, a Web Designer’s Experience, Part 3: Webkit Annoyances
It’s already annoying enough that Mac browsers render fonts all nice and perfectly smooth while Window’s machines still refuse to automatically implement anti-aliasing on fonts. Aside from making fonts (and the @font-face CSS selector that’s now a reality) look bad on every browser available to Windowleans, it comes with the side effect that Mac browsers will often render type that takes up fewer pixels on the screen itself. This can be an issue when the length of your text matters. For example, say you have a background image for your navigation bar. You want to have part of the navigation bar’s background blue while the rest of the bar is red, but you don’t want to use any image replacement technique for rendering the text itself (you might have a dynamic menu bar running off of your CMS so that when the pages on your site are updated, the navigation bar is as well). If your text renders at different sizes on different Operating Systems, you need to provide different CSS to each OS. Annoying, but doable.
Something about Webkit, however, renders text differently than Firefox does, even on the same OS, so you can end up with spacing differences. Still fixable by targeting particular browsers, but again, how annoying. This isn’t really a fault with Webkit vs. Firefox’s rendering engine, but simply that the browsers end up with differences, and since more people use Firefox than Chrome and Safari (as of the writing of this article, more than twice as many people use FF than use both Chrome and Safari combined), as a Web Designer, developing in a browser that is less common and renders differently than the more popular ones just doesn’t make sense.
The ideal solution would be that all browsers use the same rendering engine, Webkit being a great choice since it’s already used in Chrome, Safari and Apple’s slew of iProducts, but I’m still waiting on the call back from the King of DotCom on that one.