Last week saw some interesting blogposts that neatly summarise the opposing world views that we’re seeing at the moment regarding the “problem” of the Web.

Alex Russell (of Google Chrome) wrote a considered blog post called Things the W3C Should Stop Doing in which he suggested

the W3C needs to find a ways to re-focus on the needs of the constituencies that give it credibility; namely web developers and browser vendors.

…it should be agreed that the W3C will divest itself of any and all Semantic Web, RDF, XML, Web Services, and Java related activities.

…What would that leave us with? CSS, DOM & JS APIs, HTML, a11y, i18n, and all the other stuff that has legs out on the public web.

…The time has come for the W3C to grab the mantle of the web, shake off its self-doubt, and move to a place where doing good isn’t measured by numbers of specs and activities, but by impact for web developers.

I found myself nodding frequently while reading it. I wrote two years ago about my belief that XML makes no sense on the Web. And there are no shortage of vital specifications to work on – just look at David Storey’s list The Open Web 1 stack: the HTML5 application age (even after removing EcmaScript and WebGL which arent’t W3C).

I fervently hope that the W3C continues to be the place where new Standards get hammered out. I worry that, because it dropped the ball so calamitously with XHTML 2 and left the WHATWG to begin work on HTML5, there is a feeling that other specs should be developed outside the W3C. We see this with Widget specifications, where organisations haven’t liked the W3C work but instead of participating in that group, they’ve developed their own variants in isolation.

Developer Joe Hewitt has nothing but scorn for the W3C or any standards body:

To thrive, HTML and company need what those other platforms have: a single source repository and a good owner to drive it. A standards body is not suited to perform this role. Browser vendors are innovating in some areas, but they are stalled by the standards process.

He similarly scorns diversity of user agents, wishing for a monoculture:

It would help if all the rendering engines but one were to die, but even that would not be enough. Even if WebKit was the only game in town, it would still be crucial for it to have competent, sympathetic, benevolent leaders. The closest thing we have to that today is Chromium…

Obviously, I’m hardly likely to agree with this (I work for Opera, but this post is personal opinion yada yada). I’ve written before about how the IE6 monoculture grew because people believed it was the finest browser (In praise of Internet Explorer 6) and you can read about the cost of a browser monoculture in Korea.

I’m with Uncle Timbo who dreamed of the Web as universal: independent of hardware platform, software platform (operating system), Application Software, Network access, Language and culture or disability. These are features not bugs. This universality is the strength of the Web, not a problem to be solved by a Strong Benevolent Leader and single user agent.

Web veteran John Allsopp writes

The web is a different problem. It makes little if any sense to compare innovation of the web ecosystem with that of iOS, Android or other platforms. The web faces challenges far far greater (and has goals far more important). A platform such as iOS can abandon legacy applications, content and hardware, (along with their users) with little compunction. It can (and does) make developers and content creators wishing to participate jump through any number of hoops. It has a single dictatorial decision maker, beholden to no one, and nothing other than itself. And it generates extraordinary revenues, which can be reinvested into the ongoing development of the platform.

The web is different. It values interoperablity, backwards compatibility. It’s goal is to bring access to the same information to billions across the world, on all manner of devices. Its custodians are, in my opinion, scandalously under-​​resourced, given just how much wealth the web has created for so many, perhaps above all Google and Apple.

Robert Nyman (of Mozilla) agrees:

The web is the true form of democracy: people from any part of the world – with any background, gender, social status or skin color – can take part in and build the future. Some things can take longer to reach consensus about than in a closed company-controlled environment, but I would have open and democratic standards every day over that.

Not all developers agree with Hewitt. This month’s poster child for responsive/ adaptive/ HTML5 design is the redesign of The Boston Globe newspaper. It has rich markup. It looks great across different devices and screensizes. It looks great on devices that can’t deal with much JavaScript such as Opera Mini.

In an interview I did (for .net magazine, unpublished) Scott Jehl (of the Filament Group who worked on Boston Globe) said

