Built using the open web standards you know and love, Opera Dragonfly’s source is available to view. Not only that, but it is released on a open source BSD license, meaning it is free as in freedom as well as in beer.

Opera is normally one of the few browsers that isn’t open source, but they are certainly doing more with open source itself. David Storey has announced how Opera Dragonfly has joined the open source ranks.

There is Dragonfly itself, but also the Scope protocol:

Starting today, Opera Dragonfly is a fully open source project, hosted on BitBucket. Since the previous version of Opera Dragonfly, a lot of work has gone on behind the scenes replacing the existing architecture with a modern version of the Scope Protocol – STP-1. Opera Dragonfly has been rewritten to use this faster and more efficient version of Scope. Now that we believe that the underlying protocol is stable and performant, and a public desktop build has been released with this included, it is time to put Opera Dragonfly on a public Mercurial repository.

If you have a Mercurial client you can visit the Opera Dragonfly STP-1 repository and check out the source code. We have provided initial documentation in the Wiki to get you started. This is Opera’s first full open source project, so there will be a learning curve. We ask you to bear with us while we get everything up and running and policies in place. Coming from a closed source background there are some hurdles to overcome, such as the current bug tracking system being on a closed server. We hope to migrate to an open bug tracking system as the project gets on its feet.

As well as the current and previous versions of the Opera Dragonfly source code, we have released a couple of tools to help with Opera Dragonfly development. The first is Dragonkeeper. This is a standalone proxy, which translates STP (Scope Transport Protocol) to HTTP. This can also be useful for remote debugging. The second tool is Hob. Hob is a utility to create code from Protocol Buffer descriptions. Protocol Buffers are one of the formats Scope STP-1 supports along with JSON and XML.

Nice. The question is…. will others implement on STP so we can get cross browser support.

Opera has been leading us on to a bit product launch, and it came today in the form of Opera Unite a product which extends the Opera browser to contain a Web server inside allowing you to talk P2P between browsers (via a proxy at operaunite.com).

On the one hand, skeptics have argued that this has been done before. We have things like the Plain Old Web server and P2P extensions. However, it is nice to see it packaged cleanly, and we have the advantage of more standard APIs (HTML5 APIs, Widget APIs, etc). At Mozilla (disclaimer: remember I work there ;), we also have something that overlaps with this work in Weave.

If you check out the developer primer you will quickly learn that to create a service you simply whip up some JavaScript, XML, and call it good. It is definitely interesting that the “web server” is a server side JavaScript implementation too!

John Resig noticed that from looking at the examples you miss a decent storage API:

Reading the Opera Unite primer. Opera really needs client-side SQL

I believe that there is room for the browser to do more, and to truly be your “User Agent”, thus I agree with some of the core tenants of what Opera is trying to do here. That being said, I worry that for all the talk of freedom, are we locked into Opera? :) It would be great to get this out to the community and work on getting multiple implementations and clear licensing of the protocols behind this.

What do you think?

But did you also notice the comic depicting their founders’ story?

Happy Birthday, Opera.

Ajax 2.0 with Anne van Kesteren

Ajax Testing Tool Review with Ted Husted

Analyzing the Ajax Application Performance with Gaurav Seth

Building Your First Adobe AIR Application with Kevin Hoyt

Today they announced Carakan a new register based JavaScript VM that is currently 2.5 times faster than their existing one (based on SunSpider). It does native code generation including at specializing for Regex (interestingly since irregex for Chrome was just announced too). Here is their words:

We have focused our efforts to improve upon our previous engine in three main areas:

Register-based bytecode

The last couple of generations of Opera’s ECMAScript engine have used a stack-based bytecode instruction set. This type of instruction set is based around a stack of values, where most instructions “pop” input operands from the value stack, process them, and “push” the result back onto the value stack. Some instructions simply push values onto the value stack, and others rearrange the values on the stack. This gives compact bytecode programs and is easy to generate bytecode for.

In the new engine, we’ve instead opted for a register-based bytecode instruction set. In a register-based machine, instead of a dynamically sized stack of values, there’s a fixed size block of them, called “registers”. Instead of only looking at the values at the top of the stack, each instruction can access any register. Since there is no need to copy values to and from the top of the stack to work on them, fewer instructions need to be executed, and less data needs to be copied.

Native code generation

