Categories
better-know-a-speaker creativity CSS Design Fonts industry Press Real type on the web Standards State of the Web Web Design Web Design History Web Standards Web Type Day webfonts webtype

Web Type: Lupton on Zeldman

Designing With Web Standards

Today in Print, Ellen Lupton interviews Jeffrey Zeldman (that’s me) on web typography, web standards, and more. Part one of a two-part interview.

Ellen Lupton is curator of contemporary design at Cooper-Hewitt, National Design Museum in New York City and director of the Graphic Design MFA program at Maryland Institute College of Art (MICA) in Baltimore. She is the author of numerous books and articles on design, a frequent lecturer, and an AIGA Gold Medalist.

This has been a nutritious part of Web Type Day.

Short URL: zeldman.com/?p=2932

Categories
Fonts Formats Web Standards webfonts webtype

House Party

REAL FONTS on the web: House Industries supports WOFF format.

…a font format for the Web that satisfies the needs and concerns of browser makers, web designers, and type foundries. … WOFF offers compression to speed page load times, freedom from thorny legacy issues, and inclusiveness (font outlines can be Postscript or TrueType).

WOFF has the support of a wide spectrum of the type community; from peers such as Emigre, Hoefler & Frere-Jones, Commercial Type, etc., and larger foundries such as Linotype and Monotype. Today it has also gained the support of Mozilla in the their release of Firefox 3.6 (Mozilla has a full list of designers and foundries that support WOFF on that page). We hope and expect that WOFF will quickly gain support in other major browsers as we support, endorse and expect to license our library for use on the Web in the WOFF format in the future.

Read more

  • The Problem: We have the fonts, we have the CSS and the workaround for IE. What we don’t have is beautiful, reliable, consistent cross-platform rendering of real fonts like Gotham, Franklin, Garamond, etc. — 29 October 2009
  • Web Fonts and Standards: How real fonts work on the web via standard CSS. Making it work in IE. The licensing hurdle. Rise of the middlemen and their effect on the adoption of font embedding standards. — 17 August
  • Web Fonts Now, for Real: David Berlow of The Font Bureau publishes a proposal for a permissions table enabling real fonts to be used on the web without binding or other DRM. — 16 July 2009
  • Web Fonts Now (How We’re Doing With That): Commercial foundries that allow @font-face embedding; browser support; CufĂłn and SIFR, oh, my; Adobe, web fonts, and EOT; Typekit debuts; — 23 May 2009
Categories
Blue Beanie Day Community Web Standards

Toque o’ the Morning

Download Blue Beanie Day toque for your avatar. Illustration by Kevin Cornell.

Monday, November 30th, 2009 marks the third annual International Blue Beanie Day in Support of Web Standards. Don a blue toque to show your support for web standards, grab a photo of yourself sporting said headgear, and upload it to the Blue Beanie Day 2009 photo pool on Flickr. Got an illustrated Twitter/Flickr avatar? Give it a blue beanie designed by Kevin Cornell. Download the zipped Photoshop file here.

Short URL: zeldman.com/?p=2774

Categories
3e books CSS Design development DOM DWWS HTML5 javascript Publications Real type on the web Standards State of the Web Typography Usability User Experience Web Design Web Standards webfonts XHTML Zeldman

Am I Blue

Zeldman

Our classic orange avatar has turned blue to celebrate the release of Designing With Web Standards 3rd Edition by Jeffrey Zeldman with Ethan Marcotte. This substantial revision to the foundational web standards text will be in bookstores across the U.S. on October 19, 2009, with international stores to follow. Save 37% off the list price when you buy it from Amazon.com.

Short URL: zeldman.com/?p=2730

Categories
Browsers Fonts spec Standards State of the Web Usability User Experience Web Standards webfonts

Real type, real drag

You must read High Performance Web Sites Blog’s (yes, that’s really it’s name) @font-face and performance if you’re using @font-face to embed web-licensed fonts on sites you design (as I’ve done here).

Categories
Browsers Standards State of the Web Web Standards

What's my IP address and how modern is my browser?

DeepBlueSky’s FindMeByIP instantly reveals your IP details and uses Modernizr to determine your browsers’ support for the latest CSS and HTML5 features.

Categories
An Event Apart Appearances business Chicago cities Design HTML speaking Standards Usability User Experience UX Web Design Web Standards Zeldman

Chicago Sells Out

An Event Apart Chicago, two days of design, code, and content.

An Event Apart Chicago has sold out. If you wanted to join us in Chicago on October 12–13 for two days of design, code, and content, we’re sorry to announce that the show has completely sold out. There’s not a spare seat to be had.

