“It’s been a great year for web design books; the best we can remember for a while, in fact!” So begins Goburo’s review of the Top Web Books of 2010. The list is extremely selective, containing only four books. But what books! They are: Andy Clarke’s Hardboiled Web Design (Five Simple Steps); Jeremy Keith’s HTML5 For Web Designers (A Book Apart); Dan Cederholm’s CSS3 For Web Designers (A Book Apart); and Eric Meyer’s Smashing CSS (Wiley and Sons).

I’m thrilled to have had a hand in three of the books, and to be a friend and business partner to the author of the fourth. It may also be worth noting that three of the four books were published by scrappy, indie startup publishing houses.

Congratulations, all. And to you, good reading (and holiday nerd gifting).

Attention, web design geeks, contest fans, standards freaks, HTML5ophiles, CSSistas, grammarians, bookworms, UXers, designers, developers, and budding Haikuists. Can you do this?

Do not tell me I
Am source of your browser woes.
Template validates.


Write a web standards haiku (like that one), and post it on Twitter with the hashtag #bbd4 between now and November 30th—which happens to be the fourth international Blue Beanie Day in support of Web Standards.

Winning haikus will receive free books from Peachpit/New Riders (“Voices That Matter”) and A Book Apart.

Ethan Marcotte, co-author of Designing With Web Standards 3rd Edition and I will determine the winners.

Enter as many haikus as you like. Sorry, only one winning entry per person. Now get out there and haiku your heart out!

See you on Blue Beanie Day.

P.S. An ePub version of Designing With Web Standards 3rd Edition is coming soon to a virtual bookstore near you. Watch this space.

Morning finds me bound by train for Boston, capital of Massachusetts, land of Puritans, patriots, and host of the original Tea Party. Center of high technology and higher education. Where the John Hancock Tower signs its name in the clouds, and the sky-scraping Prudential Tower adds a whole new meaning to the term, “high finance.” Beantown. Cradle of liberty, Athens of America, the walking city, and five-time host to An Event Apart, which may be America’s leading web design conference. (You see what I did there?)

Over 500 advanced web design professionals will join co-host Eric Meyer and me in Boston’s beautiful Back Bay for two jam-packed days of learning and inspiration with Dan Cederholm, Andy Clarke, Kristina Halvorson, Jeremy Keith, Ethan Marcotte, Jared Spool, Nicole Sullivan, Jeff Veen, Aarron Walter, and Luke Wroblewski.

If you can’t attend the sold-out show, which begins Monday, May 24, you can follow the live Tweetage via the souped-up, socially-enriched, aesthetically tricked out new version of A Feed Apart, whose lights go on this Sunday, May 23. Our thanks to developers Nick Sergeant, Pete Karl II, and their expanded creative team including Steve Losh and Ali M. Ali. We and they will have more to say about the project soon. For now, you can always read our 2009 interview with Nick and Pete or sneak a peek on Dribbble.

There’s also a Flickr photo group and an interstitial playlist, so you can ogle and hum along from your favorite cubicle or armchair.

See you around The Hub or right here on the world wide internets.

In Issue No. 302 of A List Apart for people who make websites, Joe Clark explains what E-book designers can learn from 10 years of standards-based web design, and Daniel Mall tells designers what they can do besides bicker over formats.

Web Standards for E-books

by Joe Clark

E-books aren’t going to replace books. E-books are books, merely with a different form. More and more often, that form is ePub, a format powered by standard XHTML. As such, ePub can benefit from our nearly ten years’ experience building standards-compliant websites. That’s great news for publishers and standards-aware web designers. Great news for readers, too. Our favorite genius, Joe Clark, explains the simple why and how.

Flash and Standards: The Cold War of the Web

by Daniel Mall

You’ve probably heard that Apple recently released the iPad. The absence of Flash Player on the device seems to have awakened the HTML5 vs. Flash debate. Apparently, it’s the final nail in the coffin for Flash. Either that, or the HTML5 community is overhyping its still nascent markup language update. The arguments run wide, strong, and legitimate on both sides. Yet both sides might also be wrong. Designer/developer Dan Mall is equally adept at web standards and Flash; what matters, he says, isn’t technology, but people.

