Opera RingThe reporting is a bit confusing, but it looks like the Opera web browser has been sold to a Chinese consortium. The group wanted to buy the Norwegian company outright, but the bid failed, and they fell back to an alternate deal.

According to NewsWeb:

The following business units of Opera will be included in the Transaction:

· Mobile Browser, including Operator Co-brand solutions
· Desktop Browser
· Performance and Privacy Apps
· Opera’s technology licensing business outside of Opera TV
· Opera’s 29.09% ownership in the Chinese joint venture nHorizon

The Consumer Business will be reorganized into a separate company structure. For
clarity, the following businesses are not included in the Consumer Business or
the Transaction:

· Opera Mediaworks
· Opera Apps & Games (including Bemobi)
· Opera TV

It’s a shame to see Opera broken up and dispersed…but in a way, that already happened years ago. When they switched to WebKit in 2013, they lost what made them unique and (IMO) valuable: They’d been a solid third-party (well, fourth-party) that helped keep the web from collapsing back into a monopoly. Within a year the community portal was gone as well.

Since then I’ve only bothered with the desktop browser occasionally when I need to test multiple sessions at once. I used to keep a copy on my phone for times when I was stuck on a slow connection, but these days the cell network in my area is a lot faster. When it gets slow, it’s also unstable, so compression doesn’t help much.

VivaldiI think I will check out Vivaldi again, though. Founded in part by Opera co-founder Jon von Tetzchner, it started as a new home for the Opera community. When I first checked out their browser, it was a really rough preview, but it’s at 1.2 now. While it’s using Blink as the rendering engine, they seem to be trying to innovate through the UI instead, with a heavy emphasis on customizing everything.

(via Slashdot)

Opera IconIt still feels like an April Fool’s joke, but Opera is in fact switching to WebKit and discontinuing their own engine, Presto.

I can sort of understand. They can stop worrying about the long-running headaches of browser-sniffing websites that assume Opera can’t do things that it can. They can focus their efforts on the features they want to add or enhance, instead of maintaining their own separate codebase.

But here’s the thing: Throughout its history, Opera has served as a check against monoculture, against a single engine dominating the web too thoroughly. And now, it’s embracing the engine that dominates the fast-growing mobile web.

Remember the bad old days when people just wrote for Internet Explorer, and there was basically no innovation in web browser capabilities? It took Firefox’s success to turn the tide, but Opera was there, needling the industry with things like the “Bork edition” which turned the tables on browser-sniffing websites. Opera was a constant reminder that no, the web isn’t just Internet Explorer and Firefox, or just Internet Explorer and Webkit, or just two flavors of WebKit. That it was worth building technologies to leverage cross-browser web standards instead of picking the current 800-pound gorilla and feeding it even more.

There’s a real value in having different engines approaching the web in different ways, because it prevents stagnation. And there’s real value in having different engines use different code, even when implementing the same capabilities, because that means when a security flaw is found in one browser, it doesn’t apply to all of them. I go into this in a lot more detail in the old, but IMO still relevant article, Why do we need alternative web browsers?

The problem, of course, is that as much as I appreciate that role for Opera, it’s never really been their goal. Opera’s purpose is to sell web browser-related services. In the past, an open web was necessary to do that. Now, they’re throwing in their lot with the front-runner instead.

That leaves Mozilla, whose mission actually is to promote an open web, to go it alone. Apple and Microsoft certainly don’t care. And Google only really cares to the extent that their services are available as widely as possible. And when you get onto mobile, all three prioritize getting you into their particular silo.

Webkit browsers are a dime a dozen. The only ones that really matter are Chrome and Safari, and Safari is a lot more important on iOS. Opera will soon be just like Dolphin, Rockmelt and others that I have to rack my brains to remember. Maybe it’ll be enough for the company to survive, but it won’t be enough to keep them relevant.