I find Opera Mini tends to be pretty easy to support if you build with Progressive Enhancement – it’s a great browser with lots of performance optimizations included, and of course it’s incredibly popular around the world so supporting it is a no-brainer. Our experience [at Filament] leading the jQuery Mobile project led some familiarity to a lot of platforms that aren’t commonly tested, but are quite popular throughout the world.

The baseline browser we were regularly testing was BlackBerry 4.6, which receives a basic, JS-free experience like most other non-media-query-supporting browsers. Somebody sent us a screenshot of the Globe site running on a Newton recently!

It’s not the case that to make sophisticated websites you need to abandon universality, creativity, and progressive enhancement.

Scott is one of those behind a manifesto site called Future Friendly that argues:

We want to make things that are future friendly. By anticipating what’s next, we can react to today’s concerns but also build long-term value for people and businesses…To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services…An ecosystem of devices demands to be interoperable, and robust data exchange is the easiest way to get going.

Once you remove the fluffiness from the manifesto, it boils down to a useful reminder to design with progressive enhancement; to use structured, semantic markup; to test across software and hardware platforms and to understand that things won’t look the same everywhere.

Future friendly or Forward to Yesterday? I know which I choose.

UK government browser guidelines: good sense prevails

The Web Standards community changed some guidelines for government webmasters that would encourage designing to browsers into something that requires valid code, web standards and progressive enhancement. UK government browser guidelines: good sense prevails.

Talking of guidelines, I’m doing a short talk on Wednesday about BS 8878: Web accessibility – Building accessible experiences for disabled people at the Oxford Geek Night. See you there?

How Can I Validate (X)HTML + ARIA?

A while ago I speculated that the lack of a validator for ARIA might slow adoption. Steve Faulkner has written a proof-of-concept HTML4+ARIA Checker and hopes, as I do, that “the W3C validator adds support for (X)HTML +ARIA documents so I when check a document and it contains no errors in the HTML (except for the use of ARIA) and ARIA code, I see a message like this: this document was successfully checked. Passed (1 Warning)”

Should you think that ARIA is just w3c vapourware, there’s a podcast on ARIA by Freedom Scientific (the manufacturers of the JAWS screenreader) available:

Freedom Scientific’s Chief Technical Officer Glen Gordon explains ARIA and its benefits. Jonathan Mosen then demonstrates some applications with ARIA enabled for improved accessibility.

Didn’t see a transcript anywhere, surprise surprise.

More bandaids for microformats

Pat “Herb” Lauke wonders “if we should have an official anniversary each year where the same microformat/accessibility issue is rehashed” and links to an experiment by Andy Clarke. It’s a nice idea, but I think it’s a bandaid. I agree with Isofarro’s diagnosis:

It boils down to this: the title attribute is meant for human consumable content, just the same as the inner text of most of the HTML elements.

Everytime you put machine-formatted data into a container that is for human consumption, then you run the risk of it being exposed to a human being. In microformats this a ‘feature’, in accessibility this a ‘bug’.

I think that’s throwing the baby out with the bathwater to say “the easiest approach right now is to say Microformats are inaccessible, and move along”; it’s just this pattern that’s inaccessible.

Patrick suggests, “why not make a ‘title attribute’ pattern that allows for the use of the most semantically appropriate element? span with title in cases like datetime, abbr when it is actually an abbreviation.”

That makes sense to me. How would those plugins that make use of microformats cope if I marked up hCalendar dates with a span. Anyone know?

I was wrong, people said: IE 6 mobile isn’t IE 6 desktop back from the dead and dripping goo and pus like a George Romero zombie; it’s an accident, a coincidence of the numbering system. Microsoft are good guys now, they said, committed to web standards.

After all, look at the claims for it:

Internet Explorer Mobile 6 [is] a full-featured browser for Windows Mobile devices that brings the same high-quality browsing experience to the user as desktop browsers. Internet Explorer Mobile 6 supports desktop-quality rendering and has the best compliance support of all versions of Internet Explorer on a Windows Mobile device to date.

So I downloaded the emulator and ran a few tests.

Conditional comments and * html

