OperaWiki wurde zum März 2013 eingestellt und ist im Archiv-Modus. Die Inhalte der Seite stehen weiter zur Verfügung, werden aber nicht mehr aktualisiert. Mehr erfahren.

Interview mit Ian Hickson

Aus OperaWiki


Ian Hickson, Web-Standard Guru bei Opera und früher bei Netscape, hat mir ein sehr interressantes Interview über seine Arbeit beim W3C und bei Opera gegeben.

Please introduce yourself in a few words

I'm a cat lover who was invited to the CSS working group because I wrote a number of very "evil" tests that found errors in a lot of browsers. I have, over the years, been involved with the Web Standards Project, with Mozilla, with the W3C, and now I work for Opera in our Research and Technology group.

Do you think Opera should support more not valid code as many users ask for?

You have to consider all these requests on a case by case basis. Certainly there are some things we should (and do) support, like <marquee> - the entire Chinese market demands support for that element, for example. But there are other cases that are a lot harder – should we support document.all? We do, at the moment, to some extent, but there are those who think that this is causing more trouble than it's worth.

Personally my preferred solution is to take the non-standard extensions, and put them in a spec so that they _are_ standard. Then the question doesn't arise anymore. For example I took the non-standard "wrap" attribute and put it in my Web Forms proposal. Of course that isn't a standard yet, but at least it's in a spec now.

Should browsers display valid code only, at least in new languages like XHTML?

