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.
