What's new in Opera 12.10 beta
By Bruce Lawsonbrucelawson. Tuesday, October 2, 2012 6:00:00 AM
spdy, HTML5, Standards, Opera, icc, extensions, prefixes
Opera 12.10 beta streamlines and speeds up browsing for end-users, makes images more beautiful, and includes functionality that allows web developers to add user-friendly features to their pages and extensions.
Previously, snapshots were versioned as "Opera 12.50", but we've reduced the version number to Opera 12.10.
Operating System Integration
You use your operating system all the time, and need your browser to feel part of it. Opera 12.10 for Mac supports a number of new Mac OS X Mountain Lion features such as Notification Center and built-in sharing of content to social networks, and even comes with Retina Display support. Windows users aren't left out; as part of our continuing work on Windows 8 integration, Opera 12.10 beta has inertia scrolling and pinch-to-zoom on Windows 7 and Windows 8.
Opera 12.10 beta now supports International Color Consortium (ICC) profile v4, which will make photographs more vibrant and colorful, displaying them exactly as the photographer intended.
SPDY support
Opera has always been about speed, so the new release incorporates the new SPDY protocol, which makes web pages load faster on SPDY-enabled sites such as Twitter, Gmail, WordPress and (soon) Facebook. For consumers, things will just work faster, but developers wishing to see which sites have SPDY support can download a SPDY indicator extension.
Extensions
Talking of extensions, we've added several new APIs to give more power to developers. The most notable of these is the Context Menu API that allows an extension to add options to the user's right-click menu. Other improvements include the Resource Loader API, the Screenshot API and an update to our URL Filter API.
In order to ensure security for end-users, by default only extensions that are hosted by Opera may be installed, as these have been rigorously tested to ensure they're safe and don't harm a user's machine or data.
HTML5 and Web Standards
Opera is the browser that began the HTML5 specification that is transforming the web, so it's only natural that we'd be adding more support for the latest standards.
Opera 12.10 beta adds partial support for the Fullscreen API that allows video, games or web pages to use the whole screen to remove distractions like browser chrome that can divert your attention from skateboarding kittens or shooting aliens. (We say "partial" because new "HTML5 the living-on-the-edge standard" specs chop and change. This beta implements the Fullscreen API editors' draft 7 February 2012, while the standard has now mutated in the latest July 2012 version.)
There's also partial support for the Page Visibility API that allows a tab to know if it isn't visible so, for example, it could suspend resource-hungry animations or pause HTML5 audio/video until the tab returns to view.
Now that security concerns with the Web Sockets spec are addressed, we've turned on this functionality by default in Opera 12.10 beta.
User-Agent string changes
Opera 12.10 will ship with a simplified UA string. Firstly, we have dropped the "U;" token, which signified that the browser provides crypto support that is stronger than what the "international" builds of Netscape offered circa 1995. The second change is removal of the language indicator. As an example, while the UA string for Opera 12.02 on Windows 7 is currently
Opera/9.80 (Windows NT 6.1; WOW64; U; en) Presto/2.10.289 Version/12.02
today's snapshot for Opera 12.10 on Windows shows
Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.10
In a corresponding Mozilla bug report, Henri Sivonen explains why this matters. If you're interested in figuring out the user's locale, you should be looking at the Accept-Language header instead.
Both these changes correspond to similar changes in the IE, Firefox, Chrome and Safari browsers' UA strings.
CSS and Site Compatibility
Opera 12.10 beta now supports unprefixed CSS transitions, transforms, gradients and animations. For a transitional period, we'll also support transitions, transforms and gradients (but not animations) with an -o- prefix, but these will be phased out in order to promote site compatibility and leaner code.
This beta also introduces support for certain -webkit- prefixes on sites that don't correctly use unprefixed versions of stable CSS properties.
Broadly speaking, where developers haven't coded for cross-browser compatibility, Opera will treat -webkit- rules as if they were unprefixed and therefore render the sites properly so users aren't penalised.
Of course, this also has an effect on any related JavaScript events and properties - so things like the oTransitionEnd event will be dropped in favour of the unprefixed (and lowercased, as per spec) transitionend event.
If you're interested in the absolute minutiae, here is a handy cut-out-and-keep chart you can keep in your anorak pocket.
| -o- | -webkit- | unprefixed (standardised) | |
|---|---|---|---|
| linear-gradient | yes; old syntax | yes; old syntax | yes |
| repeating-linear-gradient | no | no | yes |
| radial-gradient | no | no | yes |
| repeating-radial-gradient | no | no | yes |
| animation | no | no | yes |
| transform | yes (deprecated) | yes | yes |
| transition | yes (deprecated) | yes | yes |
| border-radius | never existed | yes | yes |
| background-size | no | yes | yes |
| box-shadow | never existed | yes | yes |
"Old syntax" refers to the previous syntax of specifying "bottom left" for a linear gradient as opposed to the standardised syntax "to top right", which is supported without a prefix.
"Deprecated" means that we will remove support for the -o- prefix in a future version of Opera.
The general rule is: use the finalised syntax in your CSS, add an unprefixed property/value to your code and you'll be fine.
Changes to the behavior of innerHTML in XML documentsTake our brand survey
Comments
metude # Tuesday, October 2, 2012 8:16:47 AM
Thiemo # Tuesday, October 2, 2012 8:58:58 AM
serious # Tuesday, October 2, 2012 9:29:57 AM
Sadly the spdy-indicator link is wrong, this is the right one: https://addons.opera.com/de/extensions/details/spdy-indicator/
QuHno # Tuesday, October 2, 2012 9:33:56 AM
You can not guarantee that for all of the extensions on the add-ons page that load external JavaScript from websites. While those websites might be the websites of trusted companies, there is always the chance that they get hacked and such the computers with these extensions can become infected with malware.(...) as these have been rigorously tested to ensure they're safe and don't harm a user's machine or data.
I don't install Extensions directly from any website, not even the add-ons pages, without looking into the code before. This way I found at least 2 extensions that indeed load external code which IMHO directly violates the TOS for developers. It took me less than 10s to find the fractions of code in those extensions that are responsible for that.
Please take a closer look on that in the extensions and ask the developers to change that and remove the extensions if they don't do.
Andreas Bovensandreasbovens # Tuesday, October 2, 2012 10:47:56 AM
QuHno: "This way I found at least 2 extensions that indeed load external code which IMHO directly violates the TOS for developers." -> which ones?
Charles SchlossChas4 # Tuesday, October 2, 2012 1:37:59 PM
http://growl.info/documentation/developer/implementing-growl.php#growl2.0sdkchanges
QuHno # Tuesday, October 2, 2012 1:52:22 PM
I would really like them fixed instead of removed because the extensions themselves are great ...
... or Opera should modify the TOS and allow signed (i.e. signed like the browserJS) external scripts from trusted sites, that have a quality and security control of their own, because I think that some kinds of extensions need it and can have legally correct reasons to do that.
Yes, I know that it is not possible ATM because the extension APIs wouldn't support that.
logytech # Tuesday, October 2, 2012 2:18:30 PM
Originally posted by serious:
that links for Deutsch, for english this links https://addons.opera.com/en/extensions/details/spdy-indicator/Great article, many thanks for summing it all up
Sadly the spdy-indicator link is wrong, this is the right one: https://addons.opera.com/de/extensions/details/spdy-indicator/
MichalEmdek # Tuesday, October 2, 2012 5:49:32 PM
Like for example remaining KDE styling issues (wrong menu bar background, not fully polished context menus...) or still using ancient method for systray icon (AFAIK it is possible to have current one as fallback for those DEs that do not support it yet), lack of integration with FDo specs for notifications and maybe some other things (those are most annoying for me, I would be glad to see at least some of them finally improved).
QuHno # Tuesday, October 2, 2012 6:13:32 PM
Originally posted by logytech:
that links for Deutsch, for english this links https://addons.opera.com/en/extensions/details/spdy-indicator/
Just remove the en/ from the URL and it will sort itself out and take the UI language of your Opera install if available. Works with all extensions btw.
spillerrec # Wednesday, October 3, 2012 8:33:27 PM
Originally posted by Bruce Lawson:
Colors are still showing incorrectly on my setup.Opera 12.10 beta now supports International Color Consortium (ICC) profile v4, which will make photographs more vibrant and colorful, displaying them exactly as the photographer intended.
Example:
Opera on the left, reference on the right
Sorry, but I can't see the point of supporting embedded ICC profiles if you don't take the monitor profile(s) into account. While Bruce now longer looks like he just spend a month on Uranus, it is only useful for tech demos if it doesn't know how to display them as intended. (The example given is actually worse in Opera 12.10 than 12.02 in this particular situation.)
To give a bit more info on what is going wrong, Opera assumes all displays are sRGB while this is not necessarily the case. The gamma, whitepoint and/or gamut could be different for example. Not taking this in account will obviously result in incorrect colors. (And not just for images with profiles, UI and HTML content will also be incorrect.)
So why would these settings not follow the sRGB standard? A good example is that Apple used a gamma of 1.8 in the old days. A more modern issue is that the gamut of most monitors nowadays doesn't cover the full sRGB color space. In the screenshot I provided, the image was displayed on a wide gamut monitor.
All this only matters to users which actually have a profile for their monitors, which probably is less than 5%. So why do I focus on this minority? Because they are the only ones that could benefit of this feature. The point of ICC profiles is that the image is represented as closely as possible to the original. Those ~95% will never be able to see the image as intended even if the monitor is sRGB, simply because monitors aren't factory calibrated and the colors are normally quite off what they should have been.
Disclaimer: I'm no expert in the subject and color theory is complicated.
(Btw, note the plural in "profiles". You can have multiple monitors with different profiles, so the application actually needs to render differently depending on which monitor the content lands on. Doesn't color management just suck? )
QuHno # Thursday, October 4, 2012 5:34:17 AM
Originally posted by spillerrec:
Sorry, but I can't see the point of supporting embedded ICC profiles if you don't take the monitor profile(s) into account.
The image software should be agnostic to device dependent profiles as these should be applied by the system or, with good displays, no device profiles in the system at all should be used because the device itself uses its own calibrated internal color lookup table (LUT). ICM Profiles are just a fallback for home systems and should be loaded as start into the LUT of the graphics card. The system can't even know, if the calibration is still valid (oops -I accidentially touched the brightnes control - bye, bye black level setting - bye, bye gamma calibration) how or if the device is calibrated at all.
As it is now Photoshop and Opera show exactly the same colors here on my hardware calibrated 108% NTSC ugra certified monitor and the print results from the professional print shop match the colors exactly when viewed with calibrated D65 or D50 lighting (depending on the purpose of the print), if the image profiles are set correctly, so IMHO Operas approach is correct.
BTW: sRGB is evil when it comes to color because you can't get a decent match between sRGB and CMYK.
Apart from that:
Most of the consumer LCD screens are too viewing angle dependent and such disqualify for any proofing at all, only a very small area of such a monitor shows the correct gamma if it is calibrated. 90% of all consumer monitors I saw so far have only show the correct gamma in an area of about 5cm (2") hight. Furthermore, almost no LCD monitor shows the same color over the full height when it has to display a pure monochrome (single color) image. Look here if you want to know how your monitor performs:
http://www.lagom.nl/lcd-test/viewing_angle.php
If the Monitor does not show homogeneous colors, it fails for soft proofing. The other tests on that site are quite telling too ...
Binyamin7raivis # Thursday, October 4, 2012 1:17:02 PM
When are you planning to implement CSS3 Flexbox http://dev.w3.org/csswg/css3-flexbox/ ?
spillerrec # Thursday, October 4, 2012 9:59:09 PM
Originally posted by QuHno:
While such an approach would be nice, it would require all applications to use the same color space. As this is currently sRGB, it would mean your 108% NTSC would be reduced to about 72%. This is not the way forward...The image software should be agnostic to device dependent profiles as these should be applied by the system or, with good displays, no device profiles in the system at all should be used because the device itself uses its own calibrated internal color lookup table (LUT).
On Linux and Windows it normally works like this AFAIK: The profile consists of two parts. The first part is a LUT which aligns the colors to the tone curves of the wanted color space. 100% red will still correspond to the deepest red the monitor can display. It just makes sure that 50% red actually looks like 50% red in that color space. This part is done either by the graphic card or by the monitor.
The second part contains characteristics about the monitor. It tells what 100% red correspond to, the gamma and whitepoint of the monitor. This part is used by the color managed application so it knows what color space it needs to render in.
I'm still not confident in my knowledge in this area, so if you know better, feel free to educate me.
Originally posted by QuHno:
I do know that site and I can assure you it performs decently. While not quite as good as yours, it is a hardware calibrated monitor with a color gamut of 102% NTSC. Is it not the TN crap 95% of people have.Look here if you want to know how your monitor performs: ...
It is no way a professional proofing monitor, but with an error that large I'm confident I can tell which looks more natural. In Opera it is so over-saturated that it looks straight out bad.
Anyway, I was comparing Opera against other color managed applications and Opera was the oddball here. The image I uploaded was a screenshot, not a photo. Even if the monitor was poorly soft proofed, both applications should give the same output in the screenshot.
Originally posted by QuHno:
While I don't own Photoshop myself, according to other people Photoshop do render differently depending on what monitor it is on. (Experienced as Photoshop momentarily showing wrong colors while dragging the window over to another monitor.) I can confirm Opera does not do this, while it do happen in some of my other color managed applications.As it is now Photoshop and Opera show exactly the same colors here ...
Latest comments
-
The image software should be agnostic to device dependent pr ... -
But the survey almost completely ignores the brand product p ... -
Done. But the survey almost completely ignores the brand ... -
also done, I hope there will be some kind of public evaluati ... -
When planned Opera 12.10 stable release? When are you plann ...