The COI have recently published a draft of their browser guidelines for anyone developing a public sector website.

Frankly, I’m very unimpressed; they’re dangerous, vague in certain areas and over-specific in others, and promote some terrible ideas. I’d urge any designer or developer with an interest in this area to download the document and read it – it’s really not very long – and then leave feedback on the document with the COI through the appropriate form. The public have been asked for responses, and we have the scope to respond; if you feel as strongly about what’s in the document as I do, I hope that you will.

My own response follows.

As a web development professional, I’m very unimpressed with this consultation document, and would go as far as to suggest that some elements of it are actively harmful.

I appreciate the attempt to codify the need for effective browser-compatibility for all public sector websites. That said, the manner in which the document suggests which browsers to test is very poor.

All browsers are different, even though the HTML and XHTML specs remain the same. The purpose of browser-testing is not to ensure that sites look identical in all browsers; the purpose is to ensure that the site is usable in all browsers.

As such, lists of browsers to be tested in are dangerous; the best we can aspire to is to write good, valid code that is functional in all browsers, and priortise appearance for the most modern browsers.

I take exception to the notion that the browsers to be tested on are those which have >2% share of visits on a website. 2% of hits on a very popular public-sector website might account for a sizeable proportion of users, and to exclude them (especially if the lack of testing in their browsers leads to impared functionality) could well contravene the Disabilities Discrimination Act. Also, note that these statistics are not necessarily accurate, and may contain spoofed or inaccurate user data.

Going beyond the 2% hurdle, it would not be feasible to test in all browsers. The best solution is probably a form of graded browser support, much as Yahoo recommends, which itself is reviewed and updated over time, and which guarantees a minimum functionality in certain families of browsers, full support in others, and makes it clear which browsers simply are not supported. Browsers do not cost money; they are not complex tools to install, and developers should not be limited simply because a certain percentage of users on their website continue to user Internet Explorer 5.

Browser support should not be a series of boxes to check off, and it should not be specified retroactively based upon current users; it should be based upon accurate specifications and usage patterns, to ensure that public sector websites – many of which already have high production costs – are sustainable, maintainable, and functional for years to come.

As such, this preliminary draft has a long way to go before it accurately represents the state of web usage, not to mention web development, in 2008.

Time to announce my first published Rails plugin: ie-specific. And, more importantly, time to explain it.

I work as a front-end developer for a large scientific publishing firm. We’re very much committed to standards compliance and accessibility, as such, make every effort to ensure our sites work in as many browsers as possible. And that includes Internet Explorer 5.

Now, prior to IE7, we did this (by and large) by producing standards-compliant stylesheets, and then adding browser hacks where they were the only solution, in order to achieve consistent look/feel in many browsers. Fast forward to IE7, and we’ve now got a problem: many browser hacks (notably * html) no longer work in IE7 and yet it still has its own raft of styling quirks.

So we’ve decided to change the way we implement browser-hacking. On the project I’m currently working on, we now have a main.css which contains all the standards-compliant, “correct” CSS. We then place the IE-specific styles inside IE conditional comments. Each browser version gets a css file of its own where necessary, named for the name of the relevant IE conditional filter – eg, lte-ie-6.css, ie-6.css, lte-ie-5.500, etcetera.

When I started work on the front-end integration for this Rails project, it was clear that this was obviously something that could be automated in Ruby – and, given that we were probably going to use it again, it made sense to package it as a plugin so that the next time I came to need it for a project, a quick script/install would be enough.

Enter ie-specific, currently hosted at Google Code given that a) it’s open-source and b) it’s an easy way to get anonymous public svn.

It’s really simple. First, install the plugin:

script/plugin install http://ie-specific-rails-plugin.googlecode.com/svn/ie-specific

Now, place any IE-specific stylesheets into #{RAILS_ROOT}/public/stylesheets/ie_specific, named with the appropriate conditional filter (eg: lte-ie-6.css). Similarly, you can place IE-specific javascript into #{RAILS_ROOT}/public/javascripts/ie_specific. We use IE-specific Javascript to simulate min/max-width capabilities in Internet Explorer.

Finally, in the <head> of your layout, include the following ERb:

<%= ie_specific_styles_and_scripts %>

Each file in the ie_specific directories will be automatically included inside appropriate conditional comments – CSS files will be imported via an @import directive, and JS files will be appropriately escaped as CDATA (important for us, because we write XHTML 1.0 strict). There’s no unnecessary duplication, either – lte-ie-6.css and lte-ie-6.js will automatically be placed inside the same conditional comment.

That’s it, really – it’s very simple, but it’s also a convenient way to keep markup and styles clean and let other developers know exactly what’s a hack and what’s not. For more info, check out the README. And let me know what you think!