It wasn’t until the recent flurry of the guardfather of web standards, Jeffrey Zeldman, and his posts about HTML 5 (see: In Defense of Web Developers, HTML 5 Nav Ambiguity, HTML 5 Is A Mess, and so forth) that I began looking into HTML 5. I’m busy being pragmatic with my code today and making tough choices about browser support and figuring out how I can make HTML 4.01 work consistently in those browsers that I do support. But with the promise of change coming I need to be on the hunt for details rather than waiting for the browsers to fully implement the spec. If we wait for browsers to fully implement specs it could very well be after I’m out of the web development industry before they’re implemented. I wish that last line were a funny joke, but sadly 100% implementation is not likely in the next few years because the spec isn’t complete. The reason that the spec isn’t complete is because people on both sides of a bunch of arguments have been making assumptions. Lets take a look at those assumptions, shall we?
Assumption 1: The Needs of the Web Are or Are Not Going To Be The Same in ‘N’ Years
I love this assumption either direction you take it. Its awesome if it stays the same because then we can clean up our markup so that WordPress 4.0 (or your blogging platform of choice) can have 16 elements repeated over and over. We won’t have table nesting issues, we won’t have DIV-itis, we’ll have semantically pure documents. Or not. Because as long as we’re using the Sliding Door technique or any number of other hacks to get markup to map to CSS (note: the spec will change for this technology, too) we’ll be polluting the DOM. Also, if the web will change: how will it change? Assuming that we can create “The Perfect” markup language in HTML 5 is naive at best and possibly stupid at worst. What did we need in HTML, JavaScript and CSS before the iPhone, Table PCs and the user interface in “Minority Report”? Assuming that the human interface to data on the web and elsewhere will remain stagnant is flawed horribly. If we ever get HTML 5 out the door, we’ll get HTML 6 out the door some decades after that (or HTML will die and we’ll move to some other markup format). What if we’re closer to Matrix-like data input than we think and you stop taking in the web through what you consider a browser?
Assumption 2: We Need More or Less Markup Elements
There are great arguments for newer or different markup elements. There are great arguments for using the old ones and just styling them with CSS. There are great arguments but many of them have, on some core level, more assumptions. Arguments for newer elements are valid for present web contents if you are looking for semantic markup. If you take the negative view (and assumption) that there will be no really powerful algorithm in your lifetime that can really, truly process semantic markup then this is a voided argument and you move on. The assumption and expectation trumps the ideal nature of semantic markup. You will make no headway here. If you assume that semantic markup will lead to better programs to parse the data then what you’re really looking for is XML + some sort of namespace and doctype information that will help computers parse the data beyond what the browser is doing. Microformats help in this area, but are not complete enough to make all documents data fully parsable. Also, if you’re talking about web standards I should not that data synchronization standards are diverse and incomplete in most implementations as well.
We may need less markup if we can style the div and span elements however we want. Or so you may think. That sort of thinking is based on the assumption that all markup is basically the same with different styling. An oversimplification for sure, but I’ve found that oversimplification makes life easier, and so myself and others are often caught doing it here, there, or in other places we don’t talk about in polite company. Its the Internet, so we do it publicly, but on sites that anonymize our usage, of course. Hacks make Internet Explorer bugs more bearable, Firefox bugs less annoying, Opera work like every other browser, and Safari and Chrome like Internet Explorer (or not).
The Rise of the Pragmatist
I like to fancy myself a pragmatist. It doesn’t buy me anything, but I can pretend that I’m practical, which is nice when someone asks you to do something and you don’t have an unlimited amount of time or money. I don’t have time to wait for all of HTML 5 to be implemented. I don’t have time for the web to catch up with desktop software of the 80’s and 90’s that had option/select/text entry elements that allowed the user to input any type of text, but also choose from some pre-populated options. I don’t have time for the web to allow my DIV-itis to look much prettier when presented in a hierarchical tree-like structure. I need markup that works now. HTML 5 will be a step in the right direction, but it will be slowly implemented in ways we don’t know yet and we’ll see what happens. If the Canvas element replaces Adobe Flash and SVG replaces VML: I’ll cheer. If I don’t ever get to use either of those elements or technologies because the implementers of those technologies never get off their collective backsides within the walls of various browser vendors then I’ll be practical about what I do. I’m going to make several assumptions about the future – as the above statements reveal. I believe that the web will change through JavaScript and CSS libraries and hacks. I believe that HTML standards will come, and I think that just like HTML 3, HTML 4 will one day be old. I’m going to assume that practical software development is all about satisfying the demands of your boss, your client, or yourself with what you can do now.
But you wouldn’t be a pragmatist if you didn’t also believe that you could practically bring about resolution and change for HTML 5, HTML 6 or HTML 7. Practical change. Good change. The things you discover you needed from HTML 5 that its purveyors could not foresee. Keep pushing for better web standards, but don’t keep fighting for better web standards. The fighting causes delay, the fighting isn’t pragmatic, and the fighting doesn’t clean up the web, it worsens it. Data wants to be free, do your part to continue to free it. I’m going to start by reading through the proposed HTML 5 specs to see what I’ll be up against in Internet Explorer 9.5 – whenever that comes out.