Illustration by Kevin Cornell for A List Apart.

You’ll always draw ire for having stumbled into being the Chief of the cargo-cult side of Web Standards, with so-called ‘XHTML’ as the false idol. You did a lot of good, but not without ambiguating the nomenclature with a lot of feel-good bullshit.

You often find yourself as a mediator between designery folks (who you have a strong grasp over) and technical implementors (who will always hold a grudge against you for muddying the discourse). Asking people to wear blue toques does not particularly affect this balance.

“Cargo cult.” I love that phrase. But I’m not sure I agree with your assessment.

XHTML, with its clearer and stricter rules, came out just as many of us were rediscovering semantic markup and learning of its rich value in promoting content. It wasn’t a coincidence that we took this W3C specification seriously and helped promote it to our readers, colleagues, etc. The stricter, clearer rules of XHTML 1.0 helped enforce a new mindset among web designers and developers, who had previously viewed HTML as an “anything goes” medium (because browsers treated it that way, still do, and quite probably always will; indeed HTML5 codifies this, and that’s not necessarily a bad thing).

Future versions of XHTML became a dead-end not because there was no value in strict, semantic, structural markup, but because the people charged with moving XHTML forward lost touch with reality and with developers. This is why HTML5 was born.

That’s history and it’s human behavior. But those subsequent twists and turns in the story don’t mean that standardistas who supported XHTML 1.0 (or still do) and who used it as a teaching tool when explaining semantic markup to their colleagues were wrong or misguided to do so.

That some technical people in the standards community think we were wrong is known, but their belief does not make it so.

That a handful of those technical people express their belief loudly, rudely, and with belligerent and unconcealed schadenfreude does not make their point of view true or persuasive to the rest of us. It just makes them look like the close-minded, socially maladroit, too-early-toilet-trained, tiny-all-male-world-inhabiting pinheads they are.

Short URL: zeldman.com/?p=3108

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.

• What’s new in the 3rd Edition
• Mini-site

Short URL: zeldman.com/?p=2730

A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes:”

1. It’s a mess, Lawson says, because the process is a mess. The process is a mess, he claims, because “[s]pecifying HTML 5 is probably the most open process the W3C has ever had,” and when you throw open the windows and doors to let in the fresh air of community opinion, you also invite sub-groups with different agendas to create competing variant specs. Lawson lists and links to the various groups and their concerns.
2. It’s a “spec mess,” Lawson continues, citing complaints by Allsopp and Matt Wilcox that many elements suffer from imprecise or ambiguous specification or from seemingly needless restrictions. (Methinks ambiguities can be resolved, and needless restrictions lifted, if the Working Group is open to honest, accurate community feedback. Lawson tells how to contact the Working Group to express your concerns.)
3. Most importantly, Lawson explains, HTML 5 is a backward compatibility mess because it builds on HTML 4:

[I]f you were building a mark-up language from scratch you would include elements like footer, header and nav (actually, HTML 2 had a menu element for navigation that was deprecated in 4.01).

You probably wouldn’t have loads of computer science oriented elements like kbd,var, samp in preference to the structural elements that people “fake” with classes. Things like tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.

But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. …

There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.

Damned if you do

The third point is Lawson’s key insight, for it illuminates the dilemma faced by HTML 5 or any other honest effort to move markup forward. Neither semantic purity nor fault-tolerance will do, and neither approach can hope to satisfy all of today’s developers.

A markup based on what we now know, and can now do thanks to CSS’s power to disconnect source order from viewing experience, will be semantic and accessible, but it will not be backward compatible. That was precisely the problem with XHTML 2, and it’s why most people who build websites for a living, if they knew enough to pay attention to XHTML 2, soon changed the channel.

XHTML 2 was conceived as an effort to start over and get it right. And this doomed it, because right-wing Nativists will speak Esperanto before developers adopt a markup language that breaks all existing websites. It didn’t take a Mark Pilgrim to see that XHTML 2 was a dead-end that would eventually terminate XHTML activity (although Mr Pilgrim was the first developer I know to raise this point, and he certainly looks prescient in hindsight).

