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.
So, I was challenged on my assertion that the new Internet Explorer for mobile that is going to be unleashed in China next year is based on the web developer’s mortal enemy and the virus-writer’s best friend, IE 6 for desktop.
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.
Introduction
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
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 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:
-
“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 …”.
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.