Web Browser Font Rendering is the New Edge Case

In the early days of the web, designers and developers relied upon visitors to the sites they were developing to have their chosen font pre-installed on their computers so that their web browser of choice would be able to properly render the selected font. As quickly became obvious, there is a wide variety of fonts installed across all computers worldwide, so this was not an achievable scenario, especially when print level typography was desired. Unfortunately, at that time, the solution was to put all of the text in an image, ensuring the text would display exactly as the designer had specified, but hiding the same text from search engines and blind users.

As Google put more and more effort into influencing web standards and designers and developers had more input into browser feature sets, one of the features that eventually made it into all the major browsers was support for web fonts, or fonts that are hosted somewhere online, and downloaded only when needed to display the text for websites that required it. This means that you can get your multi-language PT Sans font on any website and browser if you are a designer.

Unfortunately for developers that must implement these typographical decisions, not all browsers were created equal when it came to how they render the width of the font. In a situation where you must have text spaced equally across the screen, and you are unable to rely upon letter-spacing to space the letters, you can spend hours trying to have a matching design across Safari, Chrome for Windows, Chrome for OS X, Firefox for Windows, Firefox for OS X, and Internet Explorer’s various supported versions. When you factor in that for new sites, it is also most likely a responsive design that has 4 major breakpoints, it would not be a surprise to have to have 24 different sets of CSS rules to define how the text should be spaced on the screen.

While browsers have come a long way from the days of Internet Explorer 6 versus Firefox, font rendering in the various browsers is still lagging behind when working with web fonts. As an example, just until recently, Chrome 37, the font rendering for Chrome for Windows was attrocious, with the text looking like it was in a much lower resolution setting than the rest of the screen. Browser makers: you have improved so much about developing websites, lets take it the extra distance and make sure font sizes actually mean something across all the major browsers and rendering engines.

Related Posts

Jul 28, 2014
2 minutes

Links Not Working? Check AdBlock Plus

It turns out that the issues with useForcedLinkTracking are not isolated just to Safari’s popup blocker. Unfortunately, one of the most popular browser for both Chrome and Firefox, AdBlock Plus is subject to this issue as well.

One of the things that the AdBlock Plus plugin does is attempt to intercept any and all link traffic to determine whether it was created from an actual mouse click or if it was triggered through JavaScript as part of a marketing campaign. When used on a site with Adobe’s SiteCatalyst analytics with useForcedLinkTracking turned on and target="_blank" set in the hyperlink, you will trigger the issue. If you run into this issue, you can fix it by:

May 12, 2014
2 minutes

Mobile Web Development Is the New Internet Explorer 6

Developing a website that works well across devices and browsers is an excersize in playing Whack-A-Mole. Once you get one browser working on a desktop browser, you go to the next browser and find that not everything works the same way. In 2014, it seems that there aren’t that many differences in functionality between desktop browsers, but that all changes once you start making a responsive website that must handle mobile devices as well as it does desktop browsers.

May 21, 2014
One minute

Window.Open Causes Browser Compatibilty Issues

One of the things that always annoys me as a web developer is when native browser functions that are accesible from JavaScript do not share the same function signature. One perfect example of this is the window.open function. When you are using non-Microsoft browsers such as Firefox and Chrome, you are able to make a call something like this window.open(url, 'window name', 'dimensions or other settings');. The window name parameter is important because it allows you to open multiple links in the same external window/tab. However, when using Internet Explorer, especially Internet Explorer 8 and older, you can only use window.open(url);. If you try to use the first type of function call, you get a very ambiguous error message in the browser that doesn’t tend to show exactly where the error occurred.