Opera logo and Opera Unite logoThe Opera web browser has introduced a lot of cutting-edge features* over the years, many of which have since become standard in other browsers like Firefox, Chrome, IE and Safari. But they’ve also introduced features that didn’t catch on. With Opera 12, released yesterday, they’ve taken the first step toward removing Opera Unite and Widgets.

Opera Unite was a fantastic idea to move beyond the standard client-server model that dominates most internet activity and take peer-to-peer communication to the next level. Instead of relying on central servers like Facebook or MSN or Gmail, you could run a chat room, photo gallery or other application directly from your computer.

It never really caught on. If I were to guess why, I’d say that the big reasons were security concerns (turning your computer into a server!), the rise of easy-to-use cloud services, and the increasing move toward mobile computing. It’s one thing to let friends remotely browse a photo gallery from your home desktop that you leave on all the time. It’s another to have them view that gallery data from your iPad over your sketchy and bandwidth-capped cell connection.

As for widgets, they were sort of an odd thing to begin with: not quite applets, not quite extensions, and in competition with native widgets on both Windows and Mac OS that didn’t depend on having a browser open. (Though these days, when don’t you have a browser open?) Honestly, I’m still somewhat mystified as to why Opera created them in the first place.

Opera 11 introduced an extension system, and they’ve released a reference on converting widgets to extensions.

Widgets and Unite are still present in Opera 12, but turned off by default for new installations, and will be removed from a future release “before the end of this year.”

*I still disagree on the issue of tabs, on the basis that a tabbed interface is distinct from MDI.

It’s not a huge surprise, with all the major web browsers adding their own bookmark sync services, but Xmarks (formerly Foxmarks) is shutting down in January.

I figure I’ll just use Firefox Sync, Chrome sync, Opera Link, etc. to share bookmarks between the desktop and laptop, but what I really liked Xmarks for was its ability to sync different browsers together. I’m always switching between Chrome, Firefox, Opera and Safari (and occasionally IE when I’m on a Windows box) and it’s nice to have them all on the same set of bookmarks.

I guess it’s back to periodically exporting from my main browser and importing in the secondary ones, unless I find a tool or find the time to read up on the bookmarks formats and write one.

Update: Xmarks lives!

Update 2: And now it’s dead again, for good this time. These days I use Floccus Bookmark Sync (my review).

I recently tried to retrofit a mobile layout onto an old table-based site using CSS. It was a fairly simple layout: A banner across the top, two columns, and a footer. I figured I’d use CSS to “unwrap” the table and make the sidebar and main content area into full-width sections instead of side-by-side columns.

In theory this should be simple: CSS handles tables by using the display property and assigning it table, table-row and table-cell for the <table>, <tr> and <td> elements. You can assign these properties to other elements and make them act as tables, or you can assign block or inline to these elements and make the table act like a series of paragraphs.

Initial testing worked perfectly in Firefox 3.6 and Opera 10.5x. Internet Explorer 8, as expected, ignored the changes entirely. Chrome, however, did something very strange, and Safari reacted the same way: The banner shrank, and the columns changed from a narrow sidebar to a 50/50 split…making it actually worse for small screens.

Clearly WebKit didn’t like something I was doing. Unfortunately, WebKit powers the exact platforms I was targeting: the iPhone and Android!

I dug around with the developer tools a bit to see if I could figure out what was going on. Was the browser not applying the property? Were the table cells inheriting the “original” property from somewhere else? Did I need to change properties on thead and tbody as well?

What I found was that WebKit did recognize the display:block I had added, but somehow the computed style was reverting to display:table-cell. This only applied to table and td, though. Table rows actually did what I told them to, which was why the result ended up looking bizarre.

If it hadn’t changed anything, I probably would have chalked it up to the capability just not being implemented yet. But since it worked on table rows, but not on cells, I decided to treat it as a bug in WebKit and went looking for the best way to report it. I ended up creating a WebKit Bugzilla account and reporting it as bug 38527.

Check out the testcase in Firefox 3.6 or Opera 10.5 to see what it should look like, then take a look in Chrome 4 or 5 or Safari 4.