User agents (that's the technical term for Web browsers) should do what the specs say.

If the spec says that you handle errors by stopping all processing, then that is what you must do (for example, XML and SVG say that). But if it says you handle errors by, for example, treating all unknown elements as <div>s, then _that_ is what you must do (XHTML says something like that for some errors, although it leaves many error conditions undefined).

The worst situation of course is when the specification doesn't say what you should do when you hit an error – for example, HTML4 didn't give any error handling rules. The end result is usually a mess, because each UA will have its own error handling (probably just whatever was easiest, not what was best), and eventually if a browser rises to dominance, as Netscape did in the 90s, then all future UAs must copy the error handling exactly.

I mentioned this on my Web log

What language will be the future of the web?

We're at a crossroads right now. There are multiple directions the Web could go.

It could go the Microsoft route, with Longhorn, Avalon, XAML, and so forth, leading to Microsoft basically owning the Web. This would be bad for everyone except Microsoft, on the long run.

It could go the current W3C route, with XForms, XML Events, XLink, XHTML2, XSLT, SVG1.2, and the like. I doubt this will happen, myself, because those technologies are insanely complicated, according to our authors. If it was this option versus the previous option, I think Microsoft would win.

There are also other routes, which we are hoping will be successful. These would be based on the current technologies (HTML, CSS, DOM, JavaScript), but would be extended with features that authors are asking for, without introducing the massive complexity of, for example, XForms. The problem is doing this without being just as proprietary as Microsoft, of course.

How do you like Operas web standards support? Is there something you really miss?

I wish we supported HTTP "Link:" headers! Obviously that's a low priority though.

Do you think IE hinders the development of the web?

It's too easy to blame IE. I think what's hindering the development of the Web is the chronic failure of alternative browsers such as Opera and Mozilla to get any sizable market share. IE is such a poor product that we really have no excuse for our failure.

Some people in our industry throw up their hands and say "We can't win! Users don't download new products, they use what is preinstalled!". I think this is a loser's attitude. I don't know how reliable this is, but according to some of my sources within Microsoft, something like 50% of IE6 users actually downloaded IE6 (as opposed to using it because their machine came with it preinstalled). And just look at WinAmp, and peer-to-peer download software. People are clearly downloading programs and using them, so we should be able to get downloads too.

What "minority" browsers need to do to become "majority" browsers (and thus enable faster development of the Web) is to become as easy to install as IE6 (and for that matter, as easy to install as Spyware). We're not there yet.

Before you started working for Opera you worked for Netscape. Are there big differences between these companies (beside Netscape using open-source code (Gecko]]?

There was a culture of defeatism at Netscape. For example, Netscape 6 scored something like a 4 out of 10 on CNet, and so the Big Plan for the next release was "get an 8". Get an 8! Not "get a 10", mind. The plan wasn't to have the best product ever. The plan was to have a so-so product just so we would do well enough that we could scrape a Pass at the final exam.

If anything, the attitude at Opera is the opposite – people here tend to think the product is perfect, and dismiss any criticism as being from someone who doesn't know the product well enough to realise how perfect it is.

Which new/other standards (i.e. XForms etc.) do you predict/suspect most crucial for opera to implement in a future revision of the core rendering engine?

I think getting our CSS2.1, DOM2 Core, and HTML4 bugs fixed is probably our highest priority. As far as new specs go, recently I've been mainly working on XBL, Web Forms 2, and ideas for web Apps, so I suppose you could say I think those are the most important. Obviously, though, I can't speak about our future plans.

Should Opera try to expand its standards support, or help plugin makers (MathML, SVG etc.) fill the gap?

I don't think plugins will ever really be able to do mixed namespace compound documents. It's just too involved -- you have to share the DOM, the scripting context, the rendering area, everything. Just imagine trying to composite XHTML from the browser and MathML from a plugin with SVG from another, with the SVG side doing transforms on the results. Or any other combination. With events flowing correctly and so forth.

Now of course, one has to ask whether there actually is a standards gap. Is SVG a requirement? Is MathML a requirement? How about ChemML, MusicXML, SMIL, VoiceXML, NewsML, GML, SlideML, BioML, XMLEvents, XLink, XMLSchema? There are dozens of markup languages being developed, and it would be silly to think that browsers should support all of them.

Obviously for Opera it often comes down to whether we have a customer who is willing to pay for a language to be implemented; for other browsers, like Mozilla, it's a matter of does anyone care enough to actually do the work. MathML in Mozilla was done basically by just one person over several years.

There are also markup languages that we should probably refuse to do even if people want to pay us for them. For example, XSL:FO is a markup language designed purely for presentation. It's just like using <font> and HTML tables for layout: accessibility goes out of the window.

Other languages are quite good, but only for a tiny subset of the market. XForms is an example of this. It is designed for form professionals – people who use forms for a living, like insurance companies or tax services. Does it make sense for Opera to spend resources working on a technology with such a narrow market? Again, for Opera it comes back to whether someone is willing to pay enough for it, given that the market is quite small so once you've done it, you won't be able to sell it that many more times.

There are other examples of this. A good one is MNG. Mozilla once had MNG support, but it was removed for a number of reasons (the main one being that the implementation was much too bloated, which contributed to the many complaints of Mozilla being fat). Now, before it was removed, Mozilla people did some research to determine whether this would be a problem. They worked out that on the entire internet, there were about 300 MNG files, and most of them were from MNG test suites or demo sites.

But when the feature was removed, lots of people complained. The bug now has around 670 votes – that's more than twice the total number of MNGs on the Web! Does this mean there is high demand? Of course normally people would say that the demand is from people who would use MNG if MNG was enabled in Mozilla, but we know this isn't the case, since Mozilla shipped with MNG support for something like a year before it was disabled, giving it plenty of time to take off.

So when you look at this from Opera's perspective, what do you do? Do you think "look, there are 600 people on this bug alone who say they want this feature, so if we enabled MNG support in Opera maybe people would switch to Opera instead of Mozilla"? Do you say "there are only 300 MNGs on the Web and basically none are real use cases, so it's a waste of time to do MNG"? Or "there are only 600 people (out of 600 million Web users) who have registered that they want MNG support in Mozilla, so there is clearly no demand"? Or do you say "the MNG specification is ridiculously over-engineered, so let's wait for a better animated PNG solution that is easier to implement"?

You're in some W3C working groups. How does this affect your work for Opera or vice versa?

It _is_ my work at Opera, for the most part!