Although our new engine’s bytecode instruction set permits the implementation of a significantly faster bytecode execution engine, there is still significant overhead involved in executing simple ECMAScript code, such as loops performing integer arithmetics, in a bytecode interpreter. To get rid of this overhead we are implementing compilation of whole or parts of ECMAScript programs and functions into native code.

This native code compilation is based on static type analysis (with an internal type system that is richer than ECMAScript’s ordinary one) to eliminte unnecessary type-checks, speculative specialization (with regards to statically indeterminate types) where appropriate, and a relatively ambitious register allocator that allows generation of compact native code with as few unnecessary inter-register moves and memory accesses as possible.

Automatic object classification

Another area of major improvement over our current engine is in the representation of ECMAScript objects. In the new engine, each object is assigned a class that collects various information about the object, such as its prototype and the order and names of some or all of its properties. Class assignment is naturally very dynamic, since ECMAScript is a very dynamic language, but it is organized such that objects with the same prototype and the same set of properties are assigned the same class.

Nice to see, and interesting that the browsers aren’t (or aren’t able too?) share their VM work. Each browser has a new VM implementation going. Wouldn’t it be nice if they could share effort?

Then we have Vega a vector graphics library that Opera uses to power SVG, Canvas, and more.

Vega was created shortly after we started working on SVG support.
When we added SVG support in Opera we needed a vector graphics
library. We looked into what what available to use and met our
requirements (fast, low memory usage and works on platforms
ranging from phones to TVs and desktop computers). We did not
find and good match for our needs, so we decided to write our
own.

Shortly after we created Vega we added <canvas> support, which
also uses Vega.

The most recent addition to Vega is the ability to use a
hardware accelerated back-end. The back-ends we are using at the
moment are OpenGL and Direct3D.

A busy day for Opera!

Here is a fun one for Friday, Hallvord Steen discusses the error reports coming in for Opera 10 that are to do with the version number.

That’s right, it appears that a number of people use the first character as the version number, which means that Opera 10 is showing up as Opera 1:

So we’re busy preparing the major upgrade from 9.5x and 9.6x – and what’s more obvious than calling it Opera 10? What’s in a name, or a version number?

Apparently a lot of trouble.

As Andrew Gregory already noticed, we’re the first browser ever to release with a two-digit version number. If websites assume that version numbers always have a one-letter “major” part and look for a single digit, they are going to “detect” Opera 1!

Since we released the first preview of Opera 10, we’re seeing the bug reports come in. Web sites go belly up because of their bad sniffing.

It is cool to see Opera doing this kind of work, with “Metadata Analysis and Mining Application (MAMA), a tool that crawls the web and indexes the markup and scripting data from approximately 3.5 million pages.”

Ian Hickson did some great work using the Google index to look at how developers use HTML, which lead to a lot of the HTML 5 features.

There were a couple of reports:

The URL set

MAMA’s analysis total is a mere fraction of even a single percent of such a daunting total. It seems odd to say that 3.5 million of anything is insignificant. So let us assume for a moment that it is not. We are just not able to look at every Web page, so we must choose a smaller group of URLs to look at and justify that this is representative of the whole Web. One option is to choose a set of URLs selected at random. I had some conversations with Rene Saarsoo (author of an excellent previous study on coding practices), and he brought up many excellent points about the structure of the Web and choices in URL sets—some of which I have tried to paraphrase here.

Markup Validation Report

Web standards are good for the Web! Most of the readers of this site will understand why this statement holds true—ease of maintenance, cross platform compatibility, access by people with disabilities, the list goes on!

But how does the reality of the Web hold up to these ideals? Surely with so many good reasons to code using open Web standards, the majority of sites should validate? Not so—Opera’s MAMA project has gathered a lot of quite shocking statistics showing that very few of the sites surveyed actually exhibit markup that validates.

Key Findings Report

Analysis showing:

• Web servers used: Apache: 67.72%, IIS: 25.91%
• Document structure and size
• Flash detection
• CSS styles used
• Scripting
• XMLHttpRequest object detection

Of course, it is easy to point to some potential flaws. Looking for “XMLHttpRequest” on a page doesn’t account for today’s reality on how XHR is used for example.

Doron Rosenberg pointed to some of these issues:

While it is no surprise that very few websites are completely standards compliant, their methodology seems flawed. Websites are doing more and more dynamic JavaScript stuff after page load which could affect such stats. Also, major JS libs are linked in via CDNs, so it is unclear how useful their XMLHttpRequest usage stat is.

