This past weekend, I spent some time reading Mark Pilgrim’s e-book Dive Into HTML5 which not only is an excellent resource for understanding the changes to HTML5, but also does a very good job of explaining HTML from its beginnings, to where it is now, to what may be in its future. I don’t intend to discuss the specifics of new HTML5 functionality in this post (although it is both promising and exciting), but instead to relate one of the early principles of HTML’s development to something that I see every day as one working on the fringes of a very quickly-moving IT industry.
What I found most intriguing in Pilgrim’s e-book was his first chapter titled “How Did We Get Here?“, a quick history lesson on HTML and its early authors. At one point, Pilgrim quotes some of the worldwide web forefathers; for example, a mail list conversation between Marc Andreessen and some other developers of early browsers on a proposal for a new “img” tag, which would instruct the browser to show an image in the webpage – at that time a radical change. This example is used to demonstrate the rather unassuming way that HTML came to be what it is today.
A lot of us – myself included – take for granted that HTML is a very forgiving and flexible language, assuming that it works just because it works… because that’s the way it was designed. Those of us who work with HTML on a part-time basis probably have never felt the need to challenge this assumption. I must confess; previously my best guess at how HTML5 and previous versions were spec’d, designed, and implemented involved a group of briefcase-toting technology gurus from around the world gathered at a conference table over the course of a week or two, hammering out what they felt were the best ideas for the future of the web, and then shipping them off to browser authors like Mozilla, Microsoft, Opera, etc.
But that’s not exactly how it happens. Pilgrim does a great job of explaining that HTML standards and specs are developed out of a dynamic tension between specifications and implementations. In other words, this scalable, flexible, simple, and powerful markup language wasn’t just carefully thought and planned before implementation (although certainly thought and planning were involved), nor was it just an end-result of how early browsers decided to handle HTML and how web authors adapted to those browsers’ behaviors. Here I quote Pilgrim: “The ones that win are the ones that ship.” My original idea of the technocrat elite conferring and then mandating to the rest of the world how the web will work is a misconception.
After thinking about this for a bit, I realized that this same concept which led to the evolution of HTML can be applied to nearly every area of technology (well, successful technology at least). For example, here at IDM, we often introduce a new feature into one of our products with a certain plan or roadmap to fulfill, grow, or refine that feature over time. However, we strive to remain acutely aware of the user feedback on our initial implementation of that feature. That doesn’t mean we abandon all original planning or roadmapping for our software, but user feedback and expectations certainly have an important role in helping us revisit and refine original strategies. There is a delicate balancing process between our specifications and intentions, and our user’s expectations and adaptations. I think one of the hallmarks of a successful software developer or company is knowing how to properly handle and use this tension. Regardless of how technology changes – and my, does it certainly change rapidly and drastically – this idea will likely never change.
Back to the conversation between Mosaic author Marc Andreessen and other browser developers on that “img” tag idea back in the early 90s… Looking back from the year 2011, the situation is almost humorous: several browser developers floating around ideas for embedding images on web pages, followed by the seemingly quick decision of one (Andreessen) to go in a certain direction with his browser. Said Andreessen: “We’re not prepared to support INCLUDE/EMBED at this point…So we’re probably going to go with <IMG SRC=”url”>… For the time being, inlined images won’t be explicitly content-type’d; down the road, we plan to support that…”. Here we see a “temporary” shipping implementation which was intended to be expanded or even completely changed in the future, but instead became the standard for HTML image support and is now used by billions throughout the world today to show images on their web pages, simply because that was what first shipped. And guess what? It works, and the users are happy.
For many of you seasoned developers out there, this idea is likely nothing new. But for those of us who aren’t software developers or project managers, understanding this concept illuminates a lot about the success or failure of certain ideas or products.
I encourage you to check out Mark Pilgrim’s e-book here – it’s very interesting stuff.