All posts tagged ‘Opera’

File Under: CSS, Web Standards

Opera Forges Ahead With Plan to Support WebKit Prefixes

Opera software will make good on its plan to implement the -webkit- prefix in the Opera web browser. To give developers a taste of what that will entail the company has released an update for its mobile emulator with support for the -webkit- prefix.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way. In fact, web developers fell in love with the -webkit- prefix and often forget that there are other prefixes as well: -o- for Opera, -moz- for Firefox and -ms- for Internet Explorer.

Now Opera says that to remain competitive it plans to support -webkit- in addition to its normal -o- prefix.

The problem, in Opera’s view, is that instead of writing code that will work in any web browser, some of even the largest sites on the web are coding exclusively for WebKit (the rendering engine that powers web browsers on the iPhone, iPad and Android phones). Web developers have, the argument goes, created the same sort of monoculture that used to exist around Internet Explorer, with websites proudly proclaiming they “work best in WebKit.”

In most cases Opera, Firefox and Internet Explorer support the same CSS features found in WebKit. The problem is that developers are only using the -webkit prefix, so only WebKit browsers render the effects. As a result, Opera, Firefox and IE look like less capable browsers even when they aren’t.

Opera web evangelist Bruce Lawson writes on the Opera development blog, “this leads to a reduced user experience on Opera and Firefox, which don’t receive the same shiny effects such as transitions, gradients and the like, even if the browser supported those effects” (emphasis in original).

Non-WebKit browser vendors first started talking about implementing the -webkit prefix earlier this year during a CSS Working Group meeting. Microsoft, Mozilla and Opera all said they felt the need to support -webkit, lest their users be relegated to an inferior browsing experience (because so many sites are using only the -webkit prefix).

While it’s not hard to understand Opera’s position, we’re disappointed to see Opera moving forward with this plan.

The very real danger is that if other browsers implement -webkit prefixes then the entire CSS standards effort will be broken.

Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes. As CSS Working Group co-chair, Daniel Glazman, wrote when Opera first floated the idea, “I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.”

We at Webmonkey hope it’s obvious that building WebKit-only sites is a mistake. If you’re only interested in iOS users then take a tip from Instagram and build a native app. As Peter Linss, Hewlett-Packard’s CSS WG representative and co-chair of the working group, said at the earlier CSS WG meeting, “there’s no advantage to the web to have someone write a platform-specific website.” There’s no real advantage for the developer either, especially when an automated CSS prefixer can do all the work for you. So, if you’re using prefixes, we encourage you to take the time to add them all, test your site in as many browsers as possible and make sure your site works for everyone.

File Under: Browsers

Speed, Web Standards Make Latest Opera Beta Sing

Opera 12 beta

Opera Software has release a beta preview of Opera 12, a coming update for the company’s flagship desktop web browser.

To give it a try, head over to the Opera Next page and download the beta. Existing Opera users should note that this is an Opera Next release so it won’t touch any of your regular Opera settings.

The new beta preview packs in dozens of new features that show Opera 12 well on its way to being the fastest, stablest Opera yet. Part of that speed comes from Opera 12′s 64-bit support on Windows and Mac. Startup and shutdown times have been reduced as well with what Opera describes as “smarter tab loading.”

Another potential speed boost will come from the experimental WebGL hardware acceleration in Opera 12 beta. Opera’s plan for hardware acceleration is to use your graphics processor to boost rendering speeds not just for webpages, but the browser’s user interface as well. Of all the new features in Opera 12 this the most experimental and will require you to enable it by hand. Check out this post on the Opera blog for how to turn on hardware acceleration and some fair warning on why you might want to wait.

This release also adds support for out-of-process plugins, which means that Flash and other plugins now run in separate processes. That means if Flash crashes, it won’t cause the entire browser to crash with it. Like Chrome and Firefox before it, Opera 12′s isolated processes feature applies to plugins like Flash, Silverlight and Java, among others.

Opera has long been a pioneer of web standards and this release continues that tradition, bringing support for a wide variety of emerging web standards like CSS 3 Animations and Transitions, and HTML5 Drag-and-Drop. The latter means that the Flickr uploader we looked at yesterday works just fine in Opera 12. (Sadly, Flickr appears to be doing some user agent sniffing so you’ll need to switch Opera’s user agent to Firefox for it to actually work.)

Drag-and-drop file uploads in Opera 12

Other new features in the Opera 12 beta include support for the Web Real Time Communication (WebRTC) standard. Opera has set up some demos to show off the new WebRTC features, including a series of apps that pull images (with your permission) from your webcam. Be sure to visit Photo Booth, Polaroid, Color Picker and Explode to see WebRTC in action.

Opera 12 adds support for the Do Not Track header, which now enjoys support in every major desktop browser save Google Chrome. Opera has also made some improvements to Opera Reader, which is now known as the proposed CSS 3 standard, Generated Content for Paged Media. Paged Media was first proposed by Håkon Wium Lie, Opera Software’s CTO and creator of cascading stylesheets. The idea is to make it easy for web developers to transform longer pages into a more book-like experience, where the reader flips from page to page instead of scrolling down one long screen.

