Web Development is a strange field. This is where, look to use a weary metaphor, herpes 1 + 2 will equal 3 today and 5 in six months (or other values based on which browser implements what). The specifications that browsers standardize on are in rapid and heavy development today, stomach and browsers outdo each other in the race to implement the specifications as quickly as possible. This means that, unlike in other fields, self-learning is mandatory.
What I find perplexing is how often we outsource this learning to others. Many developers do not use certain standards because well-known experts have not expressed an opinion on it. Sometimes, unstable features find popularity because experts have explicitly endorsed them.
More troubling is that very few people take the time to read what the specifications say. Even Google ranks Sitepoint’s Reference, and W3Schools’ website higher than the actual standards when searching for CSS/HTML properties (and for a beginner, it is hard to know that the former two websites have nothing to do with the official standards body.)
Browser vendors too have a vested interest which is not immediately obvious to us. Vendors introduce vendor-prefixes for their own benefit and a few of these prefixes get into the specifications. But many of us are not aware of which vendor-prefixes have been implemented because they feature in drafts of upcoming standards and which exist because they fulfill something unique for that browser. This sometimes leads to frustration with browsers that do not implement the popular vendor-prefixes of another browser.
There are several outcomes as a result of this:
- Unstable/undesirable features get used quickly, leaving browsers with backward compatibility issues.
- We are not aware of the full impact of our choices on our web development environment in the race to use the latest and greatest.
- Useful features of standards remain unnoticed for a long time, because very few developers hear about them.
- It takes a long time for the common feature requests among web developers to bubble up to the Standards body, as they are unaware they can raise suggestions to the W3C.
- Websites become harder to maintain because choosing to use specifications that have inconsistent implementations among browsers leads to more work (or sometimes such choices can make content inaccessible).
- Web developers develop superstitions about browser vendors and web standards that are hard to alter (e.g. the poor opinion about Internet Explorer means, even when IE attempts to do something well, the IE team receives brickbats).
- Browser vendors seem compelled to implement similar features as that of the competition because some web developers find it interesting, not because they are useful.
I think, given the pace of development of standards, web developers need to be more curious: investigate, and learn about standards to make it easier to apply and contribute to them (Ben Schwarz talks about it too in his presentation Take back the web). There are many ways to do it. The following have always worked for me:
- Code, code, code. There is no substitute for practice. Instead of trusting someone else to test a standard, do it yourself. Check if it works within the restrictions you have or the environment your website needs to work on. Some features are implemented such that they slow down the rendering of a page, and if your website requires high performance they will not be appropriate. Some only work with some special caveats. Know the caveats as there are very few free public resources mentioning them.
- Review upcoming standards. Not all properties are supported consistently across browsers. We should find the limitations, as well as equivalent substitutes for browsers that do not support them.
- Refer to the guidelines from W3C. It helps to actually read helpful documents the W3C has published for web developers (e.g. HTML: The Markup Language and HTML5 (Edition for Web Authors)), and ask the experts about content that is not clear. Most of them are happy to help (provided you show that you have done your homework and ask specific questions). Remember, the intent of any implementation is lost while reading a “simplified” version of it. For CSS, individual browser documentations are also useful.
- Subscribe to the W3C mailing lists. Browser representatives and people who implement the W3C specifications talk about edge-cases and debate on specifications here. In particular, www-style and public-html-comments are two lists where you can comment on the CSS or HTML specs respectively.
- Learn to love the bug-tracking systems for browsers. If a standard behaves inconsistently despite following the specification, you should check Bug trackers for Mozilla, Webkit, Chrome, and IE 9 to see if it is a known bug (IE has also released IE Standards Support Documents, that details IE support for various web standards).
- Read what other people are learning about. Paul Irish has a list of 200 front-end development feeds to subscribe to. If this gets in the way, cull the blogs you follow.
- Interact with other web developers. Go to your local Web Design meet-ups and do not feel afraid of asking questions that you think sound stupid, because, if you had that doubt, it is highly probable that someone else had that question too.
- Always ask why. Why is there border-radius? Why do we need HTML5 form elements? Why Canvas? Knowing what caused standards bodies to approve property/element is useful as it gives an insight into where they are most useful, how they can affect your web development process and what to look out for.
We are at the edge of yet another big push to what it means to develop with web standards. Instead of waiting for other people to tell us what is best and what is not, I think it is important we do that for ourselves. Be curious, be free!