Firstly, I tested a simple page to see if it picked up Conditional Comments targetted at IE 6, and whether it picked up CSS rules aimed at the valid, but nonsensical * html elements.

The test page is

p {color:red}
* html p {color:blue;}
<!--[if lte IE 6]>
<h1>Conditional comments think I'm IE6!</h1>
<![endif]-->
<p>Red for non-IE6, blue for IE 6</p>


So, IE 6 (or below) will show a heading, and a paragraph in blue. A modern browser will have no heading and the text will be red. The screenshot shows that IE 6 mobile believes it to be the same as IE 6 desktop on both counts.

IE 6 mobile and the Acid tests

29% of all internet users in China only ever use a mobile phone to acess the Web. But Microsoft’s “new” mobile browser doesn’t quite have the standards-compliance that Chinese people deserve.

The Acid 2 test:

and the Acid 3 test:

IE 6 mobile and CSS support

A big problem for web developers was IE 6 lamentable support for CSS, so I ran the CSS selectors test. The results say “from the 43 selectors, 10 have passed. 1 are buggy and 32 are unsupported”.

Even IE 7 passes 13 of the 43 selectors (“4 are buggy and 26 are unsupported”).

So what IS IE 6 mobile?

Well, it appears that the heart of it is chucklesome old IE 6 desktop, with a few extra bits grafted on from IE 7 and IE 8′s JavaScript engine. So it’s cross between a zombie and a Frankenbrowser.

To verify, I opened up the back of my mobile and hiding behind the battery, clinging onto the SIM, I found the true face of IE 6 mobile, its lips mouthing “Ni hao” in anticipation of its imminent Beijing exhumation.

Joking aside, this is a terrible situation. 20% of the world’s population are being offered an ancient, discredited browser. Who knows whether we’ll imminently see China’s phones paralysed by viruses—after all, the U.S. government’s Computer Emergency Readiness Team advised

there are a number of significant vulnerabilities in technologies relating to the IE domain. It is possible to reduce exposure to these vulnerabilities by using a different web browser.

We need web standards. And China deserves them, too.

This is Opera Software’s response to the Public consultation on browser standards for public sector Web sites by Central Office of Information (COI).

