We’re going to be bringing our daughter to Disney World for her first time pretty soon, so I have Disney on my mind on Blue Beanie Day 2013.

One of the things I love about Disney is how imagineers work hard to “plus” their creations, even when they’re already great.

They ask, how can we take an attraction that is already beloved, like Pirates of the Caribbean, and “plus it” with something fun and new? And soon enough, clever scenes of Captain Jack Sparrow join the fun.

I think that’s a great way to think about web standards.

The art of syntax

It’s been about a decade since I first read Jeffrey Zeldman’s Designing with Web Standards. That book fundamentally altered how I made web pages. It kindled in me a desire to follow web standards, as it did for so many people.

For a long time, that meant that I obsessed over syntax and the little green check mark that told me that my page was XHTML compliant.

While it’s no longer required in HTML5, I will to my dying breath use quotes around attributes, close every element and use lower case for all my HTML. These things aren’t required per se, but they add a level of consistency. Consistent HTML is easier to teach, and it also helps to eliminate a lot of odd errors.

I still believe that putting together HTML is an under-appreciated art. Selecting the right HTML element not just so that it can be styled or manipulated by Javascript, but to provide appropriate semantic meaning. I recognize that “semantic” HTML is often a consensual hallucination that often doesn’t have an impact on real users, but darn it, the right thing to do is the right thing to do.

How sausage and standards get made

It’s easy to get bitter and cynical about our standards. We’re finally recovering from a dark age where the future of HTML was in the sole hands of a benevolent dictator. A lot of improvements were made to HTML in that time—HTML5 would not have happened otherwise. However, some questionable decisions were made as well. Thankfully some of the decisions about the future of HTML have come back to the W3C through the leadership of Steve Faulkner. That’s leading to some more sensible guidelines, like being able to use the cite element within blockquote.

That’s not to say that the process of making web standards isn’t... challenging. I’ve been following the process of getting a native way to author responsive images in HTML for, oh, a few years now.

Watching the sausage made on how a web standard is developed reveals that web standards are not handed down from the mountain top on tablets, perfect and immutable.

Web standards are created by a lot of smart people doing their best to figure out the best approach to difficult problems. A lot of times good decisions are made, and sometimes decisions are made that hopefully get revisited and fixed.

A three-legged stool for standards

And yet we persevere. We try to come up with web standards that work like a three-legged stool:

• A web standard that offers clear guidelines
• A web standard implemented correctly in browsers
• A web standard used by developers and designers in code

When all three legs of that stool are there, we have an effective standard. You and I can write code a certain way, and it will “just work” in the browser.

Older browsers and standards

In reality, that situation seems all too rare. Rarely can you write your HTML and CSS, see those little green check marks, and then your process is done.

We all like to dump on Internet Explorer, but the biggest problem with IE isn’t that each version was bad at the time of their creation. It’s that a lot of other browsers auto-update now, while older versions of IE still hang around.

Our standards are not static. They change. They develop. Our understanding of HTML and CSS are different now than they were five years ago, ten years ago. When standards are first written, sometimes they are ambiguous. Browser developers interpret a guideline in different ways. And over time, hopefully that understanding of web standards improves for both browsers and for web developers, and our standards get better.

But older browsers that hang around, like older versions of IE or older versions of the Android browser, have captured that old, incomplete understanding of our standards. Older browsers can’t take advantage of new tools in web standards.

And that gets frustrating. I’ve certainly gotten frustrated. If something’s a standard, shouldn’t I just be able to author to the standard, and things just work? I followed the standard, why should I have to care that my site looks broken in this stupid old browser? Or in this current browser that has a different understanding of a newly developed standard?

If I have to check my site against dozens, if not hundreds of browsers and devices, what are these standards worth anyhow?

Not the same in every browser

What has helped, I think, is that the rise of smartphones and tablets has taught pretty much everyone that no, a website does not need to look the same in every browser. And often, it’s harmful when a site does. Pixel perfection is not and should not be the goal anymore.

People who come to our websites have a right to expect that they can use the sites we create, pretty much no mater what. That makes our jobs difficult, yes, but if you thought making the web was easy, you’re maybe in the wrong line of work.

What’s crucial here is in how we define what it means when we say we want our sites to work everywhere.

Allowing users in older browsers to do basic things like accessing our content and filling out forms, well that seems fair. But should they get every bell and whistle in our design? They will probably survive without every drop shadow and gradient, or even if things look a little bit wonky.

Leaving a little bit of wonkiness, if we can all agree to do so, provides an important signal that hey, maybe you should stop using Netscape Communicator. It’s really insecure, and the fact that so many websites look a bit... off... is maybe a hint to you that it’s time to figure out this upgrading thing. Can you use our site in your crusty old browser? Sure! Have at it! But our site could look a bit better if you upgraded.

That seems fair.

Standards as a starting point

Wrapping back to my point, which involves Disney imagineers. Web standards are a starting point. Using HTML and CSS the “right” way gives you the best chance of your site working right out of the gate.

You don’t stop there, though.

Lack of control is a strength

What does it mean for a site to work? A site works when it is easy to use. A fundamental truth of the web is that you don’t have control over how people will use your site.

You don’t control if they are on a laptop or a phone. You don’t control if they have issues with using a mouse or seeing your site or hearing the audio on your site.

The essence of web is that lack of control. That’s what makes the web great. There are so many ways to use the web that nearly everybody can do it.

So your site “works” when people can use your site no matter how they choose to come to your site.

Your site still has an emotional impact that encourages users to do the things you want them to do. Your site provides a visual impact for those who can appreciate that. Your site is easy to navigate no matter what device is used. Your site allows access to content no matter how somebody gets there.

Plussing web standards

Following the standards for HTML5 and CSS3 will get your site part of the way there. You’ll get further along if you count WCAG2 and ARIA in your staple of standards you adhere to with all your might. But even with that, you need more.

That green check mark doesn’t solve everything. But it’s a good place to start. Those green check marks offer a pretty good attraction.

Now plus it.