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:
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.
Opera isn’t sitting on their heels as the other browser vendors get snappy (even if other claim so!)
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.
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.
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.
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.
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.
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
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 :)
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.
We have a couple of browser updates. First, we have Firefox 3 beta 5 which has improved integration with the host system, a better places organizer, and a bump:
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.
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.
"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.
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.
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?
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.
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?
Tim Johansson is talking about Opera's support for a 3d Canvas which differs from Mozilla's in that it doesn't map directly to OpenGL, which they did because:
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:
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.