That means, if you don’t already have a ticket, you won’t be able to watch Jason Santa Maria, Kristina Halvorson, Dan Brown, Whitney Hess, Andy Clarke, Aaron Gustafson, Simon Willison, Luke Wroblewski, Dan Rubin, Dan Cederholm, and your hosts Eric Meyer and Jeffrey Zeldman share the latest ideas in design, development, usability, and content strategy.

We’re sorry about that.

But, hey. If you can’t be with us in Chicago next week, please join us in San Francisco later this year. Or come see us in 2010 at any of these fine cities:

Tickets for all our 2010 shows go on sale November 2nd, 2009, and are first-come, first served.

To keep up with the latest AEA doings, become a fan on Facebook, join our Ning social network, or subscribe to our mailing list.

Short URL: zeldman.com/?p=2651

Categories
editorial Education HTML HTML5 Web Design History Web Standards

HTML5 Redefines Footer

It seems like only yesterday that the HTML5 Super Friends asked the HTML5 working groups to rethink footer’s content model to avoid web developer misuse and frustration. Okay, it wasn’t yesterday, it was Monday. Close enough. Today comes word that footer is indeed being redefined as we requested. This is a wonderful usability improvement to HTML5, and we salute the working group(s) for listening and acting.

Categories
editorial Education HTML HTML5 Web Design History Web Standards

HTML5 For Smarties

The HTML5 specification runs on for over 900 pages, and much of what it covers, while vital to browser makers, is meaningless to people who create websites. If thousands of irrelevant details in the HTML5 spec have you crossing your eyes and crying for Mama, Michael™ Smith’s HTML 5: The Markup Language is just what the HTML5 doctor ordered: lean, clean, and content-author-focused. Until there’s a plain-language HTML5 Pocket Guide, Smith’s edited presentation of the spec will do. (It’s also available in a single page format.)

ShortURL: zeldman.com/?p=2561

Categories
Design HTML HTML5 spec Standards State of the Web Web Design Web Design History Web Standards

Loving HTML5

Half of standards making is minutia; the other half is politics. Rightly or wrongly, I’ve long suspected that Atom was born, not of necessity, but because of conflicts between the XML crowd and the founders of RSS. Likewise, rightly or wrongly, I reckoned HTML5 was at least partly Hixie’s revenge against XHTML served as text/html.

And then a funny thing happened. Some friends and I gathered at Happy Cog’s New York studio to hash out the pros and cons of HTML5 from the perspective of semantic-markup-oriented web designers (as opposed to the equally valid perspectives of browser engineers and web application developers—the two perspectives that have primarily driven the creation of HTML 5).

Our first task was to come to a shared understanding of the spec. During the two days and nights we spent poring over new and changed semantic elements, we discovered that many things we had previously considered serious problems were fixable issues related to language.

Easy language problems

Some of these language problems are trivial indeed. For instance, on both the WHATWG and W3C sites, the specification is sometimes called “HTML 5” (with a space) and sometimes called “HTML5” (with no space). A standard should have a standard name. (Informed of this problem, Hixie has removed the space everywhere in the WHATWG version of the spec.)

Likewise, as an end-user, I found it confusing to be told that there is an “HTML5 serialization of HTML 5,” let alone an “XHTML 5 version of HTML5.” I requested that the two serializations be referred to as “HTML” and “XHTML”—emphasizing the distinction between the two kinds of syntax rather than drawing needless attention to version numbers. (Again, Hixie promptly updated the spec.)

Names and expectations

Some language problems are tougher—but still eminently fixable, because they are language problems that mar the presentation of good ideas, not bad ideas that require rethinking.

For example, in order to choose suitable names for the new semantic elements in HTML 5, Hixie analyzed classnames on thousands of websites to see what web designers and developers were already doing. If many designers and developers use classnames like “header” and “footer” to contain certain kinds of content, then HTML 5 should use these labels, too, Hixie and his colleagues reasoned. Doing so would make the purpose of the new elements intuitively obvious to working web professionals, removing the learning curve and encouraging proper element use from the get-go.

It’s a beautiful theory that comes straight out of Bert Bos’s W3C Design Principles. There’s just one problem. Header, and especially footer, behave differently from what their names will lead web designers and developers to expect. Developers will use it for the footer of the page—not for the footer of each section. And they will be frustrated that the footer in HTML5 forbids navigation links. After all, the footer at the bottom of web pages almost always includes navigation links.

To avoid misuse and frustration, the content model of footer should change to match that of header, so that it may be used concurrently as a template level element (the expected use) and a sub-division of section (the new use). Alternately, the element’s name should be changed (to almost anything but “footer”). Expanding the content model is clearly the better choice.

For the love of markup

