YOU FIND ME ENSCONCED in the fabulous Buckhead, Atlanta Intercontinental Hotel, preparing to unleash An Event Apart Atlanta 2011, three days of design, code, and content strategy for people who make websites. Eric Meyer and I co-founded our traveling web conference in December, 2005; in 2006 we chose Atlanta for our second event, and it was the worst show we’ve ever done. We hosted at Turner Field, not realizing that half the audience would be forced to crane their necks around pillars if they wanted to see our speakers or the screen on which slides were projected.
Also not realizing that Turner Field’s promised contractual ability to deliver Wi-Fi was more theoretical than factual: the venue’s A/V guy spent the entire show trying to get an internet connection going. You could watch audience members twitchily check their laptops for email every fourteen seconds, then make the “no internet” face that is not unlike the face addicts make when the crack dealer is late, then check their laptops again.
The food was good, our speakers (including local hero Todd Dominey) had wise lessons to impart, and most attendees had a pretty good time, but Eric and I still shudder to remember everything that went wrong with that gig.
Not to jinx anything, but times have changed. We are now a major three-day event, thanks to a kick-ass staff and the wonderful community that has made this show its home. We thank you from the bottoms of our big grateful hearts.
I will see several hundred of you for the next three days. Those not attending may follow along:
HEY, YOU WITH THE STARS in your eyes. Yes, you, the all too necessary SXSW Interactive attendee. Got questions about the present and future of web design and publishing for me or the illustrious panelists on Jeffrey Zeldman’s Awesome Internet Design Panel at SXSW Interactive 2011? You do? Bravo! Post them on Twitter using hashtag #jzsxsw and we’ll answer the good ones at 5:00 PM in Big Ballroom D of the Austin Convention Center.
Topics include platform wars (native, web, and hybrid, or welcome back to 1999), web fonts, mobile is the new widescreen, how to succeed in the new publishing, responsive design, HTML5, Flash, East Coast West Coast beefs, whatever happened to…?, and many, many more.
Comments are off here so you’ll post your questions on Twitter.
The panel will be live sketched and live recorded for later partial or full broadcast via sxsw.com. In-person attendees, arrive early for best seats. Don’t eat the brown acid.
WHAT A YEAR 2010 has been. It was the year HTML5 and CSS3 broke wide; the year the iPad, iPhone, and Android led designers down the contradictory paths of proprietary application design and standards-based mobile web application design—in both cases focused on user needs, simplicity, and new ways of interacting thanks to small screens and touch-sensitive surfaces.
It was the third year in a row that everyone was talking about content strategy and designers refused to “just comp something up” without first conducting research and developing a user experience strategy.
Even outside the newest, best browsers, things were better than ever. Modernizr and eCSStender brought advanced selectors and @font-face to archaic browsers (not to mention HTML5 and SVG, in the case of Modernizr). Tim Murtaugh and Mike Pick’s HTML5 Reset and Paul Irish’s HTML5 Boilerplate gave us clean starting points for HTML5- and CSS3-powered sites.
Web fonts were everywhere—from the W3C to small personal and large commercial websites—thanks to pioneering syntax constructions by Paul Irish and Richard Fink, fine open-source products like the Font Squirrel @Font-Face Generator,
open-source liberal font licensing like FontSpring’s, and terrific service platforms led by Typekit and including Fontdeck, Webtype, Typotheque, and Kernest.
Print continued its move to networked screens. iPhone found a worthy adversary in Android. Webkit was ubiquitous.
Insights into the new spirit of web design, from a wide variety of extremely smart people, can be seen and heard on The Big Web Show, which Dan Benjamin and I started this year (and which won Video Podcast of the Year in the 2010 .net Awards), on Dan’s other shows on the 5by5 network, on the Workers of the Web podcast by Alan Houser and Eric Anderson, and of course in A List Apart for people who make websites.
Zeldman.com: The Year in Review
A few things I wrote here at zeldman.com this year (some related to web standards and design, some not) may be worth reviewing:
- iPad as the New Flash 17 October 2010
- Masturbatory novelty is not a business strategy.
- Flash, iPad, and Standards 1 February 2010
- Lack of Flash in the iPad (and before that, in the iPhone) is a win for accessible, standards-based design. Not because Flash is bad, but because the increasing popularity of devices that don’t support Flash is going to force recalcitrant web developers to build the semantic HTML layer first.
- An InDesign for HTML and CSS? 5 July 2010
- Stop Chasing Followers 21 April 2010
- The web is not a game of “eyeballs.” Never has been, never will be. Influence matters, numbers don’t.
- Crowdsourcing Dickens 23 March 2010
- Like it says.
- My Love/Hate Affair with Typekit 22 March 2010
- Like it says.
- You Cannot Copyright A Tweet 25 February 2010
- Like it says.
- Free Advice: Show Up Early 5 February 2010
- Love means never having to say you’re sorry, but client services means apologizing every five minutes. Give yourself one less thing to be sorry for. Take some free advice. Show up often, and show up early.
A few things I wrote elsewhere might repay your interest as well:
- The Future of Web Standards 26 September, for .net Magazine
- Cheap, complex devices such as the iPhone and the Droid have come along at precisely the moment when HTML5, CSS3 and web fonts are ready for action; when standards-based web development is no longer relegated to the fringe; and when web designers, no longer content to merely decorate screens, are crafting provocative, multi-platform experiences. Is this the dawn of a new web?
- Style vs. Design written in 1999 and slightly revised in 2005, for Adobe
- When Style is a fetish, sites confuse visitors, hurting users and the companies that paid for the sites. When designers don’t start by asking who will use the site, and what they will use it for, we get meaningless eye candy that gives beauty a bad name.
Happy New Year, all!
For nearly fifteen years, if you wanted to set a paragraph of web text in a serif typeface, the only truly readable option was Georgia. But now, in web type’s infancy, we’re starting to see some valid alternatives for the king of screen serifs. What follows is a list of serif typefaces that have been tuned—and in some cases drawn from scratch—for the screen.
Stephen Coles, December 6, 2010:
Cure for the Common Webfont, Part 2: Alternatives to Georgia
TrueType font embedding has come to iPhone and iPad, Hallelujah, brothers and sisters. That is to say, Mobile Safari now supports CSS embedding of lower-bandwidth, higher-quality, more ubiquitous TrueType fonts. This is huge. Test on your device(s), then read and rejoice:
The Typekit Blog: iOS 4.2 improves support for web fonts
iOS 4.2 is also the first version of Mobile Safari to support native web fonts (in TrueType format) instead of SVG. This is also exciting news, as TrueType fonts are superior to SVG fonts in two very important ways: the files sizes are dramatically smaller (an especially important factor on mobile devices), and the rendering quality is much higher.
Thanks to Matt Wiebe for mentioning the rumour that Mobile Safari on iOS 4.2 supports TrueType fonts and providing a handy link to test.
TrueType is an outline font standard originally developed by Apple Computer in the late 1980s as a competitor to Adobe’s Type 1 fonts used in PostScript. TrueType has become the most common format for fonts on both the Mac OS and Microsoft Windows operating systems.
The primary strength of TrueType was originally that it offered font developers a high degree of control over precisely how their fonts are displayed, right down to particular pixels, at various font sizes. With widely varying rendering technologies in use today, pixel-level control is no longer certain in a TrueType font.
More about webfonts
If you’re coming late to the party, the following bits of required reading and listening will get you up to speed on the joys (and occasional frustrations) of “real type” on the web:
- Bulletproof @font-face syntax, Paul Irish, 4 September, 2009
- Web Fonts at the Crossing, Richard Fink, 8 June 2010, A List Apart
- Big Web Show Episode 1, Dan Benjamin and I discuss webtype with Ethan Dunham of Fontspring and Font Squirrel and Jeffrey Veen of Typekit
- Big Web Show Episode 18, Dan Benjamin and I discuss webtype, screen resolution, and more with Roger Black
My thanks to David Berlow of Font Bureau for waking me from my Thanksgiving stupor and alerting me to this exciting slash overdue development.
The new Kindle has a lot going for it. It’s inexpensive compared to a full-featured tablet computer like the iPad; you can slip it in your back pocket, where it’s more comfortable than an old-style paperback; and it includes a Webkit browser. This last point is where folks like us start to give a hoot, whether we’re fans of epub reading or not.
The flavor of Kindle’s browser concerns us because it affords us the ability to optimize the mobile viewing experience with a single line of markup. You can see this in action in the photo at the head of this article (published and discussed on Flickr).
I made no tweaks for Kindle per se; the Kindle is simply responding to a line of markup I’ve been putting into my web pages since 2007—namely, the viewport meta element, which controls the width of the viewport, thus enabling mobile devices with a limited number of pixels to focus all available pixels on your site’s core content (instead of, for instance, wasting part of the small screen on a background color, image, or gradient). The technique is as simple as web design gets:
meta name="viewport" content="width=770"
(Obviously, the value of “width” should be adjusted to match your site’s layout.)
I learned this little trick from Craig Hockenberry’s Put Your Content in My Pocket (A List Apart, August 28, 2007), which I naturally recommend to any designer who hasn’t seen it.
A List Apart and .net magazine have long admired each other. So when .net editor Dan Oliver did me the great honor of asking if I wished to guest edit an issue, I saluted smartly. The result is now arriving in subscriber post boxes and will soon flood Her Majesty’s newsstands.
In .net magazine Issue No. 206, on sale 17th August in UK (and next month in the US, where it goes by the name “Practical Web Design”), we examine how new standards like CSS3 and HTML5, new devices like iPhone and Droid, and maturing UX disciplines like content strategy are converging to create new opportunities for web designers and the web users we serve:
- Exult as Luke Wroblewski shows how the explosive growth of mobile lets us stop bowing to committees and refocus on features customers need.
- Marvel as Ethan Marcotte explains how fluid grids, flexible images, and CSS3 media queries help us create precise yet context-sensitive layouts that change to fit the device and screen on which they’re viewed.
- Delight as Kristina Halvorson tells how to achieve better design through coherent content wrangling.
- Thrill as Andy Hume shows how to sell wary clients on cutting-edge design methods never before possible.
- Geek out as Tim Van Damme shows how progressive enhancement and CSS3 make for sexy experiences in today’s most capable browsers—and damned fine experiences in those that are less web-standards-savvy.
You can also read my article, which asks the musical question:
Cheap, complex devices such as the iPhone and the Droid have come along at precisely the moment when HTML5, CSS3 and web fonts are ready for action; when standards-based web development is no longer relegated to the fringe; and when web designers, no longer content to merely decorate screens, are crafting provocative, multi-platform experiences. Is this the dawn of a newer, more mature, more ubiquitous web?
Today’s web is about interacting with your users wherever they are, whenever they have a minute to spare. New code and new ideas for a new time are what the new issue of .net magazine captures. There has never been a better time to create websites. Enjoy!
Photo by Daniel Byrne for .net magazine. All rights reserved.
THE long-planned inevitable has now been announced. With open-source-licensed web fonts, web font hosting, and add-a-line-to-your-header ease of configuration, Google has joined Typekit, Font Squirrel, Ascender, Font Bureau and others in forever changing the meaning of the phrase, “typography on the web.”
The Google Font Directory lets you browse all the fonts available via the Google Font API. All fonts in the directory are available for use on your website under an open source license and served by Google servers.
Oh, and Typekit? They’re in on it, and they couldn’t be more pleased.
And so do my iPhone and your iPad. All it took was a bit o’ the old Richard Fink syntax and a quick drive through the Font Squirrel @Font-Face Kit Generator (featuring Base 64 encoding and SVG generation) to bring the joy and wonder of fast, optimized, semi-bulletproof web fonts to Safari, Firefox, Opera, Chrome, iPhone, and Apple’s latest religious device.
Haven’t checked IE7, IE8, IE9, or iPad yet; photos welcome. (Post on Flickr and link here.)
What I learned:
? Even if manufacturer supplies “web font” versions with web license purchase, it’s better to roll your own web font files as long as this doesn’t violate the license.
So I’ve wanted to use a condensed, bold Franklin typeface for my site’s headlines since, well, forever. So I bought Fontspring’s fine Franklin Gothic FS Demi Condensed and licensed it for @font-face use for a mere $2.99, an incomparable value.
It looks great in Safari, Chrome, and Firefox, but not so nice in the latest version of Opera, where it resembles the inside-out test monkey in Cronenberg’s “The Fly.” (Okay, okay, it looks like a ransom note, but the monkey simile was more picturesque.)
And this, my friends, is why Typekit exists. Because even when you find a great font that’s optimized for screen display and can be licensed for CSS @font-face use, guess what? There is almost always some glitch or bug somewhere. And Typekit almost always seems to find and work around these bugs. It’s the kind of grueling task designers hate dealing with, and Typekit’s team loves solving.
If this were a client site, I’d switch to Typekit, or try licensing a different vendor’s Franklin, or (if neither of those options proved satisfactory) dump web fonts altogether and use Helvetica backed by Arial instead. But as this is zeldman.com, I’d rather nudge my friends at Opera to look into the problem and fix it. This will make browsing zeldman.com in Opera a somewhat weird experience, but hopefully it will help all Opera users in the long run.
Implementation Notes and Details
- I haven’t made an SVG version yet, so the web fonts don’t work in iPhone or iPad.
iPhone and iPad see normal weight Helvetica instead of bold Helvetica, because if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font. This is not smart of Firefox.Fixed via technique below.
- In order to match the impact of the previous Helvetica/Arial bold, I boosted the font-size from 25px to 32px. (This also helps smooth the font. Web fonts need more help in this regard than system fonts.)
- Camino ignores @font-face and supports the first system font in the font stack, Helvetica Neue (correctly styled bold).
Update: Problem solved. See Opera Loves My Web Font.
GEORGIA and Verdana, Lucida and (to a lesser extent) Arial and Times New Roman have served us well. For fifteen years, these cross-platform default fonts have been faithful stewards of our desire to read, write, design, and publish web pages. Yet we designers have always wanted more. As far back as 1994, we hoped for the day when we could brand our layouts as magazine and poster designers do, by setting our pages in Franklin or Garamond, our headlines in Futura or Rosewood. And since 1998, CSS2 has provided a standard way to embed any typeface, not just the fab five, on a web page.
In August, 2007, CSS co-creator and Opera Software CTO Håkon Wium Lie wrote CSS At Ten, reminding us that CSS provided a mechanism by which actual font files could be linked to and retrieved from the web. Soon after the article was published, “web fonts” discussions started popping up at interactive design festivals and my friend Jeffrey Veen got the idea for a product that would get web fonts happening without running afoul of inconsistent browser support, multiple format hangups, or type designer licensing agreements and piracy concerns.
Speeding up design acceptance
While browser improvements and web standards alone provided multiple partial solutions, Typekit offered a complete solution that just worked. And the people behind Typekit (including Bryan Mason and Jason Santa Maria) did everything right: they reached out to the type design, graphic design, and standards-based web design communities; they worked with vendor after vendor to offer as many fonts as possible; they spoke everywhere, marketing their venture one lecture and even one designer at a time.
Typekit excited the web design community about type and proved that licensing and hosting web type was a viable business, providing options and convenience for designers and their clients, while bringing new revenue to type designers and protecting their intellectual property.
Typekit is the tipping point
Publicly and truly, I support Typekit because it is getting us to the world of web fonts faster. We could wait indefinitely for type vendors to agree to industry-standard licensing terms and font formats. We could wait far longer for IE, Firefox, Safari, Chrome, Opera, Opera Mini, Mobile Safari, and the rest to support the same font formats. (Currently Firefox supports WOFF and TrueType, Safari and Chrome support TrueType, MobileSafari supports SVG, IE supports EOT, and on, and on.)
But with Typekit, we don’t have to bother our pretty little heads worrying about these inconsistencies, and we don’t have to sit on the sidelines, waiting for all font makers and all browser makers to support a single standard format.
Platforms and performance
Typekit works, and that helps web designers and type designers take “web fonts” seriously. Typekit’s success is even helping to make web designers and type designers more aware of platform problems that can make fonts hideous on various platforms. Georgia was designed for the screen. Garamond was not. Moreover, platforms vary the way they hint fonts (Apple throws out hinting altogether, Microsoft over-hints) and the way they render them (from purely pixellated to at least three varieties of sub-pixel anti-aliasing), making a font’s appearance on a given user’s system hard to predict.
If not for Typekit, we might have had to wait years for most or all type designers to license web fonts. Only then would we have discovered that body text set in anything other than Georgia and Verdana pretty much blows on many Windows OS, browser, and monitor combinations.
Thanks to Typekit, we all know about the problem, and type designers are re-hinting their fonts, and in some cases redesigning them for the screen.
For all this I and all of us can be grateful to Typekit.
They also understand that designers will only use “web fonts” if they have access to the fonts they need. Just as a huge selection enabled iTunes to dominate online music, Typekit’s makers know their service must offer pretty much every good typeface out there—and they are working on it.
Renting versus “owning”
All this said in Typekit’s favor, I have mixed feelings about their product because I’d rather buy a web-licensed font than rent it—and Typekit’s success at establishing the viability of a rental model means that individual type foundries will also rent their fonts—and those who succeed at renting their fonts to web designers may not be inclined to sell.
Of course you never really own the fonts you buy—you simply license their use. So the analogy of owning versus renting doesn’t exactly hold true. But a one-time font purchase as a line item in a design budget is easier to explain and sell to a client than an ongoing rental charge.
Web Standards and @font-face
My other qualm has to do with a preference for pure web standards over product-assisted web standards. I don’t know if my preference is ideological or just the way my mind works (or fails to). But, given my druthers, I’d rather see millions of websites using standard @font-face to link to self-hosted web-licensed fonts than see that same number of fonts using a service—even a brilliant service created by friends for whom I wish continued, deserved, great success. It must be a quirk of mind; there’s no other logical explanation for this preference.
For those who share this bias, possess the properly licensed fonts, and don’t mind using FTP and writing a little code, the CSS @Font-Face Generator by Font Squirrel provides an exceptionally easy way to automatically generate the font formats necessary to take all browsers (including mobile) into account—complete with automated Cufón backup and your choice of best-practice @font-face code strings.
See also FontSpring.
- Web Fonts and Standards (great place to start)
- Nicewebtype: How to Use @Font-Face (a great piece to read next)
- A List Apart: Tim Brown: Real Web Type in Real Web Context
- A List Apart: Jason Santa Maria: On Web Typography
- Web fonts at A List Apart
- Web fonts at zeldman.com
- Paul Irish: Bulletproof Font-face Implementation Syntax
- Kernest.com – CSS-based web font delivery service
- A List Apart: Real Fonts on the Web: I interview David Berlow
- New! Some facts about Web Fonts at Nice Web Type
Is it getting hot in here? Or is it just the flames?
In An Early Look At IE9 for Developers, Dean Hachamovitch, General Manager for Internet Explorer, reports on performance progress, web standards progress (border-radius, bits of CSS3, Acid 3 performance), and “bringing the power of PC hardware and Windows to web developers in the browser” (e.g. improved type rendering via Direct2D, a Windows sub-pixel rendering technology that replaces Cleartype).
The reported web standards improvements are encouraging, and better type rendering in IE is a consummation much to be desired. These positive notes notwithstanding, what is most interesting about the post is the political tightrope Microsoft team leaders are still forced to walk.
The world has moved to web standards, and Microsoft knows it must at least try to catch up. Its brilliant browser engineers have been working hard to do so. This web standards support is not optional: having just been spanked hard in Europe for anticompetitive practices, Microsoft knows it is no longer invincible, and cannot continue to use claims of innovation to stifle the overall market or drag its feet on advanced standards compliance.
At the same time, Microsoft’s marketing department wants the public to believe that IE and Windows are profoundly innovative. Thus efforts to catch up to the typographic legibility and beauty of Mac OS X and Webkit browsers are presented, in Dean Hachamovitch’s blog post, as leading-edge innovations. Don’t get me wrong: these improvements are desirable, and Direct2D may be great. I’m not challenging the quality of the hardware and software improvements; I’m pointing out the enforced bragging, which is mandated from on high, and which flies in the face of the humble stance other high-level divisions in Microsoft would like to enforce in the wake of the company’s European drubbing and the dents Apple and Google have made on its monopoly and invulnerability.
In short, the tone of these announcements has not changed, even though the times have.
Hachamovitch does an admirable job of sticking to the facts and pointing out genuine areas of interest. But he is stuck in a corporate box. A slightly more personal, down-to-earth tone would have come across as the beginnings of transparency—Web 1.1, if not Web 2.0—and a more transparent tone might have slightly reduced the percentage of flamebait in the post’s comments. (It could only have slightly reduced that percentage, because, on the internet, there is no such thing as a calm discussion of improvements to a Microsoft browser, but still.)
Although I disagree with the tone of many of the comments—rudeness to engineers is not admirable, kind, or helpful—I agree with the leading thoughts they express, which are:
- Getting IE fully up to speed on web standards is much more important than introducing any proprietary innovations. (Naturally I agree with this, as it is, in a nutshell, what The Web Standards Project told browser companies back in 1998—and it is still true.)
- Switching to Webkit might be a better use of engineering resources than patching IE.
On the other hand, Microsoft’s refusal to switch to Webkit gives Apple and Google a competitive advantage, and that is good because a web in which one browser has a monopoly stifles standards and innovation alike. By torturing the IE rendering engine every couple of years instead of putting it out of its misery, Microsoft contributes to the withering away of its own monopoly. That might not be good for the shareholders, but it is great for everyone else.