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

Filed under: Design, HTML, HTML5, spec, Standards, State of the Web, Web Design, Web Design History, Web Standards

Comments off.

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

Filed under: 3e, Announcements, Design, DWWS, Franklin, Web Design, Web Standards, webfonts, Websites, Zeldman

Comments off.

Refer to the previous post on Kindle. Two salient points, omitted from the previous discussion and verified this morning, are worth mentioning:

• The Kindle edition of Designing With Web Standards, 2nd Edition, is free of conversion errors, to the best of our knowledge. As an author who hopes to sell copies of his work, I should have pointed that out in my initial post.
• Kindle for iPhone can sometimes create the appearance that a Kindle edition is missing content. Before contacting the publisher to report an error, try switching to the smallest available font size and then re-viewing the page that appeared to be missing some content. Asides, in particular, suffer from this problem, in which text is present but exceeds the viewport, and there is no scrolling mechanism or indication that additional content exists.

ShortURL: zeldman.com/x/59

Filed under: Design, DWWS, editorial, Formats, Kindle, Publications, Publishing, writing

Comments off.

With over 2,000 proposed panels from which a mere 300 will be culled, there’s no shortage of content for next year’s SXSW Interactive Festival in Austin, TX. Panels featuring Happy Cog personnel include the juicy candidates listed below. Follow the links to vote for your favorites. (Voting for a panel increases the likelihood that it may actually get presented.)

Web Fonts: The Time Has Come

After fifteen years of contenting ourselves with system fonts, or image type, the planets are now in line for getting real fonts on the web. Some solutions are already working, and a cross-platform standard is emerging. Here web designer and type designers mix it up on how the font hurdles is finally being leapt. Moderator: Roger Black. Panelists: Font Bureau’s David Berlow, Stephen Coles (new.typographica.org), Bert Bos (CSS), Happy Cog’s Jeffrey Zeldman.

We F*cked Up. Now what? Exploring Failure, Together.

Projects fall apart. We often blame the client, the politics and the personalities. But when it happens, there is a tremendous opportunity to grow as a professional and as a person. Candidly recounting past catastrophes, the panelists explore the emotional experience of project implosion and the silver lining that emerges. Moderator: Happy Cog’s Kevin Hoffman. With Greg Hoy, President of Happy Cog East, Greg Storey, President of Happy Cog West, and Tracey Halvorsen, Principal & Creative Director of FastSpot.

New Publishing and Web Content

What is content strategy? How can publishers harness the energy and talent of the online community? Explore the creative, strategic, and marketing challenges of traditional and new publishing. Moderator: Happy Cog’s Jeffrey Zeldman. Panel: book and new media publisher and entrepreneur Lisa Holton; designer, writer, and W.W. Norton creative director Mandy Brown; novelist, web geek, and Harper’s editor Paul Ford; and writer, editor, and Happy Cog content strategist Erin Kissane.

ExpressionEngine 2.0: Total Domination!

ExpressionEngine is growing in popularity and with the release of 2.0, it’s power has expanded to the stratosphere. Powering great websites such as Change.gov, A List Apart, and Campaign Monitor, it represents an amazing way to build websites and publish content. Join us as 5 experts give best practices from a beginner front-end level up to extension developer supreme. Moderator: Kenny Meyers, Happy Magic Fun Time. Panelists: Happy Cog’s Brian Warren, Happy Cog’s Ryan Irelan, Happy Cog’s Mark Huot and Happy Cog’s Jenn Lukas.

Client Whisperers: Understanding Clients and Selling Web Design

Is there a formula for success? Is there such a thing as a good client? How can you avoid problem clients? Gain insight from the people on the front lines of some of the best known web shops. Learn from their stories the best way to find, manage and love great clients. Moderator: Happy Cog’s Robert Jolly. Carl Smith, President of nGen Works (co-presenter)

Turn Off, Tune Out, Drop Weight

