Archive: August 2012

A colourful Opera 12.50 snapshot

As work steadily continues on our next stable release, this week's Opera 12.50 snapshot provides a colourful mixed bag of new features and improvements. As ever, we've cherry-picked the ones we find most interesting for developers.

Context Menu API for extensions

Another new API for extensions? Yes indeed! This time, it's a handy method to add items to the context / right-click menu. This can be useful for any kind of interaction with a page or its contents.

The API allows fine-grained control, making it possible for an extension menu item to only appear in the context menu for a link, or to only be present on certain domains. It's also possible to add sub-menu items which can be created with a folder-style structure. When a menu item is clicked, there are also a variety of event properties to enable you to work with things such as a link's URL or some text selected by the user.

In short, this API is ideal for developers wanting to activate their extension through more than just a toolbar button, so feel free to try it out following our freshly released Context Menu API documentation.

Fullscreen API

The Fullscreen API provides a simple set of JavaScript methods (such as element.requestFullscreen() and document.exitFullscreen()), as well as a new :fullscreen pseudo-class, that allow pages – and, more interestingly, even individual elements within a page, like a custom video player or a canvas game – to go fullscreen.

As a simple demo, I've hacked up one of my old video player examples (with custom HTML-based controls) to include this new functionality: HTML5 video - fancy video controls with JavaScript, including Fullscreen API support. Note that in this demo it's not just the video element, but the whole container – including the custom controls – that is going fullscreen.

As ever, with the new "HTML5 the living-on-the-edge standard", specs chop and change. This snapshot implements the Fullscreen API editors' draft 7 February 2012, while the standard has now mutated in the latest July 2012 version.

HTML5 <ol reversed>

A nifty feature from HTML5-the-living-standard is <ol reversed>. The specification says "The reversed attribute is a boolean attribute. If present, it indicates that the list is a descending list (..., 3, 2, 1). If the attribute is omitted, the list is an ascending list (1, 2, 3, ...)."

Note that if you combine reversed with the start attribute (which was bizarrely deprecated in HTML 4 but re-instated as a full member of the attribute gang in HTML5) you could encounter lists counting to zero or below. If you're using a counter style that isn't decimal (for example, alpha or roman numerals), the list will be decimal when it drops below the value that corresponds to 1. The spec says:

Numbers less than or equal to zero should always use the decimal system regardless of the type attribute.

For browsers without support, there's a clever and semantically meaningful reverse ordered lists polyfill by Louis Lazaris.

SPDY support

They grow up so quickly...only last month we released an Opera Labs build with SPDY support, and now it graduated to our main branch, on track for inclusion in our next stable release.

As a bonus, this snapshot also comes bundled with a SPDY indicator extension that shows you when a site uses SPDY...no more hunting around in Opera Dragonfly's network panel for those extra headers!

If you previously installed extensions in Opera Next, the bundled extension may not show up automatically. Either reinstall this snapshot with a clean profile, or simply grab the SPDY indicator extension from the addons site.

Nested @media blocks

As a first step towards our implementation of CSS 3 Conditional Rules, this build introduces support for nested @media blocks. Instead of long and repetitive @media feature lists such as:

@media only screen and (orientation: portrait) and (min-width: 480px) {
    ...
}
@media only screen and (orientation: portrait) and (min-width: 600px) {
    ...
}
@media only screen and (orientation: portrait) and (min-width: 768px) {
    ...
}

it's now possible to nest media queries, allowing for much cleaner, leaner and most importantly more understandable CSS:

@media only screen {
    @media (orientation: portrait) {
        @media (min-width:480px) {
            ...
        }
        @media (min-width: 600px) {
            ...
        }
        @media (min-width: 768px) {
            ...
        }
    }
}

Support for images with ICC Profiles

Beyond containing the image data itself, many image formats (JPG, PNG, TIFF to name a few) allow for embedded colour profiles. These ICC profiles tell programs how the raw image data should be interpreted, mapped to the currently-used colour space, and ultimately displayed. The large majority of images on the web don't contain embedded ICC profiles, so browsers will simply display them without any sort of color correction. However, photo enthusiasts and perfectionists will be pleased to know that, should their images contain specific profile information, Opera will display these as intended.

For further information on ICC profiles, I'd recommend this excellent and accessible primer on Digital Image Color Spaces, but here's a simple example.

