Friday, August 21, 2009

On Standards Organizations

In light of Guido van Rossum's recent Twitter post, the discussion about using divs for layout versus using tables has been revived. Both sides of the discussion are presenting the same arguments as are always presented in this discussion, and I'm not going to beleaguer those arguments further. Suffice it to say that I disagree with van Rossum; following the standards *is* worth it.

However, van Rossum's post does bring our attention to a real problem: even in browsers with good standards-compliance, simple tasks are more complicated than they could and should be.

Try, for example to create a horizontal navigation bar. This simple task is apparently difficult enough to warrant hundreds of tutorials online. Now try to make that same CSS space the links evenly to the width of the page and work intelligently when you have an unknown number of links. Apparently this cannot be done without a brittle JavaScript hack. The reason is that CSS only allows you to hardcode a width percentage for each list item.

The problem here is not the browsers, it's the standard. The standards that W3C puts out aren't good enough to represent solutions to many real problems that web developers are trying to solve.

The most common argument for excluding new features in the standard is that browsers won't be able to conform to the standard. But this is a moot point; browsers already can't comply with standards. The point of the standards isn't to get 100% compliance, it's to ensure that all the browsers work similarly. After all, it's not like there are many websites that have the Acid3 Test on their front page. Having more features in the standard merely gives browsers a higher target for which to aim, and aiming higher can only help the quality of the internet experience for all involved.

An example of this in action comes from the Perl community: Perl has consistently driven innovation in scripting language design by setting ambitious goals. In fact, some of their goals have been so ambitious as to have been formally proven impossible. But setting the bar high has kept Perl a relevant language.

The only ones who benefit from having the bar set low are corporations with large codebases to support: new features sometimes break reverse compatibility, and updating code takes a lot of work. So it should come as no surprise that such corporations have stocked the W3C with their own people to protect their corporate interests. The end result is that average web developers are not represented in the standards with which they are forced to work.

This problem is not unique to the internet. Standards organizations are almost inherently controlled by corporate interest. It's the reason that C++ can't elide semicolons after class definitions and Java can't remove deprecated APIs.

There isn't an obvious solution to this problem; the standards organizations we have are the best we are likely to get. But there is one example worth noting. Python, which doesn't have a standards organization, recently released Python 3.0, which breaks reverse compatibility and adds a whole slew of features. Yes, it's painful to many developers, but they will recover, and when they do, Python will be a better language for the struggle. Obviously this isn't a tenable solution for web standards, but for programming languages in general, the solution may be to *let the language designers design the language*. After all, if there isn't a standard, it can't be polluted by corporate interest.


  1. Killer blog name!

    If a collection of developers were to write a competing CSS standard, possibly it could take hold. I'm not quite sure how I feel about that.

  2. First a minor correction: it's "deprecated APIs" not "depreciated APIs" :)

    Second, I have recently blogged about this

    The problem as I see it is that CSS isn't designed to solve common use cases. Or rather the standards the W3C come up with aren't sanity-checked against common use cases.

    Stacking the deck with corporate interests is a plausible theory but, as the saying goes, when faced with the choice of incompetence or conspiracy, choose incompetence every time.

    Just look around at the "pure CSS" "semantic markup" zealots (arguably puritans) out there. I think the problem with the CSS standards process is that too many Ivory Tower academic types are at the helm. And to that crowd, usability in a practial sense is anathema.

  3. William, I've made the correction.

  4. I couldn't disagree with your central thesis more. With one simple exception (the lack of a proper layout module, as Guido pointed out), current iterations of HTML and CSS are extremely adept at common tasks; the problem lies with getting these techniques to work on legacy platforms that you and/or your clients need to care about. Taking on your example: it is extraordinarily easy to create a horizontal menu bar as you described:

    <li>Cell 1<br />Cell 1</li>
    <li>Cell 2</li>
    <li>Cell 3</li>
    <li>Cell 4</li>

    Add a link, subtract a link, the cells expand to fit the width of the <ul> just fine. They even expand to the height of the multiple-line item in cell 1, acting exactly like a table. All this without sacrificing the semantic markup that standardistas have been preaching since Zeldman's book opened that particular can of worms. Why can't display:table be used on most sites? IE6 and 7.

    The lack of a proper layout module is another beast entirely. I actually took browser makers to task for this at the CSS3 panel at SxSWi 09. As I mentioned, using floats for layout is a hack at best. It's certainly better than anything else in the toolkit today, but it's one area that can certainly be improved upon. There are a number of advanced layout module proposals out there, all of which are under consideration by the W3C.

    It has taken a long time to get this discussion off the ground, but I don't blame the W3C for taking it slowly. Thanks to the slow browser release and adoption cycles (as demonstrated by the substantial market share IE6 still has), they really only have one chance to get it right.

    So it's back to the browsers again.

    However, let's not sell them short; they've made many innovations that are essential pieces of the current front-end developer's toolkit. For example, XMLHttpRequest was originally an IE property that found its way into W3C standards. Now that there are proper ways to do so (-browser- prefix to experimental CSS rules, etc), browser makers actually have a say in the future of standards and have been using these tools to innovate. Some current drafts that have been spearheaded by browser manufacturers:


    My own thesis: the W3C has historically been slow to adapt to the changing web landscape, but it's absolutely unfair to blame them for browsers' historical sluggish to correctly implement standards that have been in place for years. However, things have changed for the better over the last few years, and the future is looking bright. Standards bodies are not only working closely with browser makers, but the latter have become actively involved (see Håkon Wium Lie, David Baron, Sylvain Galineau, etc) in discussion surrounding new standards and used properly namespaced channels to innovate where they see fit.

  5. Thanks for posting instead of tweeting back. My main issues were (a) the religious feeling of the debate, (b) the awkwardness of some CSS solutions, requiring the combination of many advanced settings and (oh horror) absolute dimensions.

  6. There are two schools of thought about forward compatibility in programming languages: Some (usually those who have a major investment in existing code) think it is a necessity, while others (usually those promoting keen new features that would break existing programs) see it as a nuisance and impediment to progress. You have trotted out the same old arguments for the latter side. But you go a bit far in characterizing standards, which exist precisely to promote compatibility, as "corrupted by corporate interests."

  7. The funny thing is though, the same people are often found arguing both camps.

  8. Python, which doesn't have a standards organization, recently released Python 3.0, which breaks reverse compatibility and adds a whole slew of features. Yes, it's painful to many developers, but they will recover, and when they do, Python will be a better language for the struggle.

    100% of the organizations I know are going to stick with Python 2.X. Even Google is working on unladen-swallow. I don't think that the 3.0 version of Python is a good example of how good it's to break backward compatibility.