I was perusing the twitters today, as I do, and came across a tweet about the twitter bootstrap framework and it's support (or lack of) for Microsoft's internet explorer. This got me wanting to write this post but there's also another reason why I'm about to blabber on about support (which I hope you'll read).
If you've followed me on twitter or we've spoken, you'll know that I'm 'giving up' client work until January 2013 so I can re-adress where I want to be, what I want to do and by when I want to get thing s rolling.
Hopefully in January 2013 I'll have a new version of this site with more 'about me/hire me' shizzle to 'drum up some trade', a new design of RWDCalc will be out, I hope to have something happening with deCSSor and all will be good.
On my process to get there I think it'd be a good idea to document some bits on the way. I guess this'll be the first one.
I digress (I do that)
So, browsers & the support thereof. Weekly? Daily? Hourly or at least sometimes I see conversations regarding browser support and phrases like 'we don't support IE7 but support IE8 and up' or similar. At face value such a phrase doesn't mean anything (I feel).
You don't support IE7 so they just get a blank page?
If so, that's ridiculous.
If you code sites correctly there's a chance that it'll be useabe in quite a few browsers and there in lies the need for clarification of the word 'support'.
If you stipulate what browsers you 'support' you need to define that level of 'support'. Pixel perfection? It'll look a little different but it'll work the same? There'll be a couple of sections that won't work for a certain browser but you do this to rectify it and so on.
As we know the answer to "Do websites need to look exactly the same in every browser?" the interaction doesn't have to be the exactly same either, does it. If I'm supporting mobileSafari and Opera mini do I have to have a flyout menu for both browsers? I'd say no. As Opera mini is a proxy browser and is tied down with what JS can be done with it perhaps give Opera mini a nav at the bottom of the 'page' or just under the heading instead of something that'd rely on JS that'd reload the page.
Of course, with all things, I'd say this is project dependant too. I don't think you can be so cut and dry to your clients and there users to say "I don't support browser X" especially if current usage is browser X. You should define the support you'd provide to that browser and it's users for the specific client.
If you're finding yourself required to support older browsers that'll take 'a while' to get working as needed then charge accordingly. Something like a "I support browsers X, Y and Z anything else is to be negotiated and quoted before the contract is signed and agreed upon".
So you're saying support IE6
No, I'm just saying decide what browsers you are going to support and define the level of support for those devices as a base to start with and adapt for each client and their respective requirements.
My level of support?
This is currently undecided, but I'd could probably say for certain that it'd be from IE8 and up, the latest Chrome/Safari/Firefox/Opera browsers on 'desktop' and then the browsers found on 'mobile devices' to be confirmed and part of me blathering on here is for me to start thinking about it. So, in January I'll hopefully know.