A photo of Bruce Lawson, with an embedded colour profile - ICC-aware browsers will display this correctly The same photo of Bruce Lawson, but this time without any embedded ICC profile - this will appear completely colour-shifted in all browsers

If Bruce looks blue in both images, your browser doesn't support ICC profiles.

Both of these images are exactly the same, in terms of their raw image data. They were created using an exaggerated custom colour profile, to more clearly illustrate the point. The first image contains an embedded ICC profile, which signals to colour-managed programs how to interpret the data, while the second image doesn't. In browsers that don't support colour profiles, both images will be displayed without any colour correction (resulting in the funky colour shift), while ICC-aware browsers will correct and display the first image based on its embedded ICC profile.

And here's the Russian translation of this post: Красочная сборка Opera 12.50.

SXSW 2013 Proposals

,

It's that time of the year again, when we get to vote for the proposed panels and solo presentations for SXSW 2013. You have until the 31st of August to vote, so if the following presentations by our Opera colleagues look interesting, give them an upvote: up

HTML5 and the Mobile Browser Wars, with Mike Taylor
The mobile web in the rest of the world, with Shwetank Dixit
The Future Is Now: futuristic UIs with HTML5, with Luz Caballero
Browser Wars 6: Look Ma, No Browser!, with Someone Cool (TBA)

But we don't want to just give good talks, we want to see them too. Here's a handful of proposals that we would enjoy seeing in person:

Frontend Development Techniques for the Modern Web
Stand Alone JavaScript Build Tools
Coloring the Web: Understanding CSS color
Fun and Games with CSS3

We hope to see you all in Austin next March to talk about the future of Opera products and the Open Web!

CSS vendor prefixes in Opera 12.50 snapshots

, , ,

Vendor prefixes have been useful, but they have arguably caused as many problems as they've solved, both in CSS and DOM APIs. So, in the run up to Opera 12.50, we're removing as many -o- prefixes from stable CSS properties as we can.

Last week, Patrick mentioned the removal of prefixes from Transitions, Animations and Transforms.

In today's Opera 12.50 snapshot, we're removing prefixes from CSS Gradients. The latest CSS Gradients syntax is supported in Opera with no prefix. Using an -o- will no longer work, so if your CSS still has some -o-linear-gradient hanging around, you should start to include the unprefixed version as well.

While it's encouraging to see that Opera, Firefox and even Internet Explorer 10 are accelerating the move towards unprefixing stable CSS properties, it's not all roses. The elephant in the room is of course the WebKit family of browsers, which continue to support the -webkit- prefixed stuff even in parallel with the unprefixed variants. This means that "Web developers" who only test in (or care about) WebKit have no incentive to move to unprefixed CSS, and their sites will look broken in non-WebKit browsers.

Admittedly, the history of linear-gradient has been very tumultuous, with a series of incompatible syntaxes being implemented at one time or another. Although we'd love to just support the new unprefixed standard, our testing has shown that there are many sites that use an older syntax, but do so with only a -webkit- prefix. In order to ensure Opera users don't receive a worse experience, we've included support for this older syntax when it's -webkit- prefixed. So, in Opera 12.50, the legacy syntax is supported:

background: -webkit-linear-gradient(top, white, black);

whereas the equivalent, newest syntax is supported without any prefixes:

background: linear-gradient(to bottom, white, black);

For reasons of site compatibility and interoperability, this Opera 12.50 snapshot also introduces aliasing for -webkit-background-size, as this particular property is heavily used on Japanese mobile sites. This brings the list of our aliased CSS properties to:

  • -webkit-background-size
  • -webkit-box-shadow
  • -webkit-transform
  • -webkit-transform-origin
  • -webkit-border-radius
  • -webkit-border-top-left-radius
  • -webkit-border-top-right-radius
  • -webkit-border-bottom-left-radius
  • -webkit-border-bottom-right-radius
  • -webkit-transition
  • -webkit-transition-delay
  • -webkit-transition-duration
  • -webkit-transition-property
  • -webkit-transition-timing-function

Therefore, if (for some reason) you're sending a different value to Opera than to webkit browsers, put the -o- prefixed rule after the -webkit- prefix, so the Opera one "wins" in the cascade.

You can find more information about this in our earlier article on the Opera Mobile Emulator build with experimental WebKit prefix support.