A guest post by Craig Buckler who is a Director of OptimalWorks, a UK consultancy dedicated to building award-winning websites implementing standards, accessibility, SEO, and best-practice techniques and can also be found blogging over at Sitepoint.
Web developers work in a hostile environment. The humble browser has always posed a significant challenge and, at the dawn of the web, vendors launched new applications every few months. HTML was little more than a concept: there were few rules and no strict specifications. Web pages may have been simple but cross-browser support was difficult. Do you remember the irritating “best viewed with…” statements?
By the late 1990’s two browsers reigned supreme: Internet Explorer and Netscape Navigator. Innovation accelerated as both attempted to out-do the other with long-forgotten features such as Dynamic HTML, layers, and channels. We were caught in the cross-fire and creating pages which worked in both browsers was fraught with difficulties. It may seem inelegant now, but frames, table-based layouts and spacer GIFs were the most viable solutions.
JavaScript development was notoriously complicated. Vendors implemented radically different HTML manipulation methods so it was necessary to detect the browser and write two or more versions of the same code. Many of us kept client-side coding to a minimum. Others berated the language and let server-side technologies take the processing strain.
Fortunately, the W3C specifications for HTML 4.01, CSS2 and the Document Object Model were agreed by the end of the century. Microsoft adopted many of the new standards and Internet Explorer 6.0 became the most compliant browser. Developers loved it (yes, seriously) and the browser’s market share peaked at 95% in 2003. Like many, I was guilty of ignoring W3C standards. It didn’t matter if a feature was implemented using older or proprietary techniques: IE6 was the standard.
Web standards bite back
IE’s 95% market share could only go one way. Mozilla released Firefox in late 2004 and the browser party was soon joined by IE7, IE8, Chrome, Safari and a free version of Opera. IE6 is showing its age but retains a significant market share because other browsers do not support non-standard techniques used in older web applications.
If you’re still using browser detection to deliver different code for different devices, it’s time to stop! There are five main desktop browsers, numerous mobile applications and multiple editions of each. They all offer a differing level of standards support and proprietary technologies which may or may not be accepted by the W3C.
The ultimate goal is to support all browsers using the same mark-up. There are three steps to success:
1. It’s not a spot-the-difference competition
No two browsers are the same. You cannot expect a 10 year-old application to render the same way as a modern browser. Similar functionality is possible but you’ll rarely achieve the same cosmetic effects. Embrace the differences.
2. Use the same mark-up
Adhere to W3C standards and deliver the same code to all devices.
Many developers use conditional style sheets to solve IE6 and 7 rendering differences. I don’t like the practice: it feels too close to browser detection. I might add an additional property to fix an IE6 problem but, to this day, I’ve never used conditional CSS for complex layouts. I won’t say you’ll never need them, but I’d recommend fixing the problems rather than working around them.
3. Adopt progressive enhancement and fallback techniques
It’s possible to build a basic web site or application which works everywhere. A browser may not support stylesheets or scripting, but content and functionality can still be delivered. The core application can then be enhanced:
- CSS effects can be added which appear when the browser supports those properties. Older devices may not display all effects but the layout remains similar.
- JavaScript and DOM implementations may differ but shims and object detection can paper over the cracks and inconsistencies. For example, you can detect the XMLHttpRequest object before implementing Ajax functionality.
- Fallback techniques can be used when a technology isn’t supported, e.g. provide a static bitmap image when SVG graphics cannot be used.
The road to HTML5
HTML 4.01 and XHTML 1.0 are 10 year-old standards. Code forking is less necessary, but web applications must still resort to object detection and Flash/Silverlight plug-ins to add audio, video, fonts, vector graphics, and other modern facilities.
HTML5 aims to resolve these issues and provide excellent native functionality within the browser. In addition, the five primary vendors are working together and backing the same standard. It raises exciting prospects for web developers:
- there will be less reliance on browser plug-ins
- all modern browsers will offer a similar level of core functionality
- with the release of IE9, reliable cross-browser development will finally become a reality
HTML5 is a new dawn for the web: it’s the one mark-up you need.
