Web Standards’ Three Buckets of Pain

I spent this week at the W3C’s annual technical plenary, which is a week of “discussing” the future of the foundations and future of the web. I spent the first part of the week in the CSS Working Group discussing CSS3 features and CSS2.1 issues. Tuesday evening and Wednesday were spent in the AC meeting and Technical Plenary day (everyone gets together in a big room for panel discussions and lightning talks about standards-related issues – my favorite day of the week). The latter part of the week I spent in the new HTML Working Group talking about a lot of issues I’m not up to speed on because I just joined the working group (but, of course, that didn’t stop me from jumping in).
Molly led a panel during Plenary Day called From the Outside, In: Real World Perspectives on the W3C with a handful of designers and developers who aren’t currently involved in the W3C (Aaron, Matthew, Patrick and Stephanie). The panel helped solidify a few things for me and I want to try to explore them in this post. The panel wasn’t bad by any stretch. I think it was brave for them to come into the “lion’s den” and give the W3C their perspectives. But, I felt that the way the panel was presented left people in the audience confused about the overall message, and exposes a huge gap between the W3C’s understanding of “web standards” and the web development world’s definition.
Before I get any further, I need to explain where I stand here. I have a foot planted firmly in both worlds. I’ve been building web applications for almost a decade and have been a fan of standards-based development since late 2001 when my blog validated as XHTML 1.0 Transitional. I’ve been a member of the CSS Working Group for about four years as well.
The complaints about web standards are varied and many, and the panel made it feel like they all fell squarely at the feet of the W3C. But, that’s just not the case. I think a lot of the problem comes from our (being the web development world) definition of “web standards” being almost completely different from the definition understood inside the W3C. To web developers the world over, “web standards” means: “What I have to do to get my page to look right in all the modern browsers.” The W3C’s definition is “the underlying specifications that implementors (in our case, web browsers) use”. See, the standards aren’t written for, or by, web developers. In the case of HTML and CSS, they’re written for and by the people who create web browsers – which is why they’re so hard for the rest of us to understand. The vocabulary is different. The requirements are different. There is a whole world of pain in store for the brave soul who wants to write a web browser – and it’s a uniquely different world of pain from someone (you and me) who wants to apply those standards to build a web page that will render in one of those web browsers.
For the rest of this blog post, anyone building a web browser is implementing the standards, and anyone trying to build a web application is applying the standards. People building web browsers have to implement parsers, renderers, conformance checks, error handling and all sorts of other nasty things to get a browser to function. People building web applications have to take the standards and apply them through an implementation (in our case, a browser). We’re not writing the parser, we’re writing the thing that gets parsed.
And there are our three buckets of pain:
# The Specifications
# The Implementations
# The Applications
h4. The Problems With The Specifications
The major problems I hear about the W3C and its processes are:
# It takes too long.
# I don’t know what’s going on or when we’re going to see the standards come out.
# Spec X is missing this, this and this!
# Developers and designers have no voice in the standards at all!
One, two and four are, or were, true. Number three is only half true most of the time. Every time I ask developers or designers I know about what’s missing from CSS, I always hear “I want multiple backgrounds and a real layout model. Oh, and border images!” Two of those are already implemented in Safari, and I’ll bet you Firefox will have them done shortly. They’re all in CSS3 somewhere.
Web developers and designers have more of a voice on the CSS Working Group than ever. There are currently three designers in the working group (two from AOL and one invited expert). The group is also working with the new CSS11 group, and is actively gathering feedback. The new HTML Working Group has several members who are web developers and over four hundred invited experts (who can’t all be building browsers).
The W3C is working very hard at opening up. It’s not there, and they’ll stumble, but the attempt is being made.
h4. The Problems With Implementations
# Microsoft took a vacation. IE6 has been out (and broken) for a very long time. We got complacent in our hacks and nonsense to work around its “quirks” and now those bad habits and hacks are getting stale.
# They don’t move fast enough! See number one. We’re tired of waiting, but laying the blame on the CSS Working Group instead of Microsoft. If Microsoft had been actively engaged in the Working Group this whole time, we’d be a lot farther along. It’s very hard to get to interoperability when the market leader is working on other things.
# They have bugs. Every piece of software ever written has bugs. Thankfully, bugs get fixed in the other browsers fairly quickly. Unfortunately, IE is now on a 15-20 month release cycle, which means we have a while to wait until we see things we need like display: table and probably 30-45 months until we can hope to see advanced layout or the grid implemented.
h4. The Problems With Applications
(this is going to be painful… just hold on – it’ll be over soon)
Our biggest problem as web developers and designers is the misunderstanding I pointed out at the beginning. We need to understand the three buckets of pain and what we can expect out of each one. There’s no reason to rush standards out if no one’s going to implement them. There’s no reason for us to try to use them until they’ve been implemented.
We have to admit that we made a fundamental mistake in how we advocated building things with “web standards”. As someone who’s done training for the last five years, this is as much my fault as anyone’s. We taught to the implementations. We never taught the distinctions between the specification and the implementation. We never taught that we were teaching an application of the standard and not the standard itself.
The hacks became the standard and not the exception. We taught without understanding the long term implications of teaching hack management instead of teaching the specification and the application of it separately.
h4. How do we move forward?
We need more developers and designers plugged into both worlds. To work on the specifications themselves, or even read and give feedback on them, you have to abandon any hope that this will be useful to you in your development world for three to five years. Once you do that (it took me two years to get that through my head), you’ll be much less frustrated, and might actually be helpful. To a degree, you also have to abandon your notions of how you do things today. When thinking about layout, you have to give up thinking that “float” is the best way to do it (because, please, it’s just not).
We need to reboot our perceptions of web development and start thinking towards the future. It’s a new world, and getting newer every day. Our best practices have to evolve – our disciplines have to evolve. We need to think about a world without IE6. It’s going to happen. We need to come up with better ways of building web applications. We need to come up with better ways of teaching the value of web standards. We need to do a better job of educating designers and developers about the consequences of building web applications. We told them all the good things that would happen when they did it our way, but did we tell them that hacks go away? Did we tell them that browsers evolve and that hack they spent all that time on to get things to line up in IE6 will go away some day?
I don’t think I covered everything I wanted to say. There are a lot of things swirling around in my head right now. I had my mind blown last week by this realization and it will probably take more thinking about it before it really crystalizes and I can really explain what I’m feeling. But, right now, this is it, and that’s as good as I’ve got: It feels like I’ve spent the last 7 years living a lie, but the truth is so much more interesting and complex than the lie ever was. It feels like a stronger foundation, but wider and darker in the corners, than the one I’ve been standing on.

