Announcing the second annual Blue Beanie Day. Please join us on Friday, November 28, 2008 to show your support for web standards and accessibility.
Participating’s easy: get your picture taken wearing a blue toque or beanie. On November 28, switch your profile picture in Facebook, Twitter, et al., and post your royal blueness to the Blue Beanie Day 2008 photo group at Flickr. That’s all there is to it!
A proposal for a fonts working group is under discussion at the W3C. The minutes of a small meeting held on Thursday 23 October include a condensed, corrected transcription of a discussion between Sampo Kaasila (Bitstream), Mike Champion (Microsoft), John Daggett (Mozilla), Håkon Wium Lie (Opera), Liam Quin (W3C), Bert Bos (W3C), Alex Mogilevsky (Microsoft), Josh Soref (Nokia), Vladimir Levantovsky (Monotype), Klaas Bals (Inventive Designers), and Richard Ishida (W3C).
The meeting started with a discussion of Microsoft’s EOT (Embedded OpenType) versus raw fonts. Bert Bos, style activity lead and co-creator of CSS, has beautifully summarized the relevant pros and cons discussed.
For those just catching up with the issue of real type on the web, here’s a bone-simple intro:
Microsoft’s EOT (based on the same standard CSS mechanism) works harder to avoid violating your licensing agreement, and has long worked in Internet Explorer, but is not supported in other browsers, is not foolproof vis-a-vis type foundry licensing rules, and may also cause PC security problems.
The proposed fonts working group hopes to navigate the technical and business problems of providing real fonts on the web, and in its first meeting came up with a potential compromise proposal before lunch.
Like everyone these days, the W3C is feeling a financial pinch, which means, if a real fonts working group is formed, its size and scope will necessarily be somewhat limited. That could be a good thing, since small groups work more efficiently than large groups. But a financial constraint on the number of invited experts could make for tough going where some details are concerned—and with typography, as with web technology, the details are everything.
I advise every web designer who cares about typography and web standards—that’s all of you, right?—to read the minutes of this remarkable first gathering, and to keep watching the skies.
Standards promised to keep the web from fragmenting. But as the web standards movement advances in several directions at once, and as communication between those seeking to advance the web grows fractious, are our standards losing their relevance, and their ability to foster an accessible, interoperable web for all?
A List Apart, for people who make websites, is slowly changing course.
For most of its decade of publication, ALA has been the leading journal of standards-based web design. Initially a lonely voice in the desert, we taught CSS layout before browsers correctly supported it, and helped The WaSP persuade browser makers to do the right thing. Once browsers’ standards support was up to snuff, we educated and excited designers and developers about standards-based design, preaching accessibility, teaching semantic markup, and helping you strategize how to sell this new way of designing websites to your clients, coworkers, and boss.
Web standards are in our DNA and will always be a core part of our editorial focus. Standards fans, never fear. We will not abandon our post. But since late 2005, we have consciously begun steering ALA back to its earliest roots as a magazine for all people who make websites—writers, architects, strategists, researchers, and yes, even marketers and clients as well as designers and developers. This means that, along with issues that focus on new methods and subtleties of markup and layout, we will also publish issues that discuss practical and sometimes theoretical aspects of user experience design, from the implications of ubiquitous computing to keeping communities civil.
The trick is to bring our huge group of highly passionate readers along for the ride. My wife likens it to piloting the Queen Mary. (Q. How do you make the Queen Mary turn left? A. Very, very slowly.)
We review hundreds of articles and publish dozens. Some web magazines seem to have those proportions reversed, and some readers don’t seem to mind, and that’s fine. But any content you see in ALA has been vetted and deeply massaged by the toughest editorial team in the business. And when you see a new “design tech” article in our pages, you can be sure it has passed muster with our hard-ass technical editors.
Moreover, the fields of meaningful new CSS tricks have mostly yielded their fuels. We’ve done that. We’ve done it together with you. While a few new lodes of value undoubtedly remain to be tapped, we as a community, and as individuals who wish to grow as designers, need to absorb new knowledge. ALA will continue to be a place where you can do that.
When we began focusing on web standards in 1998, we were told we were wasting readers’ time on impractical crap of little value to working designers and developers. But we kept on anyway, and the things we learned and taught are now mainstream and workaday. While we apologize to readers who are again being made irritable by our insistence on occasionally presenting material that does not fall directly within their comfort zone, we hope that this experiment will prove to be of value in the end.
The new browser is based on Webkit, the advanced-standards-compliant, open source browser engine that powers Apple’s Safari for Mac and PC, but Chrome currently runs only in Windows. You figure that out.
To compete with Microsoft, the new browser must offer what other browsers do not. The risk inherent in that proposition is a return to proprietary browser code. It is not yet clear to me whether Chrome will compete the wrong way—offering Chrome-only features based on Chrome-only code, thus prompting Microsoft to rethink its commitment to standards—or the right way.
Competing by offering features other browsers do not (easier downloads, streamlined user interface) or by consolidating other browsers’ best features (Opera’s Speed Dial, Firefox’s auto-complete) avoids this risk, as improvements—or at any rate, changes—to the browser’s user interface have no bearing on the display of existing web content.
Competing by supporting web standards ahead of the pack, although not entirely without risk, would also be a reasonable and exciting way to compete. When one browser supports a standard, it goads other browser makers into also supporting it. Because Safari, for instance, supports @font-face, Firefox is not far behind in supporting that CSS spec. @font-face raises font licensing problems, but we’ll discuss those another time. The risk that concerns us here is when a browser supports an emerging specification before it is finalized, thus, essentially, freezing the spec before it is ready. But that is the traditional dance between spec authors and browser makers.
For web standards and web content, we once again live in interesting times. Welcome, Chrome!
In Issue No. 256 of A List Apart, for people who make websites, Wilson Miner shares techniques for incorporating data visualization into standards-based web navigation patterns, and Paul Smith shows how to replicate Google Maps’ functionality with open source software to produce high-quality mapping applications tailored to your design goals. Read and enjoy.
For most of the past seven years, the DOCTYPE switch stood designers and developers in good stead as a toggle between standards mode and quirks mode. The switch enabled browsers to accurately support the work of responsible designers who cared about accessibility, findability, and lean, semantic markup. It also enabled those same browsers to support the old-fashioned, table-driven junk markup your grandpappy writes.
But when IE7, with its tremendously improved support for standards, “broke the web,” it revealed the flaw in our beloved toggle. The quest was on to find a more reliable ensurer of forward compatibility. Is version targeting the answer?
In Issue No. 251 of A List Apart, for people who make websites, Aaron Gustafson of The Web Standards Project and ALA describes the workings of and logic behind version targeting, a proposed replacement to the DOCTYPE switch. It’s an idea whose simplicity you may admire immediately; or you may, at least initially, want to run screaming in the opposite direction.
That’s how ALA‘s Eric Meyer felt, when he first previewed Aaron’s report. So did I. But we came around—and in “A Standardista’s Journey,” the companion piece to Aaron’s article, Eric explains how his thinking about version targeting evolved.
Microsoft is on board to support version targeting in IE8; they hope other browser makers will do likewise. The Web Standards Project worked with the Redmond company to forge this new path in forward compatible design. It’s with Microsoft’s consent that we unveil version targeting in this issue. In a future issue, we’ll discuss the implications for scripting.