Interview: Charles McCathieNevile on Opera 9.5 and W3C Standards

In June 2008, Opera Software released version 9.5 of its browser. As part of a series of interviews with W3C Members to learn more about their support for standards and participation in W3C, I asked Charles McCathieNevile (Opera's Advisory Committee Representative at W3C) some questions.

Note: Upcoming interview: Roberto Scano of the International Webmasters Association / HTML Writers Guild on standards-based authoring.

Q. What are your favorite new features of Opera 9.5? Can you pick one or two favorites for each of these W3C-related topics?

On Support for HTML 5

A. Naturally, we have a complete implementation of the final version of HTML 5...

Seriously, it's still a draft of course. Improvements to its parsing algorithm, reflected in improvements to ours, and continuing convergence in the way browsers build an HTML DOM, are really important to the Web, but somewhat incremental steps, so it is hard for me to pick a particular highlight in this area from 9.5.

Some of my favourite stuff that seems destined for HTML 5 is still not in the spec: Webforms 2 brings things like <input type="date"> for a date picker or the ability to make an input+dropdown list in declarative markup, instead of massive amounts of javascript. But that was already released in older versions of Opera. And there is canvas, which we have had in previous releases, but which is now clearly happening in W3C.

So for me the best HTML5 that is new in Opera 9.5 is Accessible Rich Internet Applications (WAI-ARIA). We're talking about an experimental implementation of an unfinished spec being incorporated into another unfinished spec, so there is plenty of good stuff to come in this area. But I think it is a really nice piece to have working, and the first implementation we have released is in 9.5.

I also have a disappointment. It wold be nice to have video there, but until we get a royalty-free way of enabling everyone to do that it is hard to make it high priority. So we didn't end up releasing that in 9.5, although I encourage W3C to keep following this up and find a useful solution because video is important on today's Web and should be interoperable and open enough for people to build products.

On Support for CSS

Personally, the most exciting stuff in CSS is that we made a significant level of MathML support possible through the MathML for CSS profile, and that we can use SVG in CSS backgrounds, list buttons, etc.

This probably shows how boring I am. I am not a designer, and I realise that any true designer would give very different answers about what rocks for them. Chris Mills wrote about a bunch of new CSS stuff in 9.5 that is pretty cool, like the effects you can get with multiple text shadows. Håkon [Wium Lie, Opera Chief Technology Officer] is excited by our CSS3 selectors work, which is great stuff.

But for me the MathML and SVG stuff running on my OLPC is one of the things about 9.5 that really rocked my boat.

On Support for XSLT 2, XForms

We have had effectively zero demand for these features. It is possible to use Xforms through javascript libraries in Opera, but I have not done it for a while. We did fix up a few bugs that were troubling people in our XSLT 1 implementation, which was important to the Web.

On Support for Accessibility

This question is easy for me - rebuilding screen reader support, which is a major ongoing effort under the hood, shows its nose in the public release build with Opera 9.5 on Mac and Windows. Given that it is difficult to work with Windows-based screen readers, I would suggest you try this feature out on a Mac (besides, you don't have to buy VoiceOver separately as it is part of the OS).

As a close second I would name ARIA. Again, our support for this is experimental - the spec was having some crucial parts nailed down as I was writing these answers - but we are proud of our contribution, which includes solving a problem with namespaces so it is possible to use ARIA interoperably in HTML, SVG, XHTML or XHTML2, and allows it to be incorporated into other XML/namespace-based languages like DAISY or MathML as well.

On Support for Security

We continue to work hard making sure we are the most secure browser. 9.5 brings support for the so-called EV ("Extended Validation") certificate, where a user knows not only that someone bought a certificate to encrypt their data, but that the the people who sold that certificate can actually find the person who bought the certificate, and if something goes wrong you therefore have some real means of redress.

We also worked pretty hard on our anti-fraud and anti-malware protection, covering both sites you visit and things you might download. Overall we have worked on making security user friendly, and at the same time powerful enough to protect users who want to use the web and what it has.

Users need simple guidance they can understand, as well as the power to do complicated things like decide whether to accept a certificate from an unknown authority (something that only makes sense to a few power users).

On a Mobile Experience

Opera Mobile 9.5. Opera Mini.

The HTC Touch Diamond is a high-end piece of hardware with a manufacturer who wanted a great Web browser, and chose Opera Mobile 9.5 - I think they were the first to announce it in a product, with the Samsung i900 also having it. Because these are windows mobile browsers built on our cross-platform core, we can provide similar levels of experience on other pieces of hardware for other suppliers, and I am looking forward to the public beta being available soon for anyone with a windows mobile phone.

Opera Mini is not running Opera 9.5 in the current 4.1 release. But it has been a game changer in the world of mobile web over the last 18 months. Mobile browsing has started really taking off, and Mini has been one of the major contributors to this. Lifting the level of what is available on a mobile phone, not just to the relatively tiny 'smartphone' market (the top few percent, who already have access everywhere) but to the much larger featurephone market which includes many people globally who have no other form of internet access, strikes me as a pretty big benefit in a world where increasingly web access is as fundamental as literacy to equal participation in society.

Beyond both those things, there's lots of stuff we have done in Opera that is relevant to mobile browsing. We reverse-engineered the "make it work for the iPhone" HTML hack and figured how to integrate that with the CSS standards-based approach we were already using, we further improved Opera's zoom, we put our leading SVG implementation into our native mobile browser (we had used the already good Ikivo plugin for SVG) as part of the upgrade to Core 2, added widget support, among zillions of other fixes and improvements.

But I think some of the most exciting stuff in mobile is not especially standards-oriented yet - Opera Link allows you to synchronise various kinds of information between mobile and desktop browsers, and this seems something that others want too, with Mozilla's "weave" heading the same way.

Q. Are there some noteworthy changes that will make cross-browser authoring easier?

A. Yes. These fall into two categories.

We have further improved our standards support in a variety of areas. As mentioned above, we improved our XSLT engine. But in some cases this is more a case of waiting for other browsers to catch up in order to allow people to use things reliably. As far as I know we are still the only browser shipping with a decent @media implementation, for example - a ten-year-old piece of CSS that makes for simple slideshow creation, or allows basic sites (the "long tail") to adapt to mobile rendering pretty painlessly.

There are also non-standard things we have to make compatibility for. Matching the strange bit of code Apple gets people to use so their sites look alright on iPhones, bringing undocumented or unspecified APIs closer in line with what other browsers do, and so on. But we have also made a point of trying to get the undocumented hacks, as well as the pure innovations, into the standards track so it is easier for everyone to improve interoperability, and for developers to know what really happens out there on the Web.

The second important change is the major upgrade of our developer tools, called Dragonfly. Still in beta, these are now designed to provide the power that developers have relied on Firebug to give them - but with some added bonuses. Because we have a very cross-platform browser, our tools are designed so you can debug remotely - see your code running on a different machine, or in a different browser instance (perhaps take a random weekly build from the Opera Desktop Team and debug it with your stable working release) or, importantly, on a different device. Since this is built into Core 2.1, as soon as mobile browsers are shipped based on Core 2.1 you will be able to debug what is happening in your real mobile (not an emulation on a desktop architecture), live from the comfort of your desktop.

Q. Can say a word about Opera's priorities in CSS support for the next year or so (and how they align with those of the CSS Working Group)?

A. There are some shiny features being shown off in the CSS Working Group, like using basic SVG features through CSS to apply them to HTML documents. We would like to see this work cleaned up, and the interactions with SVG in particular (which it replicates) carefully considered, but we think there are still lots of useful things that could be one with CSS (as well as some things that are better off done in markup).

We would also like to see CSS specifications advance in maturity. There are lots of things that can be done easily with CSS (our MathML implementation is based on having decent stylesheet support, being able to do seriously good HTML/SVG/etc slideshows or simple adaptations of a site to different devices is based on the ten-year-old @media rule) but there needs to be a lot of basic work done to give the design community a stable target. Webfonts is something that Håkon has recently been focussing on, because it is, as he says, well past time that we moved beyond a handful of proprietary fonts that were generously donated, and unleash people's ability to design real fonts for real text not just in SVG but for the entire Web.

I think this is broadly in line with the CSS working group, and we are basically happy with the priorities of that group if they can get specs moving along the process and completed.

Q. Does Opera 9.5 ship with XForms in the default configuration? If not, is there a reason we should be aware of?

A. Nope. We haven't seen any demand, nor any content on the Web that is causing major compatibility problems by requiring it. As I mentioned already, there are javascript-based implementations that can be used in a intranet setting, and so far that has been sufficient so we have focused our development efforts on other things. (I might add that although we actually support a relatively large amount of XHTML 2, it is more or less by accident, and it is for essentially the same reasons that we don't focus on implementing it completely).

Q. Can you comment on the state of SVG implementation in Opera 9.5?

A. It is pretty good. (That's Australian understatement we inherited from the British. It means "We Rock").

Alternatively could let the SVG community comment - we are listed on codedread (the site of the new SVG Interest Group chair Jeff Schiller) as the best native implementation going around, with the quote

"In roughly a year, the Opera browser went from being one of the least usable SVG implementations (no scripting/DOM support) to the best native implementation"

(which is slightly more presentable than his most enthusiastic comment about Opera, about kicking, and parts of the body).

We are working on further improving but I think our SVG work, in implementation, in contribution to the specification, and in contribution to the community, is something to be proud of, and the SVG and Graphics guys have done a great job.

Q. W3C has a goal of designing technology that works well on different types of devices with minimal or no additional effort for authors and readers. Opera creates Web software for many different devices (e.g., for desktop environment, mobile phones, and game consoles). From your perspective as browser developer, what challenges do you face when developing for different environments? What would you suggest that W3C do (e.g., improve existing technology, develop new technology, provide tools, promote education) to make it easier to develop for different environments?

A. Challenges come in 4 ways. The first is hardware - we have squeezed recent Opera builds onto platforms that were below our minimum specification for Opera 1, and we now have CSS, ECMAscript and DOM, and other features of the modern Web. In this sense it is important to ensure that specifications focus on what people really need, since anything else is at risk of being dumped in order to maximise the efficiency of the platform, but also because building what people use everyday into native code, rather than needing some javascript extension library, is important for performance.

Of particular concern in this context is battery life. People rely on phones in particular not just for Web access, but as a crucial tool in their everyday life (and in some circumstances as a vital part of their personal security). Running down the battery through poor design of standards is really quite unhelpful.

The second is input - as you move from a keyboard to a voice interface, or waving a wand (or game controller), or a small touch screen, a joystick or a limited keypad, you need standards that consider this range of input. At the same time we are seeing a growth of applications, whose designers want to build so the user thinks s/he is interacting with a normal application. We need much more thoughtful design of input mechanisms to cope with the huge variety of devices around. Some of this work is pretty old - WAI and the early device-independence groups at W3C have been dealing with this kind of problem for a decade and more. But the knowledge and attention to this problem are still very unevenly distributed through W3C.

The third is output - different devices also have different ways of presenting information - and we are constantly inventing new ways of using them. Zoom was once something Opera did with a simple scaling effect, with the variety being text zoom where you could change the font-size. Then came fit-to-width, ensuring that the layout reflowed even when the designers forgot, and small screen mode, and over the last 3 years zoom has become much more powerful and intelligent, with what we call "Opera zoom" intelligently and dynamically reflowing the zoomed section of what is basically a large-screen view to provide for ease of use and user efficiency - this is something that you can now see in various browsers on different devices. And here I have only mentioned screens - there are also voice, various kinds of tactile feedback, the use of "soundscapes", and so on to consider. Again, there has been work in this area for years, but spreading the knowledge and ensuring the review of new work by people who have been working in this area is important.

The other potential concern is security. W3C began with virtually no attention paid to security aspects of its technology, I think because it was initially a group of high-minded and like-thinking people who simply didn't consider the "dark side" as something that could be interesting, and who were working with essentially public data. The Web now reaches into your phone, a device whose capability to run up bills and provide personal information matches a credit card - and security and trust models need to mature to recognise that. An important piece of work is being done by the Web Security Context Working Group, who are looking not just at abstract security models for boffins, but at what ordinary users and ordinary developers know and understand - because those are the people who the security models need to help and protect. Building extremely powerful applications is only a part of the puzzle - for years we have enabled access to special functions on the platform. The other part of the puzzle is identifying the security risks, and describing them in a way that clarifies what implementations should note, without simply having the Web hamstrung by barriers imposed because we didn't bother to find ways to improve security.

And not just for device independence, although it is important in that context; I really think there has to be more focus at W3C on the tools people use to develop content. We can't (and shouldn't) develop those tools in Working Groups, but we really desperately need to make sure that the people who do develop those tools are turning up, involved, and are developing their tools along the lines of the standards as they emerge. One reason why anyone can make a browser, but making a good browser is so very difficult, is that we have to handle the things that tools produce, and that hand-authors who only learn by copy-paste-tweak produce. In the long run, this does not help standardisation, so we need to have the tool producers there are the start of the process.

With the profusion of low-cost devices, chiefly phones and the wave of OLPC-inspired cheap laptops, and with the increasing use of the Web in cars, in industrial machinery, and in other specialist devices, this is more important than ever to get right.

Q. Do you plan to make HTML input-mode available to mobile users, and if so, when?

A. We have the code to enable it in the core, so we can ship it in deliveries if anyone asks for it. But it's a pretty vague specification, so enabling it by default especially in desktop is likely to cause as many problems as it solves.

Q. What do you see as the biggest challenges today in enabling accessible Web browsing on mobile platforms with Opera?

A. If you mean accessible in the W3C sense of "to people with disabilities", the fragmentation in devices, platforms, and assistive technologies. Building a real cross-browser platform means that we need to have our own layer for UI, and then hook that to the platform we ship to. On some platforms this is just a matter of work, but on others it really involves dealing with a mish-mash of half-solutions coming from all over the place.

Effectively, this is going to take time - as I mentioned, our compatibility with accessibility tools is a work in progress - in some areas such as problems faced by people with limited vision we have had plenty of accessibility for ages, but in others, like for people with no vision there is still a lot of work to do.

If on the other hand you just mean the broad English-language sense of the term, then most of the challenge is in distribution, which comes down to the question of price of access and use, compared to the benefits available. Which means we have to build a great application platform, support it with things like our debugging tools and our widget SDK, get an ecosystem of great applications and use cases in place, let users know that it is there, and have users decide that the cost of the service is repaid by the value it gives them - something that I think is happening already (why else would Opera mini be growing at about 10% *per month*?).

Q. There are signs that both browser makers and authors are rediscovering the benefits of embedded data. Does Opera have plans to support microformats (e.g., display hatom and hcalendar with the RSS reader, or hcard with the address book), RDFa, or XMP?

A. Yes. :) (You'll have to stay tuned for more).

Q. Opera has support the application/xhtml+xml media type since version (ages ago). What challenges did you face in implementing it? Did you have a specific strategy for doing so?

A. It's XML...

Seriously, it is not very hard. There are a couple of strange issues that come up because it is not quite compatible with HTML, and people expect it to be so (for example, scripting is not exactly the same, and namespaces in XML are easier to work with than in HTML where they generally cause problems) but nothing that really makes it difficult to do.

Like everything that distinguishes a good standards-compliant browser from a great standards-compliant and also useful browser, we have various strategies for dealing with the Web as it is, as well as the Web as we would like it to be.

Q. Opera 9.5 includes integrated support for torrents, irc, usenet, rss and atom, in addition to HTML, CSS, and other formats. How do you choose which features to include natively and which would best remain independent applications (that evolve independently)?

A. It is important to us that a new release doesn't mean that some critical application breaks. If we decide that something is important enough to be a core feature, rather than an experimental add-on, we feel it is important enough to ensure that it develops alongside the browser.

Q. Scripts can be useful or malicious. Does Opera 9.5 allow users to distinguish between (and control the execution of) scripts from trusted sources (e.g., extensions written in javascript) from those found in pages on the wild Web? Would that be useful?

A. Javascript extensions (userJS - which is basically the same thing as greasemonkey have certain privileges that scripts in the wild don't have. The same goes for scripts in Widgets. The same goes for browser.js - compatibility scripts that Opera produces and periodically ships to the browser in order to solve problems with major websites from time to time - a sort of limited live-update that applies to a few specific sites that have especially unpleasant coding problems in them.

A useful model of trust has to be one that makes clear sense to users. Widgets on widgets.opera.com are code-checked before being posted, because we think it is important for us to be trustworthy. browser.js is shipped totally unobscured so that users can read it for themselves - an easy way to develop trust is how what you're doing, although in practice it only applies to stuff that people can readily get their head around.

So it would be good to have a more powerful, and more comprehensible model of trust on the Web - not just for scripts but for applications in general. It's no good building a layer of the technology stack that is perfectly secure if that just turns out to be a transport layer for all kinds of malware that people accept because they trusted the system. Work such as AC4CSR, or the file I/O proposal and its friends in the Web Apps space, are trying to open specific areas to enhance what can be done on the web. But we really need to think through the whole security and trust architecture better, I think and this is something that takes a fair bit of time.

Q. Based on the Opera 9.5 experience, are there any particular issues that you would like W3C to address as a priority?

A. I think that understanding the security space is important. I would love to see some more direct focus on multimedia and getting some resources behind those who are building patent-free alternatives to what is currently available. I think W3C needs to focus more effort and attention on the tools that are used to create Web content, and ensuring that it is feasible to build authoring tools so people don't need to become experts in SVG and HTML and scripting in order to share their expertise in water-pump installation or Mayan history using proper web standards. Too often I hear this mentioned at the beginning of some work area, and a few years later people are still saying "yes, we really should think about authoring tools, too" without doing anything about them. Although it is important that Web standards can be hand-authored ("view source" is important to tool developers as well as copy-and-hack early adopters), it is critical that people can create content without having to hand-author it.

Ensuring that technology really works on mobiles, and other devices, and the related technology work in accessibility is critical to the future of the Web, and while it isn't something we solve in a week it is something that needs to be front and center so that we don't turn around in a few years and discover we have to spend a few years re-doing our work because we forgot to focus where it matters.

Q. The W3C standards process seeks to balance speed and fairness. Building consensus takes times. Building software also takes time. Any suggestions for how to speed those processes up while promoting participation and maintaining fairness?

A. W3C has been moving towards a more open model, and almost of necessity this slows down the work, as more people need to understand and digest what is happening as it occurs rather than being presented with a fait accompli.

Providing more support for translation of Working Drafts would be helpful - this speeds input and adoption from non-English-speaking communities, which also ensures a better specification. Perhaps the incentives for translating a new Working Draft should be raised compared to translating some short test case or simple tutorial article. (It is pretty apparent that one key consideration for doing this is based on SEO, so increasing the SEO rewards for doing more useful work seems like a simple thing to help).

Promoting implementation across the toolchain - from browsers to authoring tools and tutorials - and promoting the development of interoperable but different systems over the idea of a single implementation are important to improving spec quality and the speed of development.

Q. On a similar note: do you think it would speed up the standards process if, within a given Working Group, participating Members were to prioritize and agree to implement a list of features? Or do the different priorities of the participants (and their customers) make that unlikely?

A. If Members agree to a prioritisation of implementation, and follow through, of course it speeds up work significantly. Element Traversal is an example of a perfectly simple spec, readily implementable and with several interoperable versions shipping on totally distinct codebases, that was held up some months because someone thought that it might be interesting to implement something new instead of what everyone did, and then specifying the new piece. It turns out there is no real problem with shipping the old spec and then making a new one to cover the extended functionality, which we also expect people to implement, so we expect to have the first spec finished with probably four complete implementations very soon, and the extra functionality specified and implemented relatively soon after.

On the other hand, it is possible to waste a huge amount of time trying to get agreement where there simply is none.

Q. What innovations (in particular, related to standards support) should we expect from Opera in the next major release of the browser?

A. Some things are predictable: further improvements to the accessibility support, more HTML 5 and SVG and CSS and MathML and better integration, and so on. And there are various things we have previewed at labs.opera.com that will come to release, like audio and video, Acid 3 compliance, selectors API, improved webfonts, filesystem access, and so on.

But expect the unexpected! We're working on some cool stuff that we will start to launch pretty soon. We're working to build a fantastic cross-platform standards-based application environment, and there are many things that would be good to put into that space. We'll come up with some new toys, and it might pay to watch labs.opera.com for an idea of what we are working on before we make a major release.

Many thanks to Charles for his answers.