The 2015.0 release of Adobe Muse features deep integration with the subscription font service Adobe Typekit. Even as you find typographic inspiration in this library of premium web fonts, it is imperative to keep your designs grounded in the realities of the web medium. This blog post takes a look at one such reality: the lack of consistency across browsers when it comes to text.
We will not focus on browser support for advanced typographic features; The State of Web Type is a great resource for this topic. Instead we will investigate inconsistencies in areas that designers — especially those with a print background — often take for granted: fonts, text rendering, and text layout. We will also outline Muse-specific strategies to avoid or, at the very least, work around these vagaries.
When you choose an entry from the Standard Fonts section of the Muse font drop-down list, you are really specifying a “font stack”: a list of fonts for the browser to try in succession until it finds one installed on the viewer’s computer or device. For example, if you choose “Verdana (Tahoma, Geneva, sans-serif),” the browser will render text in Verdana only if it is installed; otherwise, it will try Tahoma, and so on. The fonts in these predefined lists collectively cover most site visitors and have roughly similar traits (e.g., sans-serif with large x-height). That is a far cry from any reasonable expectation of consistent site visitor experience. For this reason, the 2015.0 release abandoned the term “web-safe” that Muse had previously used for these fonts.
Using web fonts is key to consistency as well as freedom from the monotony of standard fonts. It is no surprise that web fonts are becoming ubiquitous — in May 2015, for the first time, a majority of the sites analyzed by the HTTP Archive used web fonts.
But remember to use web fonts judiciously; too many on a given page can greatly increase load times. Typekit recommends a maximum kit size of 400K. The number of fonts this translates to depends on your choice of fonts as well as the character set. 4–6 fonts (counting each weight and style separately) with the “Default Subset” setting and 2–3 fonts with the “All Characters” setting is a good rule-of-thumb.
How a font ultimately renders on the web is something you, the designer, have little control over. The same text may appear crisp or blurry, smooth or jagged, “thick” or “thin” depending on the viewer’s OS, browser, and screen resolution. However, you do have control over aspects of the design that most impact text rendering:
Font: Not all fonts are created equal; some foundries invest great effort in optimizing their type designs for screen rendering. Perhaps even more important than choosing a quality typeface is using it in the context for which it was designed (e.g., “Display” or “Body text”). To that end, use the “Recommended For” filters in the Add Web Fonts dialog. If the same family supports different use cases (e.g., Minion Pro Display, Minion Pro Subhead, Minion Pro, Minion Pro Caption), pick the one that best suits your needs.
Font size and color: even subtle changes in font size and color can significantly affect text rendering. For example, slightly lower contrast (e.g., dark-gray text on light-gray background) often works better than black on white.
It is worth noting that these tips are just starting points; there is no substitute for experimentation and testing your designs on as many platforms as you can.
Browsers use different font metrics when positioning lines of text. This can lead to inconsistencies that are particularly apparent when another object is manually aligned with a text baseline, as in the following example. The baseline of the heading (set in Helvetica) is perfectly aligned with the blue rectangle in Firefox, but not in Chrome.
The amount of variation in baseline positions is font-dependent. Discrepancies of the magnitude shown above are, fortunately, rare. Most web fonts served by Typekit have their font metrics normalized to behave consistently across browsers.
Each browser has its own implementation of text layout (as does Muse). As a result, for the same text with identical formatting, line or word break positions will often vary from browser to browser (and between browser and Muse Design mode).
For text frames that are intended to fit one line (e.g., headings, labels etc.), you may end up with unwanted breaks as shown below. It is recommended that you make such text frames a bit wider than what’s needed to fit the text in Muse Design mode.
The figures below illustrate line break variations for some body text. The same text fits in eight lines in Muse Design mode, but spills over to the ninth in Firefox.
One practical implication of such variations is that independently-positioned margin notes or images that relate to specific ranges of text may drift from the latter, especially in long, narrow text frames.
The workaround is to paste these items as inline text-wrapped objects and adjust wrap offsets to position them as desired.
The other implication of line break variations is the effect on the height of the text frame. How Muse deals with height changes and what you can do to guide this behavior is a topic worthy of a separate post. Stay tuned!
Meanwhile, we encourage you to give Adobe Muse 2015.0 a try and create inspired designs while carefully avoiding the pitfalls discussed above. We’d love to see what you create!