HTML5 is unusual in many ways. Chiefly, it is the first HTML created in the time of web applications. It is also the first to be initiated outside the W3C (although it now develops there in parallel).

Not surprisingly in a specification that goes on for 900 pages, there are at least a dozen places in HTML5 where a thoughtful standardista might request clarification, suggest a change, or both. My friends and I have taken a stab at this ourselves, and will soon publish our short list of recommendations and requests for clarification.

Nevertheless, the more I study the direction HTML5 is taking, the better I like it. In the words of the HTML5 Super Friends, “Its introduction of a limited set of additional semantic elements, its instructions on how to handle failure, and its integration of application development tools hold the promise of richer and more consistent user experiences, faster prototyping, and increased human and machine semantics.”

Update

[4:47 PM EST] Calling all cars! The HTML5 Super Friends declaration of support is now live, as is the Super Friends Guide to HTML5 Hiccups (i.e. our technical recommendations).

ShortURL: zeldman.com/?p=2438

Categories
3e Announcements Design DWWS Franklin Web Design Web Standards webfonts Websites Zeldman

DWWS 3e mini-site updates

Designing With Web Standards, 3rd Edition

The new mini-site for the 3rd Edition of Designing With Web Standards has been updated, with additional information about the substantially revised web standards guidebook, and with tweaks to the CSS which, one hopes, now bring embedded web font goodness to Internet Explorer users, as well as our friends on Safari, Firefox, and Opera. We love the smell of Franklin in the morning.

Short URL: zeldman.com/x/60

Categories
DWWS Education Publications Publishing Web Design Web Standards work writing Zeldman

What’s new in DWWS 3e

Designing With Web Standards, 3rd Edition

The 3rd Edition of Designing With Web Standards is coming soon to a bookstore near you. Abetted mightily by our secret cabal of interns, co-author Ethan Marcotte, technical editor Aaron Gustafson, copyeditor Rose Weisburd, editor Erin Kissane and I have worked hard to create what we hope is not merely an update, but a significant revision to the foundational web standards text.

Packed with new ideas

After years of stasis, the world of standards-based design is exploding with new ideas and possibilities. Designing With Web Standards 3rd Edition captures this moment, makes sense of it, and keeps you smartly ahead of the pack.

From HTML 5 to web fonts, CSS3 to WCAG2, the latest technologies, claims and counter-claims get broken down in classic DWWS style into their easy-to-understand component ideas, helping you pick the course of action that works best for your projects. As always, the core ideas of standards-based design (which never change) get presented with clear insights and up-to-date examples. You’ll find strategies for persuading even the most stubborn boss or client to support accessibility or reconsider what “IE6 support” means—and for handling the other problems we face when trying to bring rational design and development to the unruly web.

Now with more “how”

While this 3rd Edition, like its predecessors, spends a great deal of time on “why,” it also features a lot more “how” than past editions. If you loved the ideas in DWWS, but wished the book was a bit more hands-on, this is the edition you’ve waited for.

Oh, and the color this time? It’s blue, like l’amour.

Pre-order and save

A few chapters remain to be written, but the goal is in sight, and the book will be out this Fall. To celebrate, you can now save 37% when you pre-order Designing With Web Standards 3rd Edition from Amazon.com.

There’s a new book mini-site as well, with more content and features to come. The sharp-eyed will notice that the mini-site is set in Franklin Gothic. A web-licensed version of ITC Franklin Pro Medium from Font Bureau has been embedded via standard CSS. It works everywhere, even in IE. (View Source if curious.)

ShortURL: zeldman.com/x/57

Categories
Design Fonts Web Design Web Design History Web Standards webfonts webtype

Web fonts and standards

AS FAR back as 1998, CSS2 provided a way to link to real fonts from your style sheet:


  @font-face {
  font-family: "Watusi";
  src: url("http://www.example.com/fonts/watusi.ttf")
  format("truetype");
	}

  h1 {
  font-family: "Watusi", sans-serif;
	}


Instead of static pictures of fonts, linked font files can be retrieved from the web and used to display HTML text. And not just for headlines, but for body copy, too. It’s brilliant! It’s magnificent! There are just two problems:

  • Unless they are specifically licensed for web use (and few fonts are), if you embed fonts you own on a web page, you may be violating your End User Licensing Agreement (EULA) with the font foundry.
  • While Safari (and other Webkit browsers, including Google Chrome), Opera, and Firefox support @font-face for TrueType (TTF) and OpenType (OTF) fonts, guess which browser does not? That’s right, Internet Explorer. That’s not because IE is technically inferior to the other browsers. Rather, it’s because Microsoft does not wish to provide technology that might infringe on the rights of type designers. Instead, Microsoft supports @font-face only for the Embedded OpenType (EOT) format—which Microsoft itself invented. EOT discourages the copying of copyrighted font files via encryption, “subsetting” (using only needed characters rather than the entire font), and other techniques. Microsoft has supported EOT—and proposed it as a W3C standard—since IE4 was young. No other browser maker supports EOT.

