Tag Archives: webkit

Internet Explorer Goes Chromium

I never thought I’d see Microsoft throw in the towel on their browser engine. Or that, by the time it happened, I’d see that as a bad thing.

But it’s true: like Opera did a few years ago, Microsoft is dropping not only the old Internet Explorer engine, but the newer Edge engine, and will be building Edge on Chromium going forward. That means Edge, Chrome, Opera and Safari are all built on the same codebase. (Chromium split from Apple’s WebKit a while back, but they still have a lot in common.)

Monoculture is still a problem, no matter who runs it. We’re already at the point where webdevs are treating Chrome like the defacto standard, the way they did IE6 back in the day.

Firefox is going to be even more important in the future, ensuring that the web continues to be built on interoperable standards instead of one stakeholder’s goals.

Mozilla is a non-profit organization, and like many, they’re running a year-end donation drive. Now is a good time to contribute to their mission to keep the internet and the web open. (I’ve already made my annual donation to them.)

I think I may want to finally shut down or retool that old Alternative Browser Alliance site I ran during the Second Browser War. The last time I made a significant update to it, Chrome was the new upstart.

Losing Opera to WebKit

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.

Webkit display:table-cell Problem

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.

Safari on Windows: What effect will it have on Opera?

SafariFollowing up on my previous post, Apple just dropped a bombshell: the Safari web browser is now available for Windows. I’ve posted some general reactions at K-Squared Ramblings as to how it will benefit web developers and users overall. The most obvious is that Windows-only web designers will no longer have an excuse for not testing in Safari, which might help break the two-browser mindset.

But what about Opera, specifically?

I remember when Apple first announced Safari for the Mac, Opera was very upset that Apple had decided to go their own way instead of licensing Opera as the new default browser. In retrospect, both sides were right: Apple was right to choose something that they could maintain themselves, without being dependent on an outside provider. (I guess they’d learned their lesson from Internet Explorer.) Opera was right that they lost a golden opportunity: as the default browser on MacOS, Safari has since become the most-used browser on that platform and the third-most-used browser overall, surpassing Opera’s marketshare.

So there’s certainly a risk that Safari on Windows could surpass Opera’s users. However, there is one significant difference: Safari is not the default browser on Windows. It’s hard to tell how much of Safari’s uptake on MacOS is due to it being the default, and how much is due to people actively liking it. Personally, I have Opera, Firefox, and a half-dozen other browsers on my PowerBook, but when I fire that box up, I generally use Safari.

If you look at the functionality available in a base install, from simplest to most complex, it probably starts with Safari, runs through Firefox and IE, then finishes with Opera. Firefox has a wide array of extensions available — in fact, it’s pretty much known for them. Safari isn’t nearly as extensible. You can’t install something that will add mouse gestures, for instance.

I suspect that, at least at first, the audience for Safari on Windows will consist mainly of the following groups:

  • Web Developers
  • Dual-platform users who are used to Safari on Mac
  • People who just want a basic browser and don’t want bells and whistles, but don’t want IE for some reason

If anything, I think Firefox has more to worry about than Opera. For every Firefox user who tricks out his browser with every 1337 extension he can find, there are probably many who just wanted something more stable than IE, or faster than IE. There’s a vocal faction of Firefox users who are frustrated with its performance. I don’t know why they haven’t jumped ship to Opera, but depending on how much memory Safari uses when it gets out of beta, it might prove a threat on that front.

Further reading:

*This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.

Safari on Windows

SafariWow. I have to admit I was not expecting this at all, but Apple has just announced they’re releasing the Safari web browser for Windows.

Increased consumer choice, of course, is a good thing. The most immediate benefit, though, is that Windows-based web developers (the majority) who haven’t been willing to buy a Mac to test their sites in Safari will be able to do full testing on all four major rendering engines: Trident (IE), Gecko (Mozilla/Firefox/etc.), Webkit (Safari) and Presto (Opera).

Also, there’s some really cool stuff available in recent versions of WebKit that will be great to have available for a wider audience.

Interesting thought: this may be the first browser released since Opera expanded to Linux in ~2000 that is available in the same version on Windows and Mac, but not Linux. Even when Internet Explorer was available for the Mac, it used a different engine than the Windows version did.

I wonder what impact this will have on the development of Swift. Its main claim to fame was porting WebKit to Windows, and it’s been months since their last release.

I also wonder what the status is on re-merging the KHTML and WebKit forks. It’s gotten to the point that Konquerer is only an approximation of Safari, making testing on Linux a little harder than it used to be.

(via Asa Dotzler)

No doubt there’s a 500-comment Slashdot discussion already.

Update: Slashdot’s all over it, and Opera Watch has a thread going as well.

Update 2: I’ve posted my thoughts on the implications for Opera. There’s an update at CSS3.info, where they have previews of upcoming CSS features available in Safari 3.

Update 3: I’ve updated the Alternative Browser Alliance to reflect Safari’s new status. This also solves a nagging doubt I’ve had as to whether the default browser on Mac OS should really be considered “alternative.” On Windows, it definitely is.

Update 4: The Webkit team and Web Standards Project have weighed in. The Windows version of WebKit should be available later today, which will be nice for following progress on issues as it moves from beta toward final version. It turns out there’s a regression and at least the Windows version no longer renders the Acid2 test correctly.

Update 5: The author of Swift says that Swift isn’t going away [edit: the blog has since vanished], and points out that “Swift renders more like a Windows Application, both in the GUI and in WebKit. Safari, looks just like OS X, similar to iTunes 6 and below.” Ever since Apple started porting apps to Windows, I’ve found something odd: A common complaint about third-party Mac software is that it doesn’t look and feel native (one of the big reasons we have Camino as well as Firefox), yet when Apple ports their own apps to Windows, it makes them look exactly the same as they do on Mac OS instead of making them work like native apps. I mentioned this to Katie yesterday and she suggested it might be a case of turnabout being fair play.