11 thoughts on “Web Standards’ Three Buckets of Pain”

  1. Well thought out, Kevin, and I can’t find a single point I don’t agree with at some level with one exception.
    I, and the panel, worked exceptionally hard to not “lay blame” at the foot of the W3C. If you listen at least to my words, I repeated, and clarified, that there “is the perception” of the W3C being part of the problem. This is not the same as laying blame at the feet of anyone. This was not W3C bashing. Not in the least.
    I think if it felt that way, perhaps a revisit to the points you raise in terms of gaps and pain points because of insufficient messaging and communication between all points of activity: The making of specs, th implementation, the applications, and the myriad challenges we have in communicating between EACH of those silos.
    This is no one’s fault. This is what being evolutionary is all about – adaptation to change. I must say I’m quite impressed you were able to get it together this soon to sort out your feelings, I know my own are going to be difficult to clarify for some time to come.
    Thank you Kevin, for all you do. It makes a huge difference. So keep that chin of yours up and remember we have an awesome community where genius abounds. We’ll solve these problems, and many more to come, and probably make a whole lotta new ones in the process.
    I imagine in that way, it must be a bit like parenting :)
    Always, M

  2. Hey Kevin,
    Hope you had a safe trip back. The post is interesting, but I stumbled on some of your words. :p
    You said: “The W3C is working very hard at opening up. It’s not there, and they’ll stumble, but the attempt is being made.”
    which I read as “whatever you try you will fail” which leaves me with a big question why should we try if you already think we are doomed to failure.
    First action item for coming christmas, I will buy a Weeble suit, it might help in my effort of opening the W3C and being in liaison with the developers, designers and the Web pro communities. :)))

  3. Kevin, really well thought-out post. You did a great job of capturing the state of the world as a lot of developers and designers feel it today.
    Karl, I’m really excited by your efforts with opening the W3C. The only thing is I hope its more then just “opening up.” We can make our mailing lists and our documents publicly available… we can make more primers… but I’m not sure that’s enough. It’s about engaging the development and design community in a genuine conversation…. its as you said it “being in liaison with the developers, designers and the Web pro communities.” I’m here to be a servant to your efforts however i can be.

  4. Kevin, really well thought-out post. You did a great job of capturing the state of the world as a lot of developers and designers feel it today.
    Karl, I’m really excited by your efforts with opening the W3C. The only thing is I hope its more then just “opening up.” We can make our mailing lists and our documents publicly available… we can make more primers… but I’m not sure that’s enough. It’s about engaging the development and design community in a genuine conversation…. its as you said it “being in liaison with the developers, designers and the Web pro communities.” I’m here to be a servant to your efforts however i can be.

  5. As a developer you will probably understand this. There are steps you have to take to properly implement developed code. First, you have to have a spec, then you implement against that spec, then you test the implementation against the spec. The W3C has created several specs, and Browser developers developed code against those specs. Sadly it’s the third part that falls down. The W3C did a great job providing tools to validate HTML, CSS, and other specs for the web development community at large, but they haven’t done anything to validate there specs for the browser developers that I know of.
    If Microsoft ran pages through IE and saw glaring errors because it didn’t render code correctly, maybe they’d have something to go on. Similar to automated test suites. Give them a path to properly implement and the tools to do the job right, and it might benefit the developer community. Maybe the W3c doesn’t need to be more open with the “web development” community but more to the “browser development” community.

  6. Karl, stumbling isn’t falling, it’s a minor unexpected course correction. I see the new HTML Working Group as an experiment and a work in progress. It’s going to take time to work out all the kinks and get everything running smoothly.

  7. Interesting thread.
    From my perspective, three major forces have been overlooked within the areas of specification, implementation and application. It is, in my belief, going to continue and will further dilute the value of specification and implementation.
    The management by consensus model for spec development is failing.
    There has not existed a direct financial incentive or cost for success in implementation or failure to implement specification.
    Finally, application is driven by market forces.
    I can foresee a future wherein browser dependency is reduced solely for static Internet communication and wherein dynamic content (including data management and use) is delivered, managed and controlled by stand-alone RIAs and by the operating systems.
    This post is prefaced with the disclaimer that all statements are an obvious over simplification for the purpose of brevity.

  8. The problem is that W3C usually deals with the theoretical base of web development, it is like a sort of science. And sometimes it is impossible for us, common users, who apply this knowledge into practice, to understand the complex language of science. Everything should be intelligible.

  9. Kevin – do you know of anyone ever developing and maintaining a matrix of exactly what CSS specs have been implemented by browser? I haven’t even bothered to look at implementing any new CSS specs because I want to support IE 6, but perhaps some brutal transparency would be helpful in raising awareness of IE’s lag in this process.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>