The Tan method and IE

It’s the perennial web standards problem, but until Microsoft joins the party, Jon Tan offers a commendable workaround, combining standard @font-face with EOT served via IE conditional comments. It’s a hack, perhaps, but a clean one—and one that even Microsoft would approve. Nice work, Jon Tan. That’s one hurdle cleared.

The licensing hurdle

Type foundries are on the verge of agreeing to standards that will protect their rights and enable designers to embed real fonts on their web pages via standard CSS. They are on the verge, but not there yet. Competing proposals include Erik van Blokland and Tal Leming’s .webfont, a compressed format containing XML and font data; Ascender’s EOT Lite, which removes the chief objections to Microsoft’s EOT while still working in IE; and David Berlow’s OpenType Permissions and Recommendations Table, a mechanism for showing that the designer has paid for the right to use a particular font on a particular domain.

Using @font-face in all browsers today

Some of these methods work already. For instance, on Font Bureau’s website, you will soon be able to buy a web- and print-licensed version of one of their fonts for 20% more than a print-only-licensed version, and embed it on a given domain via @font-face. It will be legally licensed, and it will work in Safari, Firefox, and Opera. It will even work in IE, if you use Jon Tan’s workaround.

Rise of the middlemen

Until type designers agree to a standard and all browsers support @font-face embedding of TrueType and OpenType fonts, “middleman” platforms such as Typekit and Typotheque will make real web fonts possible by handling licensing and technological hassles.

As nearly all of you reading this know, here’s how it works: First, companies like Typekit get font vendors to sign on. The companies agree to license their fonts through Typekit. Designers pay a monthly fee to Typekit for arranging the license and hosting the fonts. Typekit also provides a technology solution, ensuring that the fonts show up in browsers that support standard font formats via @font-face (Safari, Firefox, Opera) as well as the one that does not (Internet Explorer).

Worth noting is that Typekit is font foundry agnostic, welcoming all, whereas Typotheque is a foundry-specific solution. The wizards at Clearleft have their own middleman platform in the works. All these solutions are currently in beta.

As of this writing, their pricing models are unknown—and price is sure to have an impact on acceptance.

Moreover, by definition, no web font middleman (or font developer, like Typotheque) offers every font you could wish for, and ultimately, designers will only choose a service that provides fonts they wish to use. Nor is it yet known whose technical solution will be best, whose font file will load fastest, how reliable each hosting platform will be as usage scales up, and so on.

The effect of font services on web standards

It remains to be seen whether a font-licensing standard and universal browser support for @font-face will kill the middlemen, or whether the middlemen will prove so successful that they delay or stifle the adoption of a font-licensing standard and allow Microsoft to shrug its shoulders indefinitely at supporting @font-face for anything beyond its proprietary EOT file format.

There is also the possibility that the middlemen, by increasing acceptance of web fonts, will hasten the arrival of a licensing standard—and that this will, in turn, prompt Microsoft to support @font-face for any licensed font.

ShortURL: zeldman.com/x/54

Categories
conferences microformats Web Design Web Standards

Styles Council

I just spent an intensely magical two days discussing web standards with Nicole Sullivan, Dan Cederholm, Jeremy Keith, Eric Meyer, Wendy Chisholm, Tantek Çelik, and Ethan Marcotte in Happy Cog’s New York studio. (Photos.) We laughed, we cried, we thin-sliced the changing semantics of the b element.

To keep the wonderfulness flowing, I’ll spend today attending Tantek’s New York City microformats workshop.

Categories
Advocacy Applications architecture Browsers Code Compatibility creativity CSS Design DOM Markup spec Standards State of the Web W3C Web Design Web Design History Web Standards wisdom

Why Standards Fail

Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”

Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.

Design is for people

In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:

Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….

But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….

For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.

Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.

For instance, in the page entitled “Use What Is There,” Bert says:

The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….

And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …

And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.

He then warns:

There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.

Shrinkage and seduction

In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and HĂĄkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and HĂĄkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)

This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.

What were once vices are now habits

You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.

Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.

If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.

The future of the future of standards

It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).

And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.

To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.

I urge everyone to read “What is a Good Standard?“, and I thank my friend Tantek for pointing it out to me.

[tags]W3C, design, principles, bertbos, maintainability, accessibility, extensibility, learnability, simplicity, specs, standards, css, markup, code, languages, web, webdesign, webstandards, webdevelopment, essays[/tags]