As we become increasingly connected and our lifestyles trend toward the sedentary, our waistlines are growing. Fitness is elusive. Hear from your colleagues about their trials and tribulations around maintaining health while balancing creative work, family, and career development. Moderator: Happy Cog’s Robert Jolly.

Filed under: Design, SXSW

Comments off.

The process by which books are converted to Kindle format introduces errors which do not get corrected. Every publisher knows this, though none will say so on record.

To be clear, there is nothing wrong with Kindle or its format. The problem is one of economics. The cost of a printed book covers some degree of proofing and checking—not enough, but some. The cost of a Kindle book does not support editorial quality control, and the multi-step conversion process, handled in bulk by third parties, chops out content and creates other errors that no one fixes because no one is there to do QA.

I love the idea of Kindle. I love Kindle on my iPhone. As the economics of publishing continues to change, perhaps one day soon, a Kindle edition will contain the same text as the printed book. Until it does, Kindle is great for light reading. But if it’s critical that every word, comma, and code sample come through intact, for now, you’re better off with print.

Update

Two salient points I should have made in this post are covered in Kindling II, posted 27 August 2009.

ShortURL: zeldman.com/x/58

Filed under: Design, downloads, editorial, Formats, Publications, Publishing, writing

Comments off.

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

Filed under: DWWS, Education, Publications, Publishing, Web Design, Web Standards, work, writing, Zeldman

Comments off.

Filed under: glamorous, Zeldman

Comments off.

In Issue No. 290 of A List Apart, for people who make websites…

The Case for Content Strategy—Motown Style

by MARGOT BLOOMSTEIN

Over the past year, the content strategy chatter has been building. Jeffrey MacIntyre gave us its raison d’être. Kristina Halvorson wrote the call to arms. Panels at SXSW, presentations at An Event Apart, and regional meetups continue to build the drum roll. But how do you start humming the content strategy tune to your own team and to your prospective clients? Listen up and heed Aretha Franklin. No, really.

JavaScript MVC

by JONATHAN SNOOK

As JavaScript takes center stage in our web applications, we need to produce ever more modular code. MVC (Model-View-Controller) may hold the key. MVC is a design pattern that breaks an application into three parts: the data (Model), the presentation of that data to the user (View), and the actions taken on any user interaction (Controller). Discover how MVC can make the JavaScript that powers your web applications more reusable and easier to maintain.

Filed under: A List Apart, content, content strategy, javascript, Publications, Publishing, Scripting, Standards

Comments off.

In “New Publishing and Web Content,” a proposed panel for SXSW Interactive, I will lead book and new media publisher and entrepreneur Lisa Holton, designer, writer, and W.W. Norton creative director Mandy Brown, novelist, web geek, and Harper’s editor Paul Ford, and writer, editor, and content strategist Erin Kissane in an honest and freewheeling exploration of the creative, strategic, and marketing challenges of traditional and online publishing—and how content strategy and design can help.

Topics covered will include:

1. What is content strategy?
2. For magazines that are born digital, what opportunities and challenges does the internet offer editors and publishers?
3. For traditional magazines, what opportunities and challenges does the internet offer editors and publishers?
4. How can traditional book publishers harness the energy and talent of the online community?
5. What new forms are made possible by the intersection of traditional publishing and social networking?
6. How can design facilitate reading?
7. How can design encourage readers to become writers and publishers?
8. What is the future of magazines and newspapers?
9. What is the future of books?
10. How can editors and publishers survive and thrive in this new climate?

If this sounds like a panel you’d enjoy seeing, vote for New Publishing and Web Content via the SXSW Interactive Panel picker.

ShortURL: zeldman.com/x/55

Filed under: A List Apart, Appearances, business, Community, conferences, content, Design, events, Ideas, industry, Marketing, Publications, Publishing, Small Business, speaking, Standards, State of the Web, Surviving, SXSW

Comments off.

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:

1. 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.
2. 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

Filed under: Design, Fonts, Web Design, Web Design History, Web Standards, webfonts, webtype

Comments off.