Tag Archives: web standards

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.

Opera on Acid3: 100% (and now WebKit too!)

Opera BrowserWe may soon have a winner! It looked like WebKit was going to be the first to pass the Acid3 test, passing 98 of 100 sub-tests earlier today, but internal builds of Opera pulled ahead, and have just reached 100/100!

This doesn’t constitute passing the full test, as the resulting page needs to look exactly like the reference image, but it means they’re very close.

These fixes won’t appear in the upcoming Opera 9.5, since it’s in the stabilization phase as it approaches release (just like any new Acid3-related changes in Firefox won’t make it into Firefox 3), but will probably find their way into the next major version.

We’re in the home stretch. Opera’s nearly there, but WebKit is close behind. WebKit could still catch up while Opera polishes off the rendering issues, in which case Safari would be the first browser to pass both Acid2 and Acid3.

Congratulations to the Opera team, and best of luck in the final lap of the race!

SafariUpdate: Just a few hours later, and WebKit has caught up, also passing 100/100. And as they point out, it’s a public build, one you can download and try out yourself! The race to pass is going to be very close. Though at this point, it’s almost certain that WebKit will be the first to be publicly accessible.

(via CSS3.info. More at OperaWatch and The Good Life.)

Hey WaSP Webmaster: How to Fix Acid2

With internal builds of IE8 passing Acid2, a lot of people are looking at the Acid2 test with browsers that are supposed to comply… but don’t.

It looks like there’s a server error on www.webstandards.org, and I’m trying to report it—but emailing them is just kicking back “user unknown” errors, and the spam protection on their blog refuses to let me comment, claiming that my user-agent has changed since I read the post. Um, no, I may have looked at it with more than one browser, but the one that loaded it is the one that’s submitting it.

So, Web Standards People, you want to fix your test?

Fix your 404 page.

Rows 4-5 test nested <object> support. The intent of the spec is that if a remote object cannot be retrieved, the browser will instead display the content inside it, on the HTML page itself.

One of the objects is trying to load content from https://www.webstandards.org/404/. Normally this fails, and the browser displays the fallback content — the eyes on the happy face. Right now that page is returning an HTTP status code of “200 OK” instead of “404 Not Found” — so the browsers, including Opera 9, Safari 3, Konqueror 3 and Firefox 3 beta, are all dutifully showing the content of that page in a tiny rectangle with scrollbars.

Update: Thanks to several Slashdot posters for pointing out that the test author, Ian Hickson, has a second copy of the test that points to a different URL for the <object> fallback test, and currently works as expected.

Opera passes Acid2

Opera BrowserOperaWatch reports that this week’s development build of Opera passes the Acid2 test. This makes Opera the first browser for Windows to pass! Previous browsers included Safari (Mac only), iCab (Mac only), and Konqueror (Linux/Unix). I’m sure you could get Konqueror to run on Windows under Cygwin, but it seems like a lot of effort just to run a web browser.

Opera cautioned that upcoming development builds could regress, but we can expect the final version of Opera 9 to pass the test.

Neither Internet Explorer 7 nor Firefox 2 will make any attempt to pass Acid2, but Mozilla is working on Acid2 fixes in the next version of their rendering engine, Gecko 1.9, which will likely appear in Firefox 3.