But I can totally verify that chinese websites love flash. I still have nightmares from the AOL China gecko testing days. Flashing, scrolling, floating ads are scary.

That being said, it is great to see some data out there, and to give us a place to communicate. I would love to see more of this from Google, Microsoft, Yahoo!, and any provider that has a nice index of the Web.

Nik Cubrilovic covered this on the new TechCrunch IT blog:

Opera Software is building a team of “web evangelists” whose job it is to find sites that do not display correctly in Opera and are not standards-compliant, and then email the site owners. They are sending emails with specific tips on how to fix HTML, CSS or other issues that don’t make sites compliant. Opera has always been a strong advocate for web standards, and this initiative is good for not only Opera but standards support on the web in general.

On the Opera jobs website, there are job listings for multiple web evangelist positions. They are hiring in Norway, China, South Korea, the Czech Republic and the USA - so it is a multi-lingual global effort.

How would you take the advice? An email like this:

Hello from Opera Software,

We have recently come to know that [retracted] is not displaying
properly in Opera. It stems from an Opera bug which we plan have resolved and should be out with the next release. However, till that time, it would be nice if you could tweak the site on your end to make it work with Opera.

Just add “overflow-y:visible;” to the “Body” of the web page in the CSS file. Or you can just put

PLAIN TEXT

CSS:

1.  
2. body {
3.  overflow-y:visible;
4. }
5.  

In the <style> section of the pages, and it should make the pages display with Opera perfectly. If you have any more questions, please feel free to contact us.

If it was for general standards as well as Opera specific comments, then I would be quite happy :)

Shea Frederick has posted on building Wii-friendly web pages using the ExtJS library.

Shea focuses on the various issues that come up when building something for the Wii resolution, screen size, input types, and more.

For example, check out the layout:

And then you can detect the Wii to set this layout:

Opera has posted what looks like a great new Web debugging tool Opera Dragonfly which is released in alpha.

Debug JavaScript, inspect CSS and the DOM, and view any errors – Opera Dragonfly makes developing using Opera easier than ever, both on your computer and mobile phone.

Shawn Lauriat has a nice write-up that tells the story:

It offers most of the familiar tools for DOM inspection (along with a nice DOM editing capability), error logging (with the same granularity as before wrapped in a more polished UI), a JavaScript debugger that rivals WebKit's Drosera, a JavaScript thread logger, and a lot more that I haven't explored yet.

Time will tell whether Dragonfly can get enough developers to use Opera and keep them there, and how much the developers behind the new developer tools listen to the community in the coming iterations, but so far this looks extremely promising.

Features

• Reach breaking point step by step: Opera Dragonfly's fully featured JavaScript debugger makes building sophisticated Ajax applications easier than ever. Step through your code line by line, setting break points along the way. This allows you to make sure your application and scripts are acting as you designed them.
• Redefine your style: Its not just the DOM you can inspect. Check out what CSS rules apply to which element, and what rules are inherited or set by browser defaults. Overridden rules are highlighted so you can see what styles are or aren't applied. Support for editing CSS rules will be added in an upcoming version.
• Spot your errors: An improved error console allows you to see, filter and log any errors in your scripts, pointing to the exact position the error occurred. Use this in combination with the other tools to hunt down and fix your site’s bugs.
• Debug the DOM: View source isn’t much use if you use DOM Scripting to alter the DOM. Opera Dragonfly allows you to inspect the updated DOM and all it's properties. Support for editing the DOM will be added in an upcoming version.

The features that are not there yet, but are upcoming, include support for editing of CSS, JavaScript and the DOM, a single window mode, improved JavaScript thread handling, XHR and HTTP monitoring, improved keyboard navigation, and translation into a number of languages.

Have you checked it out? How do you like it?

Speed improvements to our JavaScript engine as well as profile guided optimizations have resulted in continued improvements in performance. Compared to Firefox 2, web applications like Google Mail and Zoho Office run twice as fast in Firefox 3 Beta 5, and the popular SunSpider test from Apple shows improvements over previous releases.

Opera also released a new browser with their Opera Mini 4.1 beta. The improvements talk about "faster" a lot: performance, finding things faster, and URL completion magic. This latest mobile browser also supports JSR-75:

JSR-75 is a specification for Java applications such as Opera Mini to access device internal storage and functionality within the phone. Some of Opera Mini features like "Save Pages" and "Download/Upload Files" vary on how much JSR-75 that is supported by the phone.

