February 13, 2013 was a sad day indeed.
Opera has been around for a long time. It was publicly released in 1996 as a commercial product and is one of the early major post-Mosaic browsers.
Many of the features found in today’s Web browsers originated in Opera.
Why abandon Presto? They’ve put in too much work to just abandon it. They should at least make it open-source and let the community make use of it.
One of the good things about Opera was that it either fully supported a feature or didn’t include it at all. It is (or at least was) the major browser that probably adheres closest to the current Web standards. It’s the browser that Web developers use to check their site’s cross-browser compatibility; if it looked right in Opera, it’ll be fine in the rest of them (maybe even in IE6).
WebKit is an infectious disease. It started out as Apple’s reworking of the open-source KHTML rendering engine for use in Safari, which was released in 2003 with Mac OS X. In 2008, Google used WebKit as the rendering engine for their then-new Chrome Web browser. Even KDE has used part of the WebKit project in its Konqueror browser, from which KHTML originated. Don’t get me wrong: WebKit itself isn’t bad. But since Apple and Google effectively dominate the mobile market, and with Google’s large browser market hold, WebKit has become the de-facto rendering engine of the Web.
Sound familiar? The same thing happened with IE6 back in the early 2000s.
Back in the early days (1990s), Netscape and Microsoft Internet Explorer were engaged in a features war: each company was trying to add more and more features to Web pages by adding extensions to the HTML “standard”, and neither supported the other’s extensions. After a while, Netscape ran into administration issues and IE dominated the Web. IE’s inclusion in Windows as the default Web browser played a big role in that. IE-specific sites started popping up everywhere! View the site with Netscape and it doesn’t work properly. What’s worse is that IE6 effectively threw Web standards “out the window” (pun intended?). Have you ever heard about the IE CSS Box Model bug? It didn’t matter whether you adhered to the standards: all that mattered was that it worked in “the latest version of Internet Explorer”.
Aside: Remember IE for Mac? Until Safari came out, IE was also the default bundled browser for Mac and not Netscape because Microsoft threatened to discontinue MS Office for Mac if they didn’t.
NO! The Web is an open and cross-platform system and it should be open and compatible across different platforms. In its style guide for online documents, the W3C strongly encourages device independence (“Don’t format for a particular browser”). This part of the reason why Web standards were created! Standards provide a common set of elements and outline how they should be handled, preventing vendor lock-in. These standards—I will highlight CSS—also outline how vendors can add vendor-specific extensions for “experimental” purposes. Web developers are to use these extensions sparingly, if at all.
Standards-compliant browsers started popping up after the disaster of IE6. One of the earliest and most notable is Mozilla Firefox, which uses the Gecko rendering engine and is based on the Mozilla Application Suite (now forked as SeaMonkey), which in turn is based on Netscape. It was the pressure from Firefox that made Microsoft release IE7 as more standards-compliant (not quite there yet) in 2006.
In 2008, Google created a Web browser called Google Chrome, which used a modified form of WebKit. Hosting the most popular Web search portal, Google advertises the browser on its homepage and Chrome gains a relatively large market share very quickly.
Nowadays, everyone’s trying to copy Chrome.
As HTML 4.01 technology started to become obsolete, vendors, notably Google, started adding vendor-specific extensions to the standards, specifically CSS. Some of these extensions have found their way into the CSS3 Working Draft, but many are still prefixed. Websites wanting to use the “latest and greatest” features must use these prefixed CSS rules, which are not compatible with browsers that do not recognize the prefix. For example, WebKit extensions are prefixed with
-webkit- and Gecko extensions are prefixed with
-moz-. WebKit browsers don’t recognize
-moz--prefixed rules and Gecko browsers don’t recognize
-webkit--prefixed rules. These extensions are used by the browser to implement “experimental” functions that are awaiting approval to be put into the standard.
This creates an opportunity for site designers to design for a specific browser, usually Chrome, and ignore the rest, “encouraging” users to switch. Unfortunately, many of them do that. These WebKit extensions often have Gecko and Presto counterparts (forget Trident), and the designers are either too lazy or too stubborn to add a few lines of code to make it compatible with the rest of the major browsers.
If this keeps up, we’ll end up with works-only-in-Chrome websites, just like we had works-only-in-IE6 sites a while back:
This isn’t hypothetical, either. With the rise of these WebKit-only sites, other vendors like Mozilla, Microsoft and Opera are being forced to support these
-webkit- properties because they have, to quote,
“no other option”.
THIS MUST NOT HAPPEN!
The Web took ten years to recover from IE6, and that was when browsers were only on desktops. Nowadays, they’re on numerous phones and tablets as well as desktops.
The Web may never recover if this gets any worse!
So, it appears that Opera has decided to give up and implement WebKit instead.
I’m disappointed in you, Opera.
Apple enforces that all Web browsers for iOS must use the Safari WebKit engine.
That means that when Firefox gets ported to iOS, it has to use WebKit instead of Gecko.
I have faith that Mozilla won’t choose to switch to WebKit for anything non-iOS. Firefox just wouldn’t be right without Gecko.
Besides, how else am I going to display blinking text?
@W3C: Make these properties into standards quickly so this won’t happen!
The Web is open, and openness is about choice. Let me use the browser I want to use.