It was in reaction to XHTML 2′s otherworldliness that the HTML 5 activity began, and if XHTML suffered from detachment from reality, HTML 5 is too real. It accepts sloppiness many of us have learned to do without (thereby indirectly and inadvertently encouraging those who don’t develop with standards and accessibility in mind not to learn about these things). It is a hodgepodge of semantics and tag soup, of good and bad markup practices. It embraces ideas that logically cancel each other out. It does this in the name of realism, and it is as admirable and logical for so doing as XHTML 2 was admirable and logical in its purity.

Neither ethereal purity nor benign tolerance seems right, so what’s a spec developer to do? They’re damned either way—which almost suggests that the web will be built with XHTML 1.0 and HTML 4.01 forever. Most importantly for our purposes, what are we to do?

Forward, compatibly

As the conversation about HTML 5 and XHTML has played out this week, I’ve felt like Regan in The Exorcist, my head snapping around in 360 degree arcs as one great comment cancels out another.

In a private Basecamp discussion a friend said,

Maybe I’m just confused by all the competing viewpoints, but the twisted knots of claim and counterclaim are getting borderline Lovecraftian in shape.

Another said,

[I] didn’t realize that WHATWG and the W3C’s HTML WG were in fact two separate bodies, working in parallel on what effectively amounts to two different specs [1, 2—the entire thread is actually worth reading]. So as far as I can tell, if Ian Hickson removes something from the WHATWG spec, the HTML WG can apparently reinsert it, and vice versa. [T]his… seems impossibly broken. (I originally used a different word here, but, well, propriety and all that.)

Such conversations are taking place in rooms and chatrooms everywhere. The man in charge of HTML 5 appears confident in its rightness. His adherents proclaim a new era of loaves and fishes before the oven has even finished preheating. His articulate critics convey a palpable feeling of crisis. All our hopes now hang on one little Hobbit. What do we do?

As confused as I have continually felt while surfing this whirlwind, I have never stopped being certain of two things:

1. XHTML 1.0—and for that matter, HTML 4.01—will continue to work long after I and my websites are gone. For the web’s present and for any future you or I are likely to see, there is no reason to stop using these languages to craft lean, semantic markup. The combination of CSS, JavaScript, and XHTML 1.0/HTML 4.01 is here to stay, and while the web 10 years from now may offer features not supported by this combination of technologies, we need not fear that these technologies or sites built on them will go away in the decades to come.
2. That said, the creation of a new markup language concerns us all, and an informed community will only help the framers of HTML 5 navigate the sharp rocks of tricky shoals. Whether we influence HTML 5 greatly or not at all, it behooves us to learn as much as we can, and to practice using it on real websites.

Read more

• Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
• Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
• In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
• XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards[/tags]

It has only been a few days but I am already sick of the “XHTML is bullshit, man!” crowd using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely.

A coterie of well-informed codemeisters, from ppk to Ian Hickson, has always had legit beefs with XHTML, the most persuasive of which was Hickson’s:

It is suggested that HTML delivered as text/html is broken and XHTML delivered as text/xml is risky, so authors intending their work for public consumption should stick to HTML 4.01, and authors who wish to use XHTML should deliver their markup as application/xhtml+xml.

This problem always struck me as more theoretical than real, but I pointed it out in every edition of Designing With Web Standards and left it to the reader to decide. When I wrote the first edition of the book, some versions of Mozilla and IE would go into Quirksmode in the presence of HTML 4, breaking CSS layouts. To me, that was a worse problem than whatever was supposed to be scary or bad about using well-formed XHTML syntax while delivering it as HTML all browsers could support.

The opportunity to rethink markup

The social benefit of rethinking markup sealed the deal. XHTML’s introduction in 2000, and its emphasis on rules of construction, gave web standards evangelists like me a platform on which to hook a program of semantic markup replacing the bloated and unsustainable tag soup of the day. The web is better for this and always will be, and there is much still to do, as many people who create websites still have not heard the call.