Paged Media really makes the most sense on tablets, but the preliminary support in Opera 12 makes it easier for developers to experiment with the new features. To go along with the updated support in Opera 12, Lie has updated the demos on his site.

This release is also notable for something it doesn’t include, namely Opera Unite. Unite, which allowed you to host a simple website directly on your own computer, is no longer available by default.

Opera is not the most widely used browser on the web by any means, but it is responsible for much of the innovation we’ve seen in web browsers over the years. If you’ve never used Opera, this beta makes a good introduction, though bear in mind that it is a beta release and may have some bugs here and there. For more details on everything that’s new in this release, check out Opera’s release notes.

File Under: Browsers, HTML5, Mobile

Opera Updates Opera Mini for iPhone, Opera Mobile for Android

Opera Mini 7 on the iPhone

Opera Software has announced a slew of updates for its various mobile web browsers, including a new Opera Mini for the iPhone and Opera Mobile 12 for Android phones.

Contrary to what many may think, the real race in mobile web browsers is not between Mobile Safari and Android’s web browser, but between Mobile Safari and Opera Mobile/Mini. As we’ve mentioned before, actual mobile traffic data puts Opera just a touch ahead of Mobile Safari in the race for most-used mobile web browser.

To get the latest version of Opera Mini for the iPhone, head to the Apple App Store. The Android version of Opera Mobile 12 is available in the Android Market Place. If you’re using another platform, or have a feature phone, head to to download the latest release for your phone.

The latest release of the iPhone variant of Opera Mini adds several useful new features, including support for more than nine items on the Speed Dial page, support for the iPhone’s native dictionary and improved traffic compression on the iPhone 4 and iPhone 4S. Other changes include fixing a bug that prevented session restore from working properly when your battery died. For full details on everything that’s new in Opera Mini 7 for iOS, check out the release notes.

There’s also a new preview version of Opera Mini available, with support for what Opera calls “Smart Page.” Smart Page takes the idea of Opera’s Speed Dial — the “new tab” screen with your favorite sites just a click away, which has since made its way into all the major desktop browsers — and applies it to the social web. Smart Page gives feature phone users one-click access to social networks and news sites like Twitter and Facebook. For now Smart Page is only available on the feature phone version of Opera Mini Next, though the company plans to eventually include it on other phones as well.

If you’d like to take Opera Mini Next for a spin on older feature phones, point your phone to Keep in mind that this a preview release and there may be bugs.

In addition to Opera Mini and Opera Mini Next, Opera has also released Opera Mobile 12 for Android, Symbian and other mobile platforms. This release brings WebGL support to Opera Mobile 12 on Android, which means better support for 3D and other complex web graphics. Opera’s new HTML5 parser — which we looked at in our review of Opera 11.60 for the desktop — is also included in Opera Mobile 12.

Other new features include support for the Media Capture API, which means websites can access your phone’s camera, and more options for customizing the Speed Dial (including the same increased number of Speed Dial items found in the other releases).

File Under: Browsers

The Curious Case of Web Browser Names

Chances are your web browser is open all day, every day. Whether it’s Internet Explorer, Firefox, Opera, Chrome or Safari, the browser is the single most important piece of software most of us use. Given its central place in our lives, some history seems in order. If you’ve ever stopped browsing long enough to wonder why Safari is named Safari or where in the world the word “Mozilla” comes from, we have some answers for you.

Martin Beeby, a developer evangelist at Microsoft, has put together a nice little history of web browser names. Some are obvious — Internet Explorer came about because it was “a name that gave people a clear idea of what the product did” — some are less so, like Opera, which was apparently chosen because, among other things, “the Opera is fun.”

With the exception of Opera and IE, none of Beeby’s name origin stories come directly from the companies behind the browsers, so take all of these with a grain of salt. For instance, no one seems to know the exact origins of “Safari”, though the Beach Boys’ album seems like a reasonable guess — surfing the web, Surfin’ Safari… get it? The WebKit blog is named Surfin’ Safari, which might lend some credence to that story, but the name also nicely ties in with the notion of exploring the wild and connotes some of the same images as “explorer” and “navigator”.

Perhaps the least obvious name in the bunch is Firefox’s parent company Mozilla. Beeby cites a well-known story that the name that was derived by combining the words that were its original goal — “Mosaic Killer.” Webmonkey has heard another version of that story that claims the word “Godzilla” was the inspiration for “Mozilla,” a Godzilla-like force that would destroy Mosaic.

Beeby doesn’t offer any stories for less well-known browsers, like Konqueror, which, as the story goes, was going to “conquer” what IE and Netscape had “explored” and “navigated” respectively. The allusion didn’t really pan out, but, when Apple came along and ported KHTML to form WebKit, the developers did name their early efforts after a famous conqueror — Alexander.

