You might remember that I published a post called UK government draft browser guidance is daft browser guidance last September, calling out a draft document outlining some UK government browser testing guidelines.
These suggested that for government web sites, webmasters need not test in less popular browsers (those with less than 2% in that site’s usage statistics) and that there should be a page on the site listing the popular browsers which had been tested with the message “We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above”.
I called on readers to email the consultation address and object that the guidelines did not advocate web standards and methodologies like progressive enhancement to ensure that all browsers were served. The Register carried the story, and two days after I made that call, the author of the guidelines, Adam Bailin, commented that over 400 people had already emailed him.
Last Friday, 16 January, Adam published the revised browser testing guidelines, and he’s done a great job of including best-practice development. The guidelines point to the BBC‘s support table as a good example of graded browser support, and notes the importance of supporting standards-compliant browsers (paragraphs 17-18):
Coding a site to web standards should ensure that any browser that supports web standards will render and behave as intended. Therefore your browser testing matrix must include browsers that support web standards.
You should follow a progressive enhancement approach to developing websites to ensure that content is accessible to the widest possible number of browsers.
The importance of valid code is noted (paragraphs 21-23):
All (X)HTML content must validate with respect to your chosen DTD.
You must use valid CSS for the presentational layer of your website including layout and styling. (X)HTML tables should only be used for presenting tables of data.
The guidelines now emphasise functionality over identical layout across browsers (paragraph 39):
You should check that the content, functionality and display all work as intended. There may be minor differences in the way that the website is displayed. The intent is not that it should be pixel perfect across browsers, but that a user of a particular browser does not notice anything appears wrong.
Graceful degradation without scripting/ plug-ins and accessibility are required (paragraphs 41-42)
You should also test your website to make sure that it works with scripting and plug-ins turned off.
Some users will be unable to use pointing devices so you should verify that the site works using a keyboard only.
I could be churlish and quibble about a couple of points in the document that I personally disagree with, but I won’t; the philosophical framework of the new Guidelines is a scalable, future-proof one that will properly serve taxpayers, web visitors and government webmasters in the UK.
I’d like to congratulate Adam Bailin and the team who revised the guidelines, and I’d like to congratulate every one of the 400+ readers who took the time and the trouble to write and support web standards.
It’s a job well done.
(Disclosure: I work for Opera, the browser vendor, and wrote the Opera consultation response).
- #1 On January 19th, 2009 8:02 am Matt Robin replied:
That’s terrific news that such an overwhelming response successfully led to an appropriate outcome! Well done to all involved.
There’s also quite a difference between ‘supporting most-popular browsers’ and ‘supporting standards-compliant browsers’.
[I remembered your earlier post Bruce, didn't comment on it at the time, and thought I was seeing a caching-error in my RSS feeds...."Oh no, the WaSP feed is broken," was my initial reaction, haha!]
- #2 On January 19th, 2009 5:47 pm Phil Houghton replied:
Wow, that’s an incredible result.
If only they listened to expert opinion on other matters!
- #3 On January 20th, 2009 7:47 am John replied:
We applaud all involved who contributed to this successful outcome.
- #4 On January 20th, 2009 9:28 am Jake Archibald replied:
The only part I’m not keen on is the “must” for valid CSS. The CSS spec is designed to handle invalid syntax and unrecognised properties and values (http://www.w3.org/TR/CSS21/syndata.html#parsing-errors).
If the CSS must be valid, you’d be unable to use “-moz-inline-box”, “zoom:1″, “filter:alpha(opacity=50)” etc etc.
Also, the guidelines do not state which version of CSS to validate against. As browsers adopt new rules, you’d be unable to use them unless they’re part of the spec you are validating against. As support improves, you may want to do something like:
background-color: rgb(127, 127, 127);
background-color: -ie-rgba(0, 0, 0, 0.5);
background-color: -whatever-rgba(0, 0, 0, 0.5);
background-color: rgba(0, 0, 0, 0.5);
But this standard would prevent it.
Personally, I’d do away with the need for valid CSS and replace it with a rule advising against CSS hacks.
The beauty of CSS is you can use invalid properties as safely as a valid property, as you know exactly how a compliant browser will handle it.
- #5 On January 20th, 2009 10:53 am WaSP Member blawson replied:
I agree Jake; in my experience, invalid CSS has no negative effect on a site. It could damage its maintainability, though.
Vendor prefixes are allowed, so it’s valid to use -x-whatever, see http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords
- #6 On January 20th, 2009 11:54 am Jake Archibald replied:
Fair point, didn’t realise the validator catered for vendor prefixes.
Still, as bad as things like the underscore hack are, I prefer them as they can sit alongside the “valid” rules rather than in seperate stylesheets inserted via conditional comments or similar.
Obviously every CSS ‘hack’ should be preceded by a comment explaining which browser is being targeted and why. Perhaps that should be the rule in the standard.
- #7 On January 22nd, 2009 1:01 am pd replied:
I prefer the original approach. Progressive enhancement puts all the burden or shit browsers on developers. Why the hell should developers have to tie together disparate browsers? The issue is clear: get Microsoft to *really* commit to *advancing* standards. The UK is a great position to do this since they are members of the EU and thus far the EU is the one and only organisation worldwide that can bring Microsoft to heel.
Microsoft want to make money out of Silverlight like Adobe do out of Flash.
Unless forced to do so, Microsoft will not provide any support in IE9 for browser standards that advance the web to a point where it competes with Silverlight. Hence Microsoft will never include canvas and SVG support because scripting vector art is the one core differentiation b/w open standards web design and the proprietary Flash/Silverlight approach.
Until the web gets basic native UI elements like pickers, sliders, tooltips and so forth, anybody supporting open standards is fooling themselves that they on the right bandwagon. I’ve been one of these people but I’ve had enough. I will not tolerate one more crappy JS-based picker/slider. I will not blend proprietary code (Flash) with complicated JS to get a mulitple file upload widget. I will not over-write standards code with ondomload JS and delude myself that the code I am writing is standards compliant because parsers only verify source code pre-domloaded.
So long as the UK gov is not favouring any one browser but rather providing a reasonable level of support for good multiplatform proprietary *and* open source browser options, SO BE IT!
A browser support list of Firefox, IE and Safari covers all scenarios. Crapintosh is supported with choice, same for Windows. Linux users can choose Firefox and wait for Chrome.
Stop whining to governments and force the glacial W3C to either get it’s act together or become irrelevant when governments like the EU make determinations that actually achieve something!
- #8 On January 22nd, 2009 7:35 am WaSP Member blawson replied:
pd, I share your frustration.
The original guidelines required government websites to test only on popualr browsers. The most popular browser is IE. By
“whining to governments”, the community has changed those guidelines so *all* standards-compliant browsers must be tested and the sites must work with them.
therefore, the community has helped break Microsoft’s stranglehold here. That’s a victory for choice, and one of the many ways of pressurising Microsoft.
Another is the EU investigation of Microsoft’s business practices regarding IE, which recently led to the EU sending MS a Statement of Objections yesterday, accusing it of illegally tying Internet Explorer to the Windows PC operating system. (Disclosure: my employers asked the EU to investigate, press release: http://www.opera.com/press/releases/2009/01/17/)
You say “Progressive enhancement puts all the burden or shit browsers on developers.”. You’re right. It does. It’s frustrating, hence I share your frustration.
But it’s what we do as professionals.
- #9 On January 22nd, 2009 8:59 am dstorey replied:
pd: I’d also add that with the original browser support they recommended which you list – FF, Safari and IE – it excludes the one and only browser that supports the native UI elements you mention you want such as range sliders. See Web Forms 2 for more details. Same said browser has a pretty good SVG/vector engine too.
- #10 On January 23rd, 2009 10:04 am Lorissa Shepstone – links for 2009-01-23 replied:
[...] UK government browser guidelines: good sense prevails – The Web Standards Project (tags: accessibility webdev) [...]
- #11 On February 9th, 2009 3:18 am Is The UK Government Being Too Strict? « UK Web Focus replied:
[...] post published on the home page of the WASP (Web Standards Project) Web sire. The blog post, UK government browser guidelines: good sense prevails by Bruce Lawson, Opera applauded the UK Government for responding to pressure from the Web [...]
Post a Reply
Comments are closed.