HTML5 was becoming much harder to ignore in 2011, but using it on client websites still needed some judgement. It was tempting to treat every new element or input type as an automatic improvement, but real projects had older browsers, varied devices and clients who expected the website to work for their actual audience.
I liked the direction HTML5 was taking because it gave better meaning to page structure. Elements like header, nav, section and article made the document feel closer to how the page was actually organised. The problem was making sure those improvements did not break the experience for browsers that were behind the curve.
That made HTML5 less of a switch and more of a gradual adoption process. I wanted to use the parts that improved the project, but I also wanted sensible fallbacks where browser support was uneven.
Using New Elements For Better Structure
The semantic elements were the easiest place to start. They made templates easier to read and gave the markup more meaning. A navigation area could be marked as navigation, an article could be marked as an article and the overall structure of the page became less dependent on anonymous divs.
That mattered during maintenance. When I came back to a template later, I could understand the intent more quickly. It also encouraged cleaner thinking about the page itself.
Forms Needed More Caution
HTML5 form features were useful, but they needed more careful handling. New input types, placeholders and validation behaviours could improve the experience where supported, but browsers did not all behave the same way. I did not want a form to depend entirely on a browser feature that might be missing or inconsistent.
My approach was to treat HTML5 form features as enhancements. The server still needed to validate input properly. Labels still needed to be clear. The form still needed to work if the browser ignored a newer input type.
Fallbacks Were Part Of The Build
A lot of the work around HTML5 came down to fallbacks. Older Internet Explorer versions needed help recognising new elements for styling. Some behaviours needed JavaScript support. Some features were better avoided if the fallback created more complexity than the feature was worth.
That is where progressive enhancement made sense. Start with a working page, then improve the experience where the browser supports it. The best HTML5 work in 2011 was not about using every new feature, it was about choosing the parts that made the site clearer, more usable and easier to maintain.