A few who became disenchanted with XHTML early retreated to HTML 4, and as browsers stopped going into Quirksmode in its presence, valid, structural HTML 4 became a reasonable option again. But both HTML 4 and XHTML 1 were document languages, not transactional languages. They were all noun, and almost no verb. So Ian Hickson, XHTML’s biggest critic, fathered HTML 5, an action-oriented toddler specification that won’t reach adulthood until 2022, although some of it can be used today.

And guess what? HTML 5 is as controversial today as XHTML was in 2000, and there are just as many people who worry that a specification of which they don’t entirely approve is being shoved down their throats by an “uncaring elite.” Only this time, instead of the W3C, the “uncaring elite” is Mr Hickson, with W3C rubber stamp, and input from browser makers, including his employer.

XHTML not dead

All of this is to say that XHTML is not dead (XHTML 2 is dead, thank goodness), and HTML 5 is not here yet. Between now and 2022, we have plenty of time to learn about HTML 5 and contribute to the discussion—and browser makers have 13 years to get it right. Which is also to say all of us—not just those who long ago retreated to HTML 4, or who became fans of HTML 5 before it could even say “Mama”—are entitled to be pleased that standard markup activity will now have a single focus, rather than a dual one (with XHTML 2 the dog spec that no one was willing to mercy-kill until now).

Entitled to be pleased is not the same as entitled to gloat and name call. As DN put it in comment-44126:

What is really rather aggravating is how many people are using this news as a stick with which to beat any developer or freelancer who’s had the audacity to study up on and use XHTML in good faith–or even, much to the horror of the Smug Knowbetters, admire XHTML’s intelligible markup structure–for the brand-new-minted sin of doing the most with XHTML that’s possible. The ‘unofficial Q&A’ is ripe with that kind of condescension. …[D]on’t pin users (front-end developers are merely users of specifications) with Microsoft’s failure to support the correct MIME type.

Read more

• Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
• HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
• Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
• XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]HTML, HTML5, W3C, WTF, XHTML, XML[/tags]

Firefox developers who were initially alerted to a problem on this page, please view the Firefox test page and the page that explains its use. — JZ

The web’s future isn’t what the web’s past cracked it up to be. 1999: XML is the light and XHTML is the way. 2009: XHTML is dead—kind of.

From the W3C news archive for 2 July 2009:

XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity. (Permalink)

Please note that this thread has been updated with useful comments and links that help make sense of the emergence of HTML 5, the death of XHTML 2.0, and what designers and developers need to know about the present and future of web markup.

Read more

• Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
• HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
• Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
• In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009

[tags]W3C, XML, XHTML, HTML, HTML5, WTF[/tags]

Hundreds of millions use Microsoft Internet Explorer to access the web, and Microsoft Outlook to send and receive email. As everyone reading this knows, the good news is that in IE8, Microsoft has released a browser that supports web standards at a high level. The shockingly bad news is that Microsoft is still using the Word rendering engine to display HTML email in Outlook 2010.

What does this mean for web designers, developers, and users? In the words of the “Let’s Fix It” project created by the Email Standards Project, Campaign Monitor, and Newism, it means exactly this:

[F]or the next 5 years your email designs will need tables for layout, have no support for CSS like float and position, no background images and lots more. Want proof? Here’s the same email in Outlook 2000 & 2010.

It’s difficult to believe that in 2009, after diligently improving standards support in IE7 and now IE8, Microsoft would force email designers to use nonsemantic table layout techniques that fractured the web, squandered bandwidth, and made a joke of accessibility back in the 1990s.

Accounting for stupidity

For a company that claims to believe in innovation and standards, and has spent five years redeeming itself in the web standards community, the decision to use the non-standards-compliant, decades-old Word rendering engine in the mail program that accompanies its shiny standards-compliant browser makes no sense from any angle. It’s not good for users, not good for business, not good for designers. It’s not logical, not on-brand, and the very opposite of a PR win.

