When web standards fail us
From time to time, web developers rise up and grumble more loudly about the failings of the W3C and ECMA for the ways they choose to evolve (or not evolve) the technologies of the web. We talk about design by committee as a failure, browser vendors should just implement and not worry about it…unless it’s Microsoft, they should never do anything without asking someone else first…and whether or not there is a better, faster way to create change. I’m actually less concerned about organizational structure than I am about these groups’ lack of focus.
The big problem
I have a bias when it comes to problem solving: once a problem is solved, I don’t want to have to solve it again. When the problem is well-defined and the solution is understood and accepted, I want that to be the solution and move on to solving newer problems.
Each web standard committee has a single job, and that is to solve problems in their focus area. The committees seem to have trouble defining the problems they want to solve. To be fair, fully defining a problem is often the most complicated part of solving it. However, there are two sets of problems to select from and there are many problems that have yet to be addressed despite years of history.
Design for today, design for tomorrow
From speaking with various people who work on web standards, there are basically two types of problems they attempt to solve: the problems of today and the problems of tomorrow. The problems of today are known entities. The entire problem context is well known and developer-created solutions already exist. The problems of tomorrow are a bit more esoteric. These problems may not have yet been encountered by developers but the standards want to provide for their eventuality.
To be certain, both problem sets deserve their due time and diligence, and everything from HTML5 to ECMAScript 5 solves some problems of today while also addressing some problems of tomorrow. The
The problems of tomorrow are often centered around doing things on the web that aren’t yet being done. I like to call this to Photoshop-on-the-web problem. It goes something like this: given that I someday want to write Photoshop as a web application, what would I need to make that happen? First, I would need some way to manipulate pixel data directly (solved by canvas). Then, I would need some way to crunch a lot of data without freezing the browser UI (solved by web workers). Of course, I would need to be able to read files directly from the desktop (solved by the File API).
You may be saying at this point, “but I do want to do that now!” That’s fine, but these APIs came about before today. It’s inevitable that some problems of tomorrow will become problems of today, but some may not. Do we really need databases in the browser, or are simple key-value stores enough? Only the future will tell.
Unsolved problems of today
As I said, it’s definitely important to spend time both solving problems of today and looking forward at potential future problems that will trip people up. What I absolutely can’t stand is the way web standards committees frequently overlook problems of today in favor of spending time on problems of tomorrow. If a problem is well-defined and affecting a large number of developers, let’s solve that problem so no one ever has to re-solve it. There are a lot of problems that we’ve been dealing with a for long time and no one seems interested in addressing them. To me, this is the biggest failing of web standards: failure to allow developers to move on to more interesting problems.
Here’s a list of current problems that are not yet solved:
sprintf(). Why is this not a solved problem? Why do we each have to rewrite such functionality over and over again? The next version of ECMAScript will apparently have a feature called quasis that tries to solve all problems using the same (new) syntax. I really don’t like this because there’s no backwards compatibility for what is a set of solved problems in the world of computer science. We’re not breaking new ground here, an
htmlEscape()method would be a great start, or implement
String.format(). Something sane.
- Carousels – a very popular control that is little more than a
<marquee>tag that stops and starts periodically based on user interaction. There are few sites you can go to that won’t have at least one carousel on the page. And having written a few, it’s always a pain. Why can’t this just be part of HTML?
- Accordions – nothing magical here. Very close to the HTML5
<details>element behavior. Why can’t I have this natively?
- Trees – another decade-long invention that we’ve still not standardized. In fact, my second-ever published article was about creating an expandable tree…that was in 2002. ARIA also has roles to represent trees, so why not have an HTML-native version?
touchevents to figure out what the user is doing? Why aren’t there events for
pinch? I don’t want to need a PhD in computer science to be able to program for the touch-enabled web.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.