Opera Software ASA is a company headquartered in Norway. Noway is a signatory to the European Economic Area Agreement, which guarantees free trade with all EU states and cooperation in such matters as consumer protection, culture, education, and information services (see http://www.eu-norway.org/about/eeaforside.htm).

Many of our users are within the United Kingdom and the European Union, and we feel that the draft guidelines (“the guidelines”) potentially disadvantage them.

We support the aim of the COI to ensure inclusion by testing public authority Web sites on a range of browsers. It is also laudable that the COI requires that Web sites be made accessible to people with disabilities and across multiple operating systems.

However, we feel that there are some aspects of the browser guidelines that need re-drafting. We request that our concerns be considered and give permission for them to be quoted with attribution in any report on this consultation.

Executive summary

Opera believes that the current guidelines attempt to reinvent a wheel that has already been satisfactorily invented and refined over time by other large organizations, both public and private. Reusing their work reduces costs to taxpayers.

Also, Opera believes that the guidelines in their current form

• are anti-competitive, as they perpetuate dominance in the browser market by giving the impression that alternative browser products are inferior, and those who choose to use them are not worthy of consideration,

• inconvenience users unnecessarily by asking them to install new software,

• do not promote best practice development and may lead to more expensive development and testing,

• are too fragmented,

• insufficiently “future-proof” Web sites, by ignoring methodologies which would ensure compatibility with mobile phones and other devices,

• ignore plug-ins which have capabilities independent of browsers, and

• do not sufficiently ensure accessibility by disabled users.

Recommendations

The guidelines should recommend using Web standards and a best-practice development methodology called “progressive enhancement”. This will help ensure compatibility across browsers, rather than aiming at different browsers as if they are completely separate targets.

For testing, the guidelines should recommend adoption of browser support matrices such as the one provided at http://www.bbc.co.uk/guidelines/futuremedia/technical/browser_support.shtml/ by the BBC, which is a well-respected Web brand with a public-service duty and a huge, diverse audience.

This would support

• greater competition in the browser market

• greater value for money for taxpayers

• more consistency for Web visitors and developers, and

• savings on Web development costs by promoting Web standards and proven methodologies.

These benefits are also noted in the BBC’s Objectives of Web browser support, which gives the methodology by which their browser-support matrix was devised at Appendix 2.

Guidelines restrict choice

Guidelines confuse popularity with capability

Paragraph 15 says “There may be specific browsers that you choose not to fully support because they are either old or unpopular.”

It is legitimate to choose not to support old browsers fully that are not capable of rendering sites made with Web standards and progressive enhancement.

However, it is wrong to decide not to support a browser purely because it is “unpopular”. If it is capable of rendering the site, it should be supported.

The guidelines’ introduction states, "It is important to declare which browsers your website has been tested on. This demonstrates a clear commitment to your audience. Users will want to know whether or not your website works with their browser."

We disagree. By naming the browsers on which a Web site has been tested (simply because they are more “popular”), the impression is given that browsers that were not mentioned are somehow “second class”, and its users are not worthy of attention, which demonstrates a clear lack of commitment to audience needs.

We recommend adopting a testing statement such as that used by the Solicitors Regulation Authority:

Browser compatibility

It doesn’t matter how old your browser is—you can use this website. It looks different in some older browsers, and is mostly text in very old browsers (like Netscape 4, or Internet Explorer for Macintosh). But the information is the same, and so are the things you can do.

Guidelines inconvenience users

This erroneous impression of less “popular” browsers as being inferior is reinforced in the sample “browser support statement” in paragraph 12.

Webmasters are advised to list browsers they have tested in as “supported”. The example browser support policy statement includes 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".

There are also many reasons why a user may not be able to change their browser easily – for example, they

• may not be using their own computer and be on a shared computer; therefore, they are unable to change or update the browser,

• may use a particular browser because of security or privacy settings,

• may use a particular browser due to features that help them access and are unable to use another browser comfortably,

• may not know how to change their browser.

Many users of the most “popular browser” made no conscious choice to use that browser. On the other hand, we know that many Opera users choose Opera because of features such as excellent keyboard support, the built-in voice browser, intelligent zoom, and fit-to-width display, which are very useful for people with disabilities. It is unreasonable and unfair to suggest that they upgrade because a Webmaster has elected not to test in Opera.

Potentially anti-competitive

Not only does this inconvenience the user, but we strongly believe that this is anti-competitive.

The guideines help perpetuate current market shares by encouraging users of “unsupported” (in reality, “untested”) browsers to replace their current browser with another.

(Disclosure: The EU Commission are opening an investigation into an anti-trust complaint filed by Opera on 12 December 2007, regarding Microsoft bundling Internet Explorer in the Operating System and not implementing Web standards.)

Guidelines do not promote best practices

The guidelines are published because it is “impractical and inefficient” to test in all browsers. Presumably this should be interpreted as the COI suggesting that it is not cost-effective to do so. However, it is unnecessary to do so if best-practice Web development is followed.

Best practices should be central to guidelines

The section “out of scope” notes, “How to code for browser compatibility [and] Development methodologies such as graceful degradation and progressive enhancement,” are out of scope.

Additionally, paragraph 40 notes “These guidelines do not advocate specific development methodologies, for example, graceful degradation or progressive enhancement. However, it is widely accepted that sites conforming to open Web standards such as XHTML and CSS are more likely to work well across a wide range of browsers. The importance of working to technical standards is highlighted in Minimum technical standards”.

Opera believes that the guidelines must recommend the development methodology known as “progressive enhancement” which, when based on Web standards, would reduce inconsistencies between browsers resulting in greater interoperability.

When this methodology is employed, users of the most capable browsers automatically receive the highest quality user experience, while users of less capable browsers will receive content and be able to access basic functionality. Therefore, no-one will be “locked out", whereas being "locked out" is much more likely if you choose consciously to test only in/support specific browsers.

Guidelines erroneously treat Web as a visual medium

The guidelines treat the Web as if it were a visual medium such as print, in which designers specify pixel-perfect layout and can rely on that being delivered to the consumer.

This is not true and is inappropriate for public-service websites, where the emphasis is on content rather than aesthetics.

Paragraph 41 says, “A browser is semi-supported if the content and navigation works but the website does not display as intended”.

It is incorrect to judge a Web site on whether it displays “as intended”. A Webmaster cannot mark a browser “down” as semi-supported because it does not have curved borders, opacity, or the same fonts as those on a designer’s machine.

By emphasizing “intention”, the guidelines legitimize preservation of design as a goal. In the past, this has led many bad design decisions such as fonts being expressed in pixel sizes which cannot be resized in Internet Explorer, for example.

The Web site should be judged on whether the recipient can use it in a format that (s)he wishes. If, for example, a browser mis-renders a site built with Web standards, such that content is obscured or is illegible, then that browser is unsupported.

If a browser renders the content as legible, the navigation usable and functionality operable, then that browser is fully supported in the context of a public-service site.

Best practices lead to cost-savings

Recommending best practices whereby developers code to internationally-agreed standards rather than to circumvent the quirks of today’s market leaders leads to cost savings throughout the life-cycle of a Web site:

• It is more cost-effective to build right than to correct during testing, so explicitly advocating progressive enhancement results in more efficient development and Web sites being quicker to market.

• Reducing inconsistencies through smarter development ensures that the “testing” phase is shorter and, in the case of static pages of content, it should be possible to reduce testing to a quicker “verification” stage that quickly checks across a range of browsers that there are no significant inconsistencies.

• Once deployed, Web sites built using valid, semantic (X)HTML and CSS are more maintainable because they are in accordance with international standards.

Guidelines are too fragmented

The guidelines mention design methodology and minimum technical standards in paragraph 40, but it is a leap of faith to assume that everyone else will read the second document.

The guidelines are written “for all website managers, web developers and web testers delivering public sector websites”, so we recommend that all the guidance relevant to these groups be amalgamated —or developers will naturally assume this supersedes all other guidance and start developing to browsers.

Additionally, the “Minimum Technical Standards” document is dated May 2002 and is obsolete; it mentions CSS 2 as the latest version, allows HTML tables for layout, and does not mention Scalable Vector Graphics (SVG).

Opera recommends modernizing this document and incorporating the updated guidelines into a comprehensive document aimed at the target audiences named on the cover.

Guidelines do not address mobile and other devices

Paragraph 39 notes that Guidance on support for mobile platforms will be the subject of future guidance. Other devices are described are similarly “out of scope”. (Paragraph 37 also notes, “Guidance on support for mobile platforms will be the subject of future guidance”; we assume this is an editorial error.)

This further fragments the guidelines, as readers will have another set of guidelines to check.

Different guidelines are unnecessary. Recommending a progressive enhancement methodology ensures that Web pages work across all browsers and devices.

Guidelines ignore plug-ins which are independent of browsers

The guidelines ignore the subject of browser plug-ins, such as those that allow readers to access PDF, MP3, video, and Flash content. These plug into a browser but are independent of it. Therefore, a group of users running the same version of a browser may have different versions of plug-ins and receive markedly different experiences.

For example, a visitor running Opera 9.5 with Flash Player 6 would not be able to take advantage of any accessibility features built into a Flash movie, while a visitor running Opera 8 with Flash Player 7 would be able to use those accessibility features, because the plug-in has a higher specification, even though the browser is less capable.

The guidelines should address plug-ins, independently from browsers.

Opera also suggests that the guidelines for Web developers require the use of open standards wherever possible, while allowing content that requires plug-ins as a secondary delivery method.

Guidelines should recommend testing by disabled users

Opera welcomes the guidelines’ inclusion of a requirement that Web sites be tested with assistive technologies.

However, the guidelines currently legitimize a sighted developer using a trial version of a screenreader and comparing the synthesized speech with the words on a screen, which is inadequate testing; a sighted user cannot have the same experience or knowledge of the tool as a real user.

Therefore, we believe that it should incorporate guidance from the British Standards Institution’s Publicly Available Specification (PAS) 78, Guide to good practice in commissioning accessible websites:

• “All organizations, regardless of size, should ensure that those testing the website are different from those developing it.”

• “Website commissioners should conduct user testing with disabled participants to ensure that their websites are accessible and usable by disabled people”

• User testing should include users from a range of disabilities and preferences, including a mix of beginners and experienced web users using a range of assistive technologies.

Inadequate definitions/ ambiguities

• Paragraph 46 suggests testing “ability to bookmark” as part of testing a Web site. That is a browser feature, not a developer-authored feature and thus out-of-scope.

• Why are Rich Internet Applications separated out? The requirement for sites to work with scripting turned off, etc., is not solely related to RIAs.

Too many trademarks used in examples

We would prefer it if more than one trademark were used as illustrative examples, or none at all, as currently the guidelines erroneously give the impression that only one browser exhibits the qualities being discussed.

For example, we would prefer it if paragraph 50 were redrafted to read, “Certain browsers (e.g., Firefox and Opera) are developed using cross-platform technology (e.g., Java) and, therefore, behave similarly on different operating systems,” or “Certain browsers are developed using cross-platform technology …”.

Contact details

These comments were written by Bruce Lawson, a Web Evangelist representing Opera Software ASA. Bruce may be contacted via brucel@opera.com for any clarification of these comments.

Comments on the Opera developers’ network, please; no login required.

UK government draft browser guidance is daft browser guidance

I’ve written a piece for the Web Standards Project about a new government consulation on proposed guidelines on browser testing. Sounds yawnorama, I know, but please read it and respond to the government: if it goes unchallenged, it will reduce choice, inconvenience users of government websites and lock smaller browsers (like Opera, who I work for) out of the market. It looks like we struck a chord; Adam, who wrote the draft guidelines, says that they’ve had approximately 400 responses already. In three days!

Accessiblity in suit and tie

I’ve written a piece for thinkVitamin called Accessibilty in suit and tie about how to “sell” accessibility inside a corporate organisation, with crap technology and the like. It’s a more generic version of my long long article Standards-based corporate web development.

Hello Henny!

When I started at Opera, the top guys said to each other “Why do we only have one übergroovy kickboxing accessibility-lovin’ glamorous web evangelist? We need two! And make the other one a dame!”. Three months and an executive notice period later, in comes Henny Swann fresh from the RNIB and WaSP. (Note to Nate Koechley: Yes, Henny is a girl.)

What a great team of good-looking guys and gals I work with.

New Opera releases

Want to build your own browser in a device?

Then use the Opera 9.6 SDK to build an Opera browser in your TV, picture frame, tablet etc. This new version comes with the same compression used for Opera Mini on mobile phones, so it’s pretty jolly fast. (Developer documentation)

Opera 9.6 beta released

We’ve also released a beta version of Opera 9.6 desktop. This adds some privacy settings I like (so bookmarked URLs don’t appear in the autocomplete address bar, which can be embarrassing at presentations) and adds a low-bandwidth mode for the Opera mail client, plus some useful UI tweaks. Download it but please be aware it’s beta software, so please install it separately from your current 9.5 install

Multipack meeting on Saturday

For West Midlands web developers, and those who care for them, there’s the regular multipack meeting at The Old Joint Stock in Birmingham, to catch up with all the goss from Geek in the Park and dConstruct. Wish I could be there (but will be flying in from Amsterdam) as it’s always a pleasure and a warm welcome.

The CSSWG plans to discuss its charter at our next face-to-face meeting in March. If groups like CSS3.info, the CSS Eleven, and the WaSP and/or individuals like Jeffrey Zeldman and Eric Meyer could organize a collectively-written list of priorities and submit it to us before then, we could take that into account when writing our charter for 2008+.

So at the Web Standards Project we’re collecting such a list of priorities. Thinking caps on, if you please, and comments there.