Mike Taylor by Mike Taylor in Blog

Post tags: odin opera-next

This post is licensed under a Creative Commons Attribution 3.0 Unported license.

What’s New in Opera Development Snapshots: March 26, 2012

Pssst! Yes, you. You like CSS? Interested in some HTML5? Want some hot ECMAScript? Then, my friend, you want to look at this latest Opera desktop snapshot in which our core rendering engine, Presto, gets a huge upgrade.


  • This build introduces initial support for HTML5 Drag and Drop. With DnD, Web pages can natively drag elements, selections and microdata from one page onto another, or drag files from the operating system and drop them onto a Web page. Have a play with this simple demo. Another demo presents a list of fruit that you can drag around—have a look at the code and see how you can break this in iteresting ways, and try to figure out why the words and rows are draggable, but the fruit images aren't.

    Currently, we’ve got some bugs and limitations with this initial HTML5 Drag and Drop support, such as issues with dragging to and from external applications. Please give us your feedback and report any DnD-specific issues here.

  • Previously, Opera did not expose how much of a video was preloaded in the native controls that are associated with a video element. This has now been added. Here is a demonstration of that effect.

  • <video> will now use a new kind of cache for streaming resources and limit the bandwidth to (approximately) the bandwidth of the video while playing. This is reflected in the buffered attribute.

  • Cache invalidation for <video> was improved, so live streams should be able to recover from a network error. Previously no new data could be read after a network error.

  • HTML5 defines the default value of the size attribute of an <input> element as 20. Up until this snapshot, it’s been 0. Have a look for yourself at arguably one of the shiniest HTML5 demos of the year.

  • The submit event would fire before HTML5 form validation, allowing invalid or incomplete data to be submitted. For example, clicking Submit with an empty form should not fire alert() here.



  • We now correctly support the TypedArray contructor of the form TypedArray(TypedArray array), e.g., var x = new Uint32Array(uint8Array);.

  • ES5.1 defines special handling for String.prototype.split(undefined). Previously we aligned with V8, but as the latest JS engines in Firefox and IE are now compliant we’ve fixed this to match the spec.


  • The HTML5 structured cloning algorithm has added support for re-assigning ownership of certain objects via Transferables. We’ve updated our implementation to support this now.

  • Appending a <foreignObject> element in SVG or modifying its contents via script never resulted in a reflow, therefore the changes never got painted. Fixed now!

  • Not too long ago, support for window.event, attachEvent, and detachEvent was necessary for the “Best seen in Internet Explorer” class of sites to work. Thankfully, these days are mostly behind us. As such, we’re hiding our support for these IE-isms. What this means is code like if (window.event) will return false, but existing code will work if it relies on it.

  • Another IE-ism that we’re removing is readystatechange events on the <script> element. This was causing a handful of sites to break as we supported both this and script.onload.

  • Previously, in Opera, if the properties of an element changed such that a pseudo-element was no longer generated (Psuedo-elements are generated if a pseudo-element selector matches the element), the pseudo-elements still persisted. This is now fixed.


  • Direct children of the element with enable-background=new were rendered into its BackgroundImage buffer twice. They no longer do so.

64-bit and out-of-process plug-ins

  • In December 2011 and February this year, we've released 64-bit Labs builds with out-of-process plug-ins. Running plug-ins in a separate process gives Opera a level of protection from plug-in instability, which is one of the most common sources of browser crashes and freezes. This architectural change has now graduated from Labs, and has landed in the desktop Next channel.

Encoding, Unicode, Network, and Graphics (aka Changelog Potpourri)

  • Surrogate pairs no longer work in CSS escape sequences. To understand this, let’s look at 𝌆, a supplementary, non-BMP character. In UTF-16 encoding it consists of two surrogate halves U+D834 and U+DF06. In order to work with this in JS, you’d have to write \ud834\udf06. CSS, on the other hand, doesn’t care about surrogate pairs so content: '\d834\df06' should show invalid characters, not the Unicode symbol. In this example, you shouldn’t see 𝌆 after “WAT”, but some invalid characters.

    Special thanks to Mathias for reporting this to us and writing it up in detail.

  • Did you know that there was x-mac-ukrainian? Me neither. The x-mac-cyrillic mapping is defined in the encoding specification. In the past when Unicode was not yet deployed everywhere, each OS implemented their own version of character sets. Apple defined a Ukrainian set of characters. On the Unicode site, we can find its relation to the cyrillic one.

  • Opera has implemented for a while different open formats: video and audio (OGG, WEBM), image (webp). This release adds the association between the Content-Type (HTTP) with filename extension (file system) for these formats. When you want to add some of your own, you can go to Preferences → Advanced → Download.

    • video/ogg = .ogv, .ogm
    • audio/ogg = .oga, ogg
    • video/webm = .webm
    • image/webp = .webp
  • In the first iterations of Web Forms 2, a lot of ideas of XForms were applied. Since then Web Forms 2 have been added (and modified) to HTML5. The initial Web Forms 2 specification had application/x-www-form+xml as a form encoding type to enable XForms parity. It is not part of the HTML5 specification anymore, so we dropped support for it.

  • It is better to encode your Web pages in UTF-8, and serve them as such. In HTTP, the HTTP header has priority, then the meta name contained in HTML. Some Web pages have specific encoding. It happens often on the Web that the Web page encoding is different from the one specified in the file and/or the one specified in HTTP headers. It creates issues for users who receive unreadable characters on their screens. So the browsers have to fix the encoding on the fly. We had bug reports about Web sites sending BOM different from the HTTP header. We decided to make the BOM authoritative like webkit and IE, because there are more chances for it to be exact than the HTTP headers.

  • Opera used to treat “unexpected out of order” code in a gif file as a hard error and abort decoding, while other browsers didn’t. The implementation has been changed so this is consistent. Here is a smiley blowing its nose - in older Opera versions it would not reach the nose-blowing state, but now it does.

So where do you get all these goodies? You could just hang out and wait a little while until your Opera.Next updates itself (Browser Identification will show Presto/2.10.282 in opera:about if you've got the latest).

But I bet you want to grab it while it's hot, so you can grab it from from the Desktop team's blog post.