It has only taken about 20 years, but HTML development is starting to not be completely hair-pulling frustrating. It’s good to see clients finally dropping the “must support IE 8” requirement and forging ahead with modern browsers. If you are just building mass market content sites, supporting older browsers might make sense, but if you are building modern web applications and experiences (like we do) it’s a breath of fresh air.
While you can do nearly anything in IE 8 as you can in current browsers, it essentially doubles the work. Cutting support for legacy browsers also makes financial sense for a lot of projects. On our own public site, IE < 9 accounted for 2% of all our traffic. Today only people using legacy browsers (or IE at all, really) are those people who a) don’t know any better or b) are working in a hugely bureaucratic company that doesn’t care about security or progressive technology. Either way, they are probably not a customer for the things we build, so it’s probably not worth our time catering to people who don’t need our services.
Now, anyone who has been doing web dev for any length of time knows that IE 9 will soon be ‘the new IE 8’. In fact it sort of already is, since there’s still a gap between the capabilities of current browsers and IE 9. But the good news is that most structural things work fine in 9, and there’s usually simple graceful fallbacks to it. Things like CSS transitions don’t work at all, but for a lot of apps they aren’t necessary to function.
Because of the confusing browser landscape, people are still trying to figure out what this HTML 5 thing is. Until recently it was hard to even use that term with a straight face since there was such a difference in support amongst browsers, and actual browser support forms the de-facto standard developers actually care about. Even with better adherence to standards, there are still some frustrating HTML-isms that may make sense from a historial print-layout context but not from a GUI-development standpoint. Why must the first child’s margin affect the margin of it’s parent? Why must a container lose its height if all its children float? Why is it still too hard to make completely fluid layouts? Getting all of those things at least acting consistently is a huge leap forward, and HTML 5 has more options (hurray for for border-box and table-cell, boo on inline-block for still being a tease). Still some of those choices can be frustrating.
One of the main things that has made our lives easier is starting with a consistent base line for all of our projects. If you aren’t using tools like HTML5 Boilerplate you are making your life harder. Pulling in some well-tested frameworks can smooth over a lot of the rough edges, even if you aren’t sure what they all are at the start of a project. To this end, put together a base-line project skeleton with some libraries that we consider to be default ,and there’s not much reason to NOT include them in every project.
The things we are using in every web project these days:
- HTML5 Boilerplate – just use it, if nothing else just for the CSS defaults
- jQuery – I hear good things about this up-and-coming library!
- jQueryUI – Less essential and a little bloaty, but we usually end up reaching for it anyways
- Underscore.js and Underscore.string – more generally useful libraries you miss when you don’t have them
- Touch Punch – Its a crime that in 2013 that jQueryUI doesn’t ‘just work’ with touch devices, but this takes care of it