For more details, and to learn where the names Firefox and Chrome come from, be sure to read through Beeby’s post.

File Under: Web Standards

Is Apple Using Patents to Hurt Open Standards?

Opera developer Haavard Moen has accused Apple of repeatedly using patents to undermine the development of web standards and block their finalization.

World Wide Web Consortium (W3C), the industry group that governs and oversees the development of web standards, requires that every specification it approves be implementable on a royalty-free basis, barring extraordinary circumstances that justify an exception to this rule. The specifications can contain patented technology, as long as royalty-free patent licenses are available.

Members of W3C—a group that includes representatives from Apple, Microsoft, Google, Mozilla, and Opera—are required to disclose any patents that they hold that are relevant to each specification. Depending on how far the specification is through the standardization process, they have between 60 and 150 days to make this disclosure.

If royalty-free licensing is available, the specification can proceed as normal. Participation in the development of a particular specification obliges W3C members to offer royalty-free licensing for technology used in that specification. Nonparticipants can also voluntarily offer a royalty free license, but they are not obliged to.

If, however, there is no commitment to offer royalty-free licensing for the patents in question, a Patent Advisory Group (PAG) is formed. The PAG will then assess whether the patent is truly applicable to the specification, and if so, how best to address the issue. The PAG might then seek prior art to invalidate the patent, or it might recommend that the specification be modified, to work around the patent. It might even advise abandonment of the specification. Only in exceptional circumstances will it decide that the specification should stand, in spite of the lack of royalty freedom.

Without an appropriate patent grant, browser vendors—whether open source or proprietary—cannot implement the specification without opening themselves up to a lawsuit. Such specifications would be, at best, an extremely risky proposition for anyone seeking to develop a browser, and none of the major browser vendors would even consider implementing a specification with known unlicensed patents.

Haavard identifies three separate occasions, twice in 2009, and again in 2011, where Apple has disclosed patents and not offered royalty-free licensing. In the first 2009 patent claim, Apple said that it had a patent covering W3C’s “widget” specification. A PAG was formed, and determined that Apple’s patent was not relevant. In the second 2009 claim, Apple claimed to have two patents covering W3C’s widget security specification. A PAG was again formed. It decided that one patent was not relevant, and the other didn’t apply. With both 2009 claims, Apple waited until the last minute to disclose its patents.

Touch Events

This time, Cupertino is claiming to have three patents, and an application for a fourth, that cover some of W3C’s touch event specification. This time the disclosure was made with about a month left to go. Again, the lack of royalty-free licensing means that a PAG is likely to be formed.

This in turn will delay the development of the specification and cost W3C members further time and money. The PAG process is not quick; the widget security PAG did not deliver its verdict until October of this year.

Haavard’s conclusion is that there is a pattern of behavior here; that Apple is trying to disrupt the standards process with its patent claims. He references the touch specification in particular—this is plainly an area where Apple has lots of expertise and interest in the technology, but the company opted out of working on the specification. If Apple had worked on the specification, it would have had to disclose sooner and offer licensing, and Haavard believes that avoiding this commitment is why Apple refused to work on the specification.

Apple’s is acting within its rights. W3C obliges members to disclose patent claims, and Apple is duly disclosing them. However, it’s easy to be sympathetic to Haavard’s argument. The two prior PAGs that resulted from Apple’s refusal to offer royalty-free patent licenses delayed and inconvenienced W3C, but ultimately on both occasions the groups decided that Apple’s patent claims were irrelevant. If Apple was hoping to keep some technology to itself, it did not succeed.

Moreover, W3C doesn’t require patent-holders to give up their competitive advantage. It’s acceptable to W3C for the royalty-free patent licenses to only cover implementations of the W3C specifications; if Apple wants to permit the royalty-free use of its touch patents in HTML5 browsers, but nowhere else, this would be an option. Such terms would allow browsers to implement the standard but still keep the technology off-limits to, for example, Android. But Apple did not offer such terms before, and so it seems unlikely that it will offer such terms this time.

Further, the only likely result of this is that Apple’s patents simply get worked around. W3C’s aversion to royalties means that it’s unlikely that it would accept any non-free license (should Apple even offer one), and the importance of touch input to phones and tablets means that W3C is unlikely to abandon the specification altogether. There’s no win possible for Apple—just wasted time and money for those seeking to make the web a more effective, more open platform.

Indeed, the result might even constitute a loss for Apple; the prior art that PAGs can uncover could jeopardize the patents themselves. The PAG subjects the patents to a certain amount of scrutiny—scrutiny that could be avoided through provision of a suitable license.

Apple has thus far not responded to our request for comment.

Apple’s work on WebKit and with W3C has undoubtedly helped the web community. But actions such as this show the company’s approach to standards and intellectual property is, at best, inconsistent, and and worst downright unhelpful: if open standards and Apple’s IP interests conflict, it’s the IP interests that win out. This may be good for Apple, but it’s bad for the open web.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.