Rumor has it that Microsoft chose the Word rendering engine because its Outlook division “couldn’t afford” to pay its browser division for IE8. And by “couldn’t afford” I don’t mean Microsoft has no money; I mean someone at this fabulously wealthy corporation must have neglected to budget for an internal cost. Big companies love these fictions where one part of the company “pays” another, and accountants love this stuff as well, for reasons that make Jesus cry out anew.

But if the rumor’s right, and if the Outlook division couldn’t afford to license the IE8 rendering engine, there are two very simple solutions: use Webkit or Gecko. They’re both free, and they both kick ass.

Why it matters

You may hope that this bone-headed decision will push millions of people into the warm embrace of Opera, Safari, Chrome, and Firefox, but it probably won’t. Most people, especially most working people, don’t have a choice about their operating system or browser. Ditto their corporate email platform.

Likewise, most web designers, whether in-house, agency, or freelance, are perpetually called upon to create HTML emails for opt-in customers. As Outlook’s Word rendering engine doesn’t support the most basic CSS layout tools such as float, designers cannot use our hard-won standards-based layout tools in the creation of these mails—unless they and their employers are willing to send broken messages to tens millions of Outlook users. No employer, of course, would sanction such a strategy. And this is precisely how self-serving decisions by Microsoft profoundly retard the adoption of standards on the web. Even when one Microsoft division has embraced standards, actions by another division ensure that millions of customers will have substandard experiences and hundreds of thousands of developers still won’t get the message that our medium has standards which can be used today.

So it’s up to us, the community, to let Microsoft know how we feel.

Participate in the Outlook’s Broken project. All it takes is a tweet.

[tags]browsers, bugs, IE8, outlook, microsoft, iranelection[/tags]

While the entire HTML 5 standard is years or more from adoption, there are many powerful features available in browsers today. In fact, five key next-generation features are already available in the latest (sometimes experimental) browser builds from Firefox, Opera, Safari, and Google Chrome.

Tim O’Reilly: Google Bets Big on HTML 5

Striving to avoid the mistake Microsoft made when it bet on binary applications over the web, Google is counting on HTML 5 adoption to expand the capability of web applications. Tim O’Reilly describes Google’s strategy and lists five key HTML 5 features that are already supported in Safari, Firefox, Opera, and Chrome.

[tags]HTML5, Google, O’Reilly, TimO’Reilly, canvas, browsers, webapps, web applications, webstandards[/tags]

[tags]zeldman, zeldman.com, design, redesign, css[/tags]

The body and bottom of the next zeldman.com design are now finished. Tomorrow I start working on the top.

Have a look.

Looks extra sweet in iPhone.

I’m designing from the content out. Meaning that I designed the middle of the page (the part you read) first. Because that’s what this site is about.

When I was satisfied that it was not only readable but actually encouraged reading, I brought in colors and started working on the footer. (The colors, I need not point out to longtime visitors, hearken back to the zeldman.com brand as it was in the 1990s.)

The footer, I reckoned, was the right place for my literary and software products.

I designed the grid in my head, verified it on sketch paper, and laid out the footer bits in Photoshop just to make sure they fit and looked right. Essentially, though, this is a design process that takes place outside Photoshop. That is, it starts in my head, gets interpreted via CSS, viewed in a browser, and tweaked.

Do not interpret this as me dumping on Photoshop. I love Photoshop and could not live or work without it. But especially for a simple site focused on reading, I find it quicker and easier to tweak font settings in code than to laboriously render pages in Photoshop.

If you view source, I haven’t optimized the CSS. (There’s no sense in doing so yet, as I still have to design the top of the page.)

I thought about waiting till I was finished before showing anything. That, after all, is what any sensible designer would do. But this site has a long history of redesigning in public, and the current design has been with us at least four years too long. Since I can’t snap my fingers and change it, sharing is the next best thing.

A work in progress. Like ourselves.

[tags]zeldman, zeldman.com, redesign, webdesign, css, code[/tags]

• Can we finally get real type on the web?
• Does beauty in design have a benefit besides aesthetic pleasure?

Real Fonts on the Web: An Interview with The Font Bureau’s David Berlow

by DAVID BERLOW, JEFFREY ZELDMAN

Is there life after Georgia? We ask David Berlow, co-founder of The Font Bureau, Inc, and the first TrueType type designer, how type designers and web designers can work together to resolve licensing and technology issues that stand between us and real fonts on the web.

In Defense of Eye Candy

by STEPHEN P. ANDERSON

Research proves attractive things work better. How we think cannot be separated from how we feel. The next time a boss, client, or co-worker scoffs at the notion that beauty is an important aspect of interface design, point their peepers here.

A List Apart explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

[tags]alistapart, type, typography, realtype, truetype, CSS, beauty, design, aesthetics[/tags]

I had no expectations. I made no assumptions. I just clicked and tested.

Such tests tell us little

I make no claims about what I found. If all the home pages of the top 100 sites were valid, it would not mean that the pages beneath the home page level were valid, nor would it prove that the sites were authored semantically. (An HTML 4.0 table layout with no semantics can validate; so can a site composed entirely of non-semantic divs with presentational labels.)

Validation is not the be-all of standards-based design; it merely indicates that the markup, whatever its semantic quality may be, complies with the requirements of a particular standard. Conversely, lack of validation does not prove lack of interest in web standards: ads and other third-party content can wreck a once-valid template, as can later third-party development work.

Moreover, nothing causal or predictive can be determined from these results. If 25% of the top 100 sites validated in my test, it would not mean that 25% of all sites on the web validate.

And I got nothing like 25%.

Enough disclaimers. On with the test.

Seven percent validate

On this day, in this test, seven out of 100 “top US” sites validated:

1. MSN (#7 in Alexa’s list) validates as XHTML 1.0 Strict. Who’d a thunk it? (Validation link)
2. Craigslist (#10) validates as HTML 4.01 Transitional. I’ll buy that! (Validation link)
3. WordPress (#22) validates as XHTML 1.0 Transitional. The power of the press, baby! (Validation link)
4. Time Warner RoadRunner (#39) validates as XHTML 1.0 Transitional. Meep-Meep! (Validation link)
5. BBC Newsline Ticker (#50) validates as XHTML 1.0 Strict. Cheers, mates! (Validation link)
6. The US Internal Revenue Service (#58) validates as HTML 4.01 Transitional. Our tax dollars at work! (Validation link)
7. TinyPic (#73) (“Free Image Hosting”), coded by ZURB, validates as XHTML 1.0 Transitional. (Validation link)

Also-rans (one or two errors)

1. Wikipedia (#8) almost validates as XHTML 1.0 Strict (two errors).
2. Apple (#29) almost validates as HTML 4.01 Transitional (two errors).
3. Linkedin.com (#45) almost validates as HTML 4.01 Transitional (one error).
4. AWeber Communications (#83) almost validates as XHTML 1.0 Transitional (one error: an onClick element)

Suis generis

The Pirate Bay (#68), “the world’s largest BitTorrent tracker,” goes in and out of validation. When it validates, it’s a beautiful thing, and it belongs on the list. But when it goes out of validation, it can quickly stack up ten errors or more. (Validation Link)

No-shows

Google (#1) does not validate or declare a DOCTYPE.

Yahoo (#2) does not validate or declare a DOCTYPE.

YouTube (#3) does not validate but at least declares that it is HTML 4.01 Transitional. Progress!

A surprising number of sites that do not come close to validating declare a DOCTYPE of XHTML 1.0 Strict. For instance, Twitter (#93) is authored in XHTML 1.0 Strict, although it contains seven errors.

This preference for Strict among non-validating sites suggests that at one point these sites were made over by standards-aware developers; but that any standards improvements made to these sites were lost by subsequent developers. (It doesn’t prove this; it merely suggests.) Another possibility is that some developers use tools that are more standards-aware than they are. (For instance, a developer with little to no knowledge of web standards might use a tool that defaults to the XHTML 1.0 Strict DOCTYPE.)

Some sites that used to validate (such as Blogger.com, previously designed by Douglas Bowman, and Reference.com, previously designed by Happy Cog) no longer do so; maintaining standards or design compliance may not have been important to new owners or new directors.

[tags]validation, webstandards, alexa, test[/tags]