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 getElementsByClassName() method and the Selectors API solved the problem of developers wanting to query the DOM by CSS classes and use CSS queries – both were already ubiquitous amongst JavaScript libraries. The Cross-Document Messaging API solved the problem of secure cross-frame communication where otherwise developers were using multiple embedded iframes just to pass data back and forth. ECMAScript 5 finally introduced the official way to assign getter and setters as well as controlling property enumerability. All of these were problems of today that were well understood and fairly quickly turned into officially supported APIs.
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:
- Cookie reading/writing in JavaScript – Netscape gave us
document.cookie. It hasn’t changed at all since then, meaning anytime anyone wants to read from or write to a cookie, they must do all of the string formatting themselves. We’ve been writing JavaScript cookie libraries for the past 15 years and we still need them because the API never changed to reflect what we’re actually doing. This is a glaring failure in the evolution of the web. - JavaScript string formatting – we’ve known for a decade that we need to be able to escape text for HTML and regular expressions, and that we have a need for general string formatting similar to
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, anhtmlEscape()method would be a great start, or implementString.format(). Something sane. - JavaScript date formatting – once again, a problem that has existed for over a decade. Why can’t I easily do date formatting in JavaScript? Java has had this capability for a while, and it’s not horrible. Why are we stuck still writing date formatting libraries?
- Common UI paradigms – this one really bugs me. For the past decade, we’ve all been writing a ton of JavaScript to make the best UI controls. The controls have become ubiquitous in JavaScript libraries and often require a ton of code to make them work correctly. Why aren’t there HTML tags that allow me to create these common UI paradigms:
- Tabs – how many more times do we need to create JavaScript for a tabset? There are even ARIA roles to markup HTML to be tabs, why can’t we have some tags whose default behavior is to use those roles? I am very tired of creating ever-newer versions of tabs.
- 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?
- JavaScript touch events – even though touchscreen technology is relatively new, there quickly emerged some common patterns that would be nice to have standardized. Why do I need to decipher multiple
touchevents to figure out what the user is doing? Why aren’t there events forswipe,flick,tap, andpinch? I don’t want to need a PhD in computer science to be able to program for the touch-enabled web.
Conclusion
I’m all for moving forward, and don’t get me wrong, both TC-39 and the W3C have done a commendable job at solving many of today’s problems. I’d just like to see more addressed so that we can stop solving the same problems repeatedly over the next decade. In another ten years, I don’t want to be writing JavaScript to parse a cookie string, and I don’t want to be debating the best way to create a tab control. These are all known problems that deserve attention now so that we can move on to solving more interesting problems in the future.
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.
11 Comments
Great list. More on String & RegularExpressions – I would really really like fully Unicode support. That means – full UTF-16 support with Surrogates, Normalization, Collation and Character Properties baked in the language.
Ram Viswanadha on October 3rd, 2011 at 4:04 pm
For cookies there is this
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025300.html
https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
I think Adam got busy with other work so nothing really happened to it.
Erik Arvidsson on October 3rd, 2011 at 7:20 pm
Have you looked at toStaticHTML?
I think the problem is that it is really hard to get it right: even the browser vendors don’t know how to sanitize
. (toStaticHTML has been found to have bugs)
anonymouse on October 3rd, 2011 at 9:04 pm
I would also add in regards to touch events that we need an actual standardized (and implemented) touch event mechanism. Various tablet devices seem to have varying implementations, and glaringly the new Metro IE10 implementation is using some MS-prefixed system that is different compared to other tablet/touch devices. We need a standardized implementation so that we can create useful sites without a bunch of code branching.
Randy Peterman on October 3rd, 2011 at 9:24 pm
Spot on with the problems of today, but I would disagree with your suggestion for UI controls:
1) These things do not necessarily fit well on every device the current web now runs on (not to mention the future).
2) Popular UI styles seem to move faster than standards and implementations.
Steven on October 3rd, 2011 at 10:21 pm
So some questions:
– you’re worried about the lack of focus. I am too. Do you support my proposed splitting of the W3C? http://infrequently.org/2011/09/things-the-w3c-should-stop-doing/
– the common UI idioms thing often gets held up by folks who want semantics and not UI. How do you suggest we press the *process of progress* against that sort of resistance? (I’ve got ideas but I want to hear yours)
– as for TC39, not a ton of folks on the committee write lots of JS, and the interested community members tend not to be library authors. You get the committee you allow to serve.
Alex Russell on October 4th, 2011 at 7:48 am
I’ll love that all the scripts have a reference to its tag something like window.currentScript; since using the async mode mess up with the document.write and sometimes we need to append elements right next to the script tag , the way to solve it is using a id but if you are loading multiple times the script complicate things
alejandro on October 4th, 2011 at 8:57 am
Hi Nicholas,
Completely agree with you. The standard committee is very slow and instead of solving the problems of today and tomorrow they are following what creative web developers had done. For example, getElementsByClassName and querySelectorAll were created by library developers in order to suit their needs because the committee did not see that coming. Now they are part of the standards but after several years waiting for them. In addition, if we wait for new features to be standardized or in recommendation we would still in the year 2000. We need a faster committee that do not try to oversee the future and start solving common problems that we see today.
Lastly, why they did not include to the standards those UI elements that you mentioned (even a simple lightbox should be included imo)? If we are trying to emulate desktop application on the web since 2005, why not to add all those UI elements to the standards right now?
Thank you!
Teylor Feliz on October 4th, 2011 at 9:09 am
@Erik – Yup, I’ve seen that. I also saw when it was proposed to the WHAT-WG and unceremoniously dismissed (I also provided feedback on it). I like the proposal!
@Anonymouse – Yes, I’ve seen that. I think it’s a decent first attempt but tries to do too much, which is where bugs get introduced. Simple HTML escaping where web developers could do their own sanitization would work better, IMHO.
@Steven – Mobile devices are a reason to try to make the UI paradigms work, not to avoid them. I’ve seen all of these on mobile sites and they seem to work fine. I’m not saying there is zero work involved in creating these controls, just that the work should be centralized instead of distributed.
@Alex – Yes, I agree with you on the W3C. There is a time and a place for academic pursuits, but not at the expense of moving the real web forward. With regards to UI controls – ARIA can already provide semantics for most of these controls, and all browsers now support ARIA, meaning that they can communicate the UI really well. We’re actually at a point where screen reader users get better semantics than sighted users, which seems silly. These things may not be “document-like”, but I’d argue that it’s far more important to be able to state definitively what something represents than it is to worry about whether this thing would appear in a book. The semantics are mostly already there through ARIA, we just need to have them applied natively. For TC39, I understand that it’s mostly academics, but it seems like they should be augmented by a rotating invited-expert panel comprised of real web developers writing real web application (okay, and maybe some Node.js developers).
Nicholas C. Zakas on October 4th, 2011 at 11:14 am
You’re right, of course… and one can think of any number of other features which would be nice to have in HTML and JavaScript. Of course, the larger problem is not what isn’t being added into new releases of these things: it’s that none of the new additions are useful in the real world, yet, and they won’t be for quite some time to come. Why is this? It’s because the user base, i.e. the whole world, cannot be relied upon to be using browsers which can cope with them. It’s only now, really, that we can be almost completely sure that our users are not going to be using IE4, for example; in other words, it’s only when we can be reasonably sure that our users’ browsers are going to be able to cope with the new features that we can actually start using them for real applications. Intranets are, of course, a different story, although most Fortune-500 companies tend to be very slow about adopting new technologies, simply because each new release of a thing has to be shown to work with all their existing software, most of which will be home-grown and is unlikely to be particularly tolerant. I shouldn’t think HTML 5 will become the standard choice for most website developers for at least another five years. This, in itself, presents a problem because it implies that the standards we use for development refer in reality to an environment which is already obsolete by the time it becomes acceptable for use. Much more than this need not really be said, but the implications are interesting, to say the least.
Dan Suton on October 5th, 2011 at 10:05 am
RegExp.escape is another small thing that should have happened a long time ago.
Tgr on October 6th, 2011 at 10:45 pm
Comments are automatically closed after 14 days.