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

Oct 7, 2014
2 minutes

LocalStorage and Safari Weirdness

One of the technologies that has been intriguing to me for a while has been LocalStorage on the web browser. One of my first adventures into using persistent storage other than cookies on a web browser was the short-lived HTML 5 standard of the webSQL database. It turns out that it was simply a SQL Lite database that was accessible via JavaScript in all the WebKit browsers as well as Firefox. However, Internet Explorer did not implement this functionality, and the webSQL standard was soon dropped from the HTML 5 standard itself, leaving only the LocalStorage key/value storage mechanism.

Aug 21, 2014
4 minutes

Google Chrome Makes Web Developers Lazy

This post may make me sound ancient in the world of web development, but here it comes anyway.

Like Microsoft, Google has decided to implement functionality in their dominant browser that is incompatible with the other major competing browsers.

When I first started developing websites professionally, ensuring a website worked for 99% of the site’s visitors was easy, relatively, as you only needed to make sure the site worked in Internet Explorer 6. Obviously, there were a ton of random hacks and tricks required to deal with the quirks of this browser, but you were fairly safe knowing you had developed your site to be tailored to the browser of choice for your visitors. However, the dominance of Internet Explorer 6 was bound to come to an end and it ushered in an era of multiple popular browsers including Firefox and Chrome. With no single browser having a massive advantage in terms of users in all areas, web developers had to make sure that thorough testing of their sites was completed in each of the major 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.