It appears that Opera has passed Acid 3:

Since the test was officially announced recently, our Core developers have been hard at work fixing bugs and adding the missing standards support.

Today we reached a 100% pass rate for the first time! There are some remaining issues yet to be fixed, but we hope to have those sorted out shortly.

We will release a technical preview version on labs.opera.com within the next week or so. For now, the screenshot above shows the Acid3 test as rendered in our latest WinGogi Desktop build. WinGogi is the Windows version of our reference builds used for the internal testing of Opera's platform independent Core.

At the same time, Ian Hickson posted about changes to the test and Anne has commented that Opera is passing the latest and greatest:

"The updates from Ian have been done since the release of the test. Opera gets 100/100 on the latest version of the test."

• Sub-pixel testing: It turns out that the original test accidentally required that browsers implement sub-pixel positioning and layout (and in fact the reference rendering got it wrong too, and relied on the same kind of rounding as Firefox does), which is somewhat dubious. I've changed the test to not rely on sub-pixel layout. However, it is very likely that this will be tested in Acid4, if we can get the specs to be clearer on this.
• Surrogate pairs in SVG APIs: One of the submitted tests assumed that SVG APIs worked on Unicode codepoints, but the SVG spec changed to work on UTF-16 codepoints, like the rest of the DOM API, so the test was changed there. (The test changed a couple of times, because I originally got the fix wrong.)
• The click() method: The test originally assumed that the click() method was reentrant, but the specs were vague on this and someone suggested making it fail if calls to it were nested, so I removed this part of the test (the spec hasn't been updated yet). I replaced it with an attribute test (the new second part of subtest 64).
• The Performance Test: I made the loop counter in the performance test (a part of subtest 63) less complicated and shorter, to make it at least plausible that browsers could be fixed to pass that test quickly enough that it wouldn't always feel jerky. At the same time, I updated the test's infrastructure to report more details about pass and fail conditions and how long each subtest takes to run.
• Namespace bug: Someone noticed that http://www.w3.org/1998/XML/namespace should have been http://www.w3.org/XML/1998/namespace in one of the subtests.
• Linktest timeout

I made the linktest more resilient to slow network conditions. However, the test is still going to give you major issues if you are on a network with multi-second latency, or if the acidtests.org site is being slow.

Congrats to the Opera team!

Oh, and Safari is at 95/100 and will close in on 100 shortly.

UPDATE:

Hixie has another update:

Just as Reddit is celebrating Opera reaching 100/100, with the misleading headline Opera the first browser to pass the Acid3 test (hey, submitter: it wouldn't hurt to read the Opera blog post before submitting it to Reddit), the Apple guys track me down and point out that there's yet another bug in the test. With heycam's help, we have now fixed the test. Again. This presumably means Opera is now at 99/100... the race continues!

I have to say, by the way, that the relevant parts of the SVG spec are truly worthless. Where are the UA conformance criteria? You'd think a spec that was so verbose and detailed would actually tell you stuff, instead of just rambling on without actually saying what the requirements were...

The complaint describes how Microsoft is abusing its dominant position by tying its browser, Internet Explorer, to the Windows operating system and by hindering interoperability by not following accepted Web standards. Opera has requested the Commission to take the necessary actions to compel Microsoft to give consumers a real choice and to support open Web standards in Internet Explorer.

"We are filing this complaint on behalf of all consumers who are tired of having a monopolist make choices for them," said Jon von Tetzchner, CEO of Opera. "In addition to promoting the free choice of individual consumers, we are a champion of open Web standards and cross-platform innovation. We cannot rest until we've brought fair and equitable options to consumers worldwide."

Opera requests the Commission to implement two remedies to Microsoft’s abusive actions. First, it requests the Commission to obligate Microsoft to unbundle Internet Explorer from Windows and/or carry alternative browsers pre-installed on the desktop. Second, it asks the European Commission to require Microsoft to follow fundamental and open Web standards accepted by the Web-authoring communities. The complaint calls on Microsoft to adhere to its own public pronouncements to support these standards, instead of stifling them with its notorious "Embrace, Extend and Extinguish" strategy. Microsoft's unilateral control over standards in some markets creates a de facto standard that is more costly to support, harder to maintain, and technologically inferior and that can even expose users to security risks.

Mary Jo Foley quickly chimed in on why it is a bad idea:

1. Should antitrust courts be the ones in charge of determining which versions of Cascading Style Sheets (CSS), XHTML, Document Object Model (DOM) and other Web standards are the ones to which all browser/Web developers should be writing? Participants in various standards bodies can’t even agree among themselves which version of these standards is the best. How are judges supposed to wade through the browser-standards confusion in a good/fair way?
2. Would it be positive for customers if Microsoft were suddenly forced to create a version of IE that looked good on paper, in terms of more complete standards compliance, but which broke third-party and custom Web applications? Microsoft has argued that it is trying to avoid this situation with IE and is working on various ways it can make IE more standards-complaint without breaking existing apps, completely upsetting the partner/customer universe.
3. With Mozilla, Firefox has proved you don’t need government intervention to wrest a substantial percentage of the browser market from Microsoft. You just friends with deep pockets (like Google) and a community of dedicated developers — plus a guaranteed customer base who prefer anything other than Microsoft technologies.

   In the end, Microsoft’s own inertia, browser-security problems and inability to react quickly to market changes (where, oh where, is IE 8?) will continue to help its browser competitors more than a ruling by the EU or other antitrust body would.

   What do you think? Is Opera’s attempt to get the European Commission to force the unbundling of IE from Windows too late? And what’s your take on Opera’s attempt to get the courts involved in enforcing Web-standards compliance?

• It makes it easier to implement on non-OpenGL platforms (such as D3D)
• We wanted to have some form of collision detection available

What can you do? Here is the interface that you get to work with:

And, here is an example of a rotating cube (which you can see if you are using a new Opera build).

Features

Opera Link

We've added support for Opera Link in Opera Mini 4. With Opera Link, you're able to instantly synchronize and share your bookmarks and Speed Dial with the Opera browser for your computer.

Overview mode

Opera Mini 4 includes a new rendering architecture that allows you to view webpages just like you would on your computer. When you first load a webpage, Opera Mini will show you an overview snapshot of the page; using the new mouse cursor you can instantly zoom in to the selected region of the page.

Size of text fits width of screen

Opera Mini 4 dynamically changes the size of the text on webpages to fit the width of your phone's screen, meaning you won't have to scroll horizontally.

Context menu

A context menu is displayed when pressing the number 1 key. From the context menu you could change the viewing modes to 'Mobile view', reload the page, and show webpage information. When the mouse cursor is focused on a link, the Context menu will show you the link information (i.e. where the link points to, etc.).

Mouse cursor

With the mouse cursor you could scroll to any direction on the page and more easily click on links.

Scrolling shortcuts

Pressing these number key shortcuts will help you quickly navigate around the page.

• 2 - Page up
• 8 - Page down
• 4 - Go to the left one column
• 6 - Go to the right one column
• 5 - Zoom in and out

Create search

With this new feature, you could add any search engine of your choice to the Opera Mini start page. To add a new search engine, click on the search field, press the menu button and click on the 'Create search' option.

View pages in Landscape mode

By pressing the * and # shortcut keys, you could switch the page view to landscape mode.

New standards support

Support for HTML tables, CSS handheld stylesheets, and more advanced support for CSS have been added to Opera Mini.

Opera Mini is a very clever way of bringing the web to your mobile phone - it will work on most phone models, even low spec ones, as long as they will run a JVM. Basically, when you request a web page from Opera Mini, a request is sent to the Opera Mini servers. They retrieve the page, convert it into OBML (Opera Binary Markup Language,) a very compact binary markup format that reduces the page size by up to 90%, and then serve it to your phone....But what about JavaScript?

The areas covered in his article include:

• How Opera Mini interprets JavaScript
• Server-side support
• Client-side support
• Ajax support

One key point that jumped out at me is that the Opera Mini servers have full support for ECMAScript 4 on the server-side but is hindered on the client side by the limitations imposed on individual handsets.

After the page has been transferred to the client, things are a lot more limited - basically all events are processed on the server. The client does absolutely no JavaScript processing at all, and instead the page is kept in the server (basically the client works as an input device for the opera running in the server).

My reaction was obviously that this is a major limitation but Chris goes on to give this perspective:

This sounds limiting, but there is another point to consider - Opera Mini can execute JavaScript on the server if it's triggered by the JavaScript events listed above in the client, so some complex pages work surprisingly well - for instance Facebook is able to display popup menus and popup dialogs very well on Opera Mini.

There are also some considerations when trying to use Ajax, as the Opera Mini architecture handles Ajax requests slightly differently based on the expected functionality. Chris cited the use of automated page refreshes as a possible sticking point.

As with any mobile device or browser, a lot of homework needs to be done when developing for Opera Mini but it looks like Opera is making some good strides towards easing that pain.

It looks like the Opera team really focused on the rendering engine, with some fast results displayed during CyberNet's review. Ryan, CyberNet's reviewier:

...decided to do a rather unofficial speed test to see how fast the different browsers rank in terms of loading our site (with an empty cache). I did three tests for each browser and averaged out the time it took for each to completely load our site. Here are the results with the slowest browsers first:

• Internet Explorer 7: 18 seconds
• Firefox 2: 15 seconds
• Opera 9.23: 12 seconds
• Firefox 3 Nightly: 11 seconds
• Opera 9.5 Alpha: 8 seconds

In addition, it looks like accessibility is big on the list of enhancements with enhanced support for Window-Eyes, Jaws, and VoiceOver on OS X as well as updated keyboard shortcuts to make navigation easier. You can get more info at the Opera Desktop Team's recent blog entry about the release.

This means that you can watch up to four people buzzing around the screen:

Polling the status of a remote

The Wii Remote data is accessed through the opera.wiiremote object. This object offers a single method opera.wiiremote.update(n) which is used to obtain the status of an individual Wii Remote. The method expects a single parameter; the Wii Remote number. The number is zero-based, so it starts at 0 for the first remote, and ends at 3 for the fourth remote. The method returns a KpadStatus object, which has several properties that give information about the remote.

This update method can be called as often as is needed to obtain a fluid response, but note that the Wii is not as powerful as most desktop computers, so it is important to make sure that it is polled only as often as the script that uses that data can process it. For example, if a script uses the Wii Remote status to update the display of a canvas element, and that update will take perhaps 50 ms to update in Opera on a desktop computer, it may take over 100 ms on a Wii. Attempting to use a polling interval of less than 100 ms will cause the response to appear very sluggish.

Note that the opera.wiiremote object only exists in Opera on Wii, so it is important to check for its existence, as well as the existence of the opera object, before attempting to use it.

Examples

There are a bunch of demonstrations, including a simple game.

I can't wait to see the Star Wars light sabre web game... and then see a Comet based app that grows beyond the four connected devices!

Shawn Lauriat has posted on the new Opera Developer Console.

The tool is written in JavaScript and is an interesting little read.

The tool covers:

DOM

The DOM tool lets the user inspect and alter various various aspects of the document.

JS

The JavaScript tool lets the user to inspect and search the JavaScript enviroment initialized on the web page.

CSS

The CSS tool lets the user inspect and alter any Cascading Style Sheets attached to the page. Further, the tools allow the altered stylesheets to be exported for later use.

HTTP

The HTTP tool allows user to inspect the HTTP headers sent from the server, inspect and edit cookies, and allows logging of XMLHttpRequests sent by the document.

At first, each person got a chance to say their peace. Here are some core items that each person said:

Chris Wilson

We are not about to enter another browser war. This isn't about destroying each other. This time it is about building the standards based web future, which means we need to work together. This isn't 1995, so let's not build that platform. The problem that we have is that as soon as you improve something, you break the web. This is especially hard since Microsoft has ~500 million users.

Chris queried the top 200 web sites and 50% of them are in strict mode. When he did this in IE 6, only one of them was like this. He hinted at having developers opt-in to standards mode in a different way.

Mike Shaver

Mike also said that he doesn't consider it to be a browser war..... but rather a "mindshare struggle".

The new "war" is having cool applications being built on the web itself. If the next flickr/gmail/... is built on the web, it is winning.

Don't look to the W3C for the future.

HÃ¥kon Lie

"If you need a good browser for Windows 98 we have it"

Ajax is bad. We need to add HTML, CSS, and the like, and he had some funny acronyms.

He then discussed the ACID 2 test and had a lot of fun with IE 7 showing how it compared to Opera 3.6 from 1998.

The Wii (which uses Opera) is going to change the web. More people are trying to get their sites rendering correctly with the Wii than "who cares about that Opera browser".

We need to support video as a first class citizen (and sound). "We can't leave it to plugins anymore".

What video formats should we support? There aren't many open formats, so they use Ogg formats.

Where's Apple?

They refused to send someone saying that "we are busy writing software".