Four years ago today, Tantek Çelik and Kevin Marks gave a presentation on real-world semantics. Working backwards from HTML extensions like XFN (created by Tantek, Matt Mullenweg, and Eric Meyer), the paper showed how designers and developers could add semantics to today’s web rather than starting from scratch or waiting for a “purer” markup language to bring us an “uppercase semantic web.”
As with ‘most all great ideas, the principles were simple and, in hindsight, profoundly obvious. Do what designers were already doing. Instead of toiling over new languages that might or might not get adopted, use existing (X)HTML elements such as rel and class, and agree on such things as common class names for simple things like relationship definitions.
On behalf of all web designers and developers, thank you, Tantek and friends, and happy birthday.
Jonathan Follett takes another trip down the the long hallway, looking at ways to collaborate, communicate, and manage conflict in virtual space.
Comments off. Talk on ALA!
In defense of version targeting
We knew when we published this issue of A List Apart that it would light a match to the gaseous underbelly of standards-based web design, but we thought more than a handful of readers would respect the parties involved enough to consider the proposal on its merits. Alas, the ingrained dislike of Microsoft is too strong, and the desire to see every site built with web standards is too ardently felt, for the proposal to get a fair viewing.
The always dapper Mr Jeremy Keith provides a pleasantly thoughtful exception to the massive glowering.
Jeremy sees that version targeting offers a solution to the problem of keeping Microsoft’s Internet Explorer on the web standards track, but he quarrels with an implementation detail: namely, that if you omit the meta element that instructs IE to behave as a particular version—in other words, if you opt out—the browser defaults to IE7’s rendering.
Jeremy thinks, if you opt out by omitting the meta element, the browser should default to the latest version’s rendering, be that version IE8, IE10, or IE412.
I respect Jeremy—all the more so after reading his reasoned response to a bombshell proposal—but disagree with his reasoning on this point.
In his post, Jeremy provides the following example to prove that the “IE7 rendering=default” decision is broken:
Let’s say you’re building a website right now that uses a CSS feature such as generated content. Any browsers that currently support generated content will correctly parse your CSS declarations. Future browsers that will support generated content should also parse those CSS declarations. This expected behaviour will not occur in Internet Explorer. IE8 will include support for generated content. But unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.
It sounds reasonable, but it’s an unlikely scenario, and the exact opposite of what will happen over and over again out there in the real world of web development, which, for too many, is a fallen world.
Jeremy, since you are among the tiny minority of enlightened web developers who know what generated content is, and who care that IE8 will support it (and since you read ALA), you will know to include a meta element that instructs IE8 to act like IE8—or you will use “edge” to instruct IE14 to act like IE14. Easy-peasy. No hardship for you.
By contrast, the many developers who don’t understand or care about web standards, and who only test their CSS and scripts in the latest version of IE, won’t opt in, so their stuff will render in IE8 the same way it rendered in IE7.
That sounds bad, but it’s actually good, because it means that their “IE7-tested” sites won’t “break” in IE8. Therefore their clients won’t scream. Therefore Microsoft won’t be inundated with complaints which, in the hands of the wrong director of marketing, could lead to the firing of standards-oriented browser engineers on the IE team. The wholesale firing of standards-oriented developers would jerk IE off the web standards path just when it has achieved sure footing. And if IE were to abandon standards, accessible, standards-compliant design would no longer have a chance. Standards only work when all browsers support them. That IE has the largest market share simply heightens the stakes.
When I look at the scenarios of who is likely to do what where web standards and version targeting are concerned, the IE7 default for those who don’t opt in appears to be the correct design decision. Of couse I’m more than willing to be proved wrong.
Regardless, the discussion raised by Mr Keith is exactly the kind of discussion our community should be having.
Unfortunately, the conversation we’re mostly having so far is neither thoughtful nor helpful. But perhaps when the shock dies down, a few more people will consider the merits of version targeting.
To help them do so, let me break it down the way I did for myself:
With version targeting, IE stays on the path of web standards.
Without it, ineptly made websites “break,” putting IE’s standards compliance at risk.
If IE were to stop supporting standards, standards would stop working.
I’d love to live in a world where the vast majority of websites were compliant and accessible. But that’s not the real world. At least, not today.
Today too many sites aren’t semantic, don’t validate, and aren’t designed to specs of the W3C. Idealists think we can change this by “forcing” ignorant developers to get wisdom about web standards. Idealists hope, if sites suddenly display poorly in IE, the developers will want to know why, and will embark on a magical journey of web standards learning.
You feel that way because you are special.
You care about semantics and accessibility because it’s right.
That’s how we’re going to get more converts. By persuading more people that it’s right.
We won’t get converts by breaking sites and ridiculing their creators for not knowing as much as we do.
I commend Aaron Gustafson for his courage and intelligence and thank him and his small band of colleagues, and the engineers they worked with at Microsoft, for offering a way forward that keeps web standards front and center in all future versions of IE.
Discussion is now closed, but you can enjoy the 235 responses that came in before we shut the iron door.
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.
An Event Apart, the design conference for people who make websites, kicks off its 2008 season with An Event Apart New Orleans, a monster, 19-hour, two-day creative session. Join us April 24–25 at the Hilton New Orleans Riverside for two intense, 9.5-hour-long days of learning and inspiration, featuring twelve of your favorite web design authors.
See Dave Shea, co-author, Zen of CSS Design, explore what makes sites flexible visually, experientially, and code-wise.
See Jeff Veen, design manager, Google, explore how new thinking, born of creating the latest generation of web apps, is being infused into design practices.
See Robert Hoekman Jr., author, Designing the Obvious, perform slam-bang, on-the-spot usability reviews of sites submitted by our live audience on the fly.
See Cameron Moll, author, Mobile Web Design, uncover the differences between good and great design.
See Andy Clarke, author, Transcending CSS, explain how comic books inspire his award-winning web layouts.
See Stephanie Sullivan, co-author, Mastering CSS with Dreamweaver CS3, explore practical, standards-based approaches and techniques to some of today’s toughtest design challenges.
See Aarron Walter, author, Building Findable Web Sites, explain “findability bliss through web standards SEO”
See Brian Oberkirch, Publisher, Like It Matters, review, catalog, dissect, and champion small design victories that daisy chain to create a delightful overall user experience.
See Jason Santa Maria, designer, Happy Cog, share techniques for maintaining individuality and brand distinction in a world of generic templates and design sameness.
See An Event Apart co-founder Eric Meyer, author, CSS: The Definitive Guide, present two new talks that shed brilliant light on the darkest corners of CSS.
As for me, I’ll be doing two new sessions on the whatness of web design (what it is, what it ain’t, and why it matters) and the whereness of web standards (as in, where we are with them).
It’s the longest, biggest, densest, hardest, coolest show we’ve ever done, and we’re doing it where Louis learned to blow his horn. Join us if you can.
Jeremy Keith’s “Year Zero” beautifully explains why the W3C needs our backs, not our bullets.
The W3C is maddeningly opaque and its lieutenants will sometimes march madly into the sea, but it is all that stands between us and the whirlwind.
Slow the W3C will always be. Slow comes with the territory. If you glimpse even a hint of the level of detail required to craft usable standards, you’ll understand the slowness and maybe even be grateful for it—as you’d be grateful for a surgeon who takes his time while operating on your pancreas.
But the secrecy (which makes us read bad things into the slowness) must and will change. To my knowledge, the W3C has been working on its transparency problems for at least two years and making real change—just very slowly (there’s that word again) and incrementally and hence not at all obviously.
Key decision makers within the W3C intend to do much more, but they need to get their colleagues on board, and consensus-building is a bitch. A slow bitch.
If designers and developers are more aware of the problems than of the fact that the W3C is working to solve them, it’s because the W3C is not great at outreach. If they were great at outreach, we wouldn’t have needed a Web Standards Project to persuade browser makers to implement the specs and designers and developers to use them.
Designers sometimes compare the slow pace of standards with the fast pace of, say, Flash. But it is like comparing the output of the United Nations to the laws passed by a small benevolent dictatorship. When a company owns a technology, it can move fast. When a hundred companies that mistrust each other need to agree to every detail of a technology that only exists insofar as their phones and browsers support it, surprise, surprise, the pace is quite slow.
The W3C is working on its speed issues, too. It’s been forced to work on them by outside groups and by the success of microformats. But detailed interoperability of profound technologies no company owns is never going to happen half as fast as we’d like.
You want instant gratification, buy an iPod. You want standards that work, help. Or at least stop shouting.
Apple and Microsoft and Netscape and Sun and Opera have been suing each other since the W3C started. What lawyers do has never stopped developers from Apple and Microsoft and Netscape and Sun and Opera from working together to craft W3C and ECMA specs.
And even if this time is different—even if, just this once, the existence of a lawsuit will stop a working group from working—I’m not sure it’s practical or advisable to cut browser makers out of the equation. For one thing, have you seen what the W3C comes up with when browser developers aren’t involved?
I can’t comment on the merits of Opera’s legal action because it is a legal action and I’m not a lawyer, let alone a lawyer versed in European antitrust law.
Based on past history, I don’t think the lawsuit will prevent the members of the CSS working group from doing their jobs. If it does, then the title of your post will be borne out, and Bert Bos, as group leader, will take action.
The web standards movement needs leaders who are passionate, but their leadership must also make sense. Proposing change when the change makes sense is good. Proposing change because you are disappointed and frustrated isn’t good enough. Anger can be brilliantly motivating; but anger is not a strategy.
[tags]webstandards, css, working group, opera, microsoft, antitrust, lawsuit, browsers[/tags]
Who’s afraid of HTML 5? Not Lachlan Hunt! As both a front-end web developer and a contributor to HTML 5, he tells us what we can expect from the emerging markup specification, whose goals include more flexibility and greater interoperability.
Ask a web designer what makes a site great, and you’re likely to hear “ease of use.” Jim Ramsey begs to differ. Web applications in particular, he tells us, work best and engage most profoundly when they challenge users to overcome difficulties.
We have what we think is a special issue of A List Apart for people who make websites.
Every responsible web designer has theories about how best to serve type on the web. In How to Size Text in CSS, Richard Rutter puts the theories to the test, conducting experiments to determine the best of all best practices for setting type on the web. Richard’s recommendation lets designers reliably control text size and the vertical grid, while leaving readers free to resize text.
And in Understanding Web Design, I explain why cultural and business leaders mistake web design for something it’s not; show how these misunderstandings retard critical discourse and prevent projects from reaching their greatest potential; and provide a framework for better design through clearer understanding.
Plus, from October 2001, we resurrect Typography Matters by Erin Kissane, the magazine’s editor, who is currently on sabbatical.
On Monday, November 26, 2007, don your blue beanie to show your support for web standards and accessibility. So goes the pitch by Douglas Vos, founder of Facebook’s Designing With Web Standards Group:
Monday, November 26, 2007 is the day thousands of Standardistas (people who support web standards) will wear a Blue Beanie to show their support for accessible, semantic web content. … Don a Blue Beanie and snap a photo. Then on November 26, switch your profile picture in Facebook and post your photo to the Blue Beanie Day group at Flickr.
Is this silly or serious? Seems to me, it’s a bit of both. If enough people do it on enough social networks, it might even raise web standards awareness in a small but positive way. (As opposed to, say, busting people for a validation error, which, surprisingly, doesn’t win you their love.)
Make a personal commitment to fight Web Standards Apathy. Show solidarity with the Standardistas on November 26th, 2007.
Buy, beg, or borrow a Blue Beanie (blue hat or cap, even a black or grey one will do in a pinch.)
Take a photo of yourself wearing the Blue Beanie. Or take a cool group photo of you and your friends wearing Blue Beanies.
Post your photo, or photos to Facebook, the Flickr pool, and other social networks on November 26th, 2007. Remember to switch your profile photos that day on all your social networks, like Flickr, Twitter, Last.fm, iLike, Pownce, Dopplr… you name it.
Promote Blue Beanie Day in your blog or wiki starting today, and tell all your friends to get ready for Blue Beanie Day. Start by inviting all your Facebook friends to this event.