Shared publicly  - 
Mark Bridge's profile photoLeigh Garland's profile photoThomas Belin's profile photoPhred Lane (fearphage)'s profile photo
Be interesting to see how this works out for +Opera, if users would move to/stay with Opera for the UI/UX if the rendering engine is the same as #Safari and +Google Chrome.
I don't know what to think about this, I'm in two minds about it. I don't think this decision will necessarily result in a less standards compliant Opera browser, a website that works perfectly in Chrome may not work perfectly in Safari even though both of those browsers are running WebKit. Opera could still branch WebKit and Chromium/V8, strip out all of the crap, and stick strongly to standards.

On the other hand, part of my brain couldn't care less if Opera vanished altogether (just being honest). Compared to other browsers Opera's user-base has more or less flatlined over the last few years so I understand why a lot of website developers no longer consider testing their websites in Opera - if a website works in Chrome, Firefox, MSIE and Safari then it works for 99% of potential website visitors.
And here I had no idea that there was a Douglas Crockford of browsers.  Where have I been hiding?
This is a win for anyone that writes web client code. Albeit that Opera has always had small market share. If the market gravitates towards webkit, so be it. At least we have a consistent rendering engine. It's probably one of the best choices to standardize to.

The happiest day of my life is when Mozilla and Microsoft use webkit for Firefox and IE. I will have some time to actually talk to real people, instead of debugging IE/Trident inconsistencies all day and night long.
Sounds like a good thing to me. Now IE should also make the switch.
+Robert Whiting the analog you are probably thinking about is when IE had 90%+ market share. 

Let's assume, in a magical world, that all major browsers use webkit as their rendering engine. I don't think you'd get the same situation, for several reasons:

1- The BROWSER, not the rendering engine, is the product. That is what is sold to the customer. Individual browser makers will continue to push their products, irrelevant of underlying engines.

2- Webkit is open source. There is nothing stopping individual companies from making innovations if they feel that the rest of the party is slowing down... which brings me to my third point...

3- Apple's safari, and Google's chrome/chromium, don't run on the same exact code base. Both companies, at the time of their choosing, submit patches to the upstream webkit project, which maintains the "one true" version of the rendering engine.

You still have competition, you still  have innovation, but you have a more consistent web platform, which makes it easier for programmers, which in turn providers more and better apps for users more consistently across different browsers. Where is the loss?
+Enmanuel Rivera this is simply not true. Just because Webkit is under the hood doesn't mean that browsers don't have massive rendering differences. Compare Safari on iPhone with the custom Android browser and Chrome on Desktop. You will find a lot of differences. There is no "one webkit" and it will not make it easier for us as developers. The same way IE5, IE6, IE7 and IE8 differed and weren't the same. Or Firefox on Linux and Firefox on Windows. Or Chrome on Desktop and Webkit on Playstation in the version Netflix built. If you think you can build things that look and work the same for every end user out there then don't build things for the web. This is not playing to its strengths.
I would even go as far as to say that WebKit currently is the least stable rendering engine out there at the moment. Too many regressions, too many weird rendering bugs related to css2 properties.  Every time Chrome updates I pray that nothing breaks ... 
I have to disagree -- the Opera team's worked really hard over the years to keep up, but for complex behavior it's always been extremely difficult to make things work in Opera. I can't count the number of rendering and interaction bugs I've tried to work around in Opera, usually triggered by CSS edge cases and dynamic updates. WebKit and Gecko tend to handle them all quite well, but I always dreaded testing Opera because I knew I was always going to hit some weird rendering edge-case for which there was no workaround.
Existence of projects like jQuery are evidence of the weakness behind the W3C's standards.

This lamentation seems to say you'd like someone else to pay attention to the you don't have to.

Should be able to read a standard, write accordingly, and never have unexpected outcomes (which is the nature of a bug is it not?).  But this is not the case.  This "look good" method of development, where one hits F5 every time a snippet is modified bothers me.

I don't use that mentality when I write a line of OCaml, Python, Ruby, Delphi, PHP, or C.  Need a solid well known framework to create beautiful code.
+Christian Heilmann Yes, you are completely right. I didn't argue against that. On the contrary, I said that was a good thing.

Just because different browsers use webkit, doesn't mean they will have EXACTLY the same rendering. Webkit is open source, and most browser vendors modify webkit. Some more heavily than others. Their ability to modify webkit to suit their needs will guarantee that we will still have browser innovation. It's not a locked down engine that they can't play with.

However, the differences in rendering between different webkit implementations are much smaller and less dramatic, than the differences between browsers that use different rendering engines. Especially the 11th plague, also known as Internet Explorer.

I am not arguing against web standards. It's a great thing that the web is flexible, and can cater to different device types. I understand that you can't expect everything to look exactly the same in every browser, and I acknowledge that as a strength of the web as a content and functionality delivery platform.

However, I and many other people need to get stuff done. That's the simple truth. Rendering inconsistencies take up way too much time dev time. That time could be spent making more apps and better apps.
Doesn't this just mean that Opera's obsessiveness to build a great browser will just get included in Chrome?  Doesn't this just mean WebKit can move faster?

Doesn't this just make the Chrome Army against IE even stronger?

I want even IE10 to die.  Sure the rendering engine is finally on par with say Firefox, but it's a long throw from webkit, and it's developer tools suck total balls.  IE can't debug inside iframes, it can't inspect live HTML changes, and it must refresh those changes in the dom, collapsing it anytime you need inspect it.

If MS wants folks to build HTML5 apps for Windows 8, they need to get a real web development kit together.

Maybe HP can sell the what's left of the WebOS team to MS, but this shit needs to get better and Opera deciding to play for the wining team will only help MS light their own fire under their ass.
It's a shame that Opera's devs are basically throwing in the towel. Presto was always the fastest browser for me on low end PCs. Chrome does an okay job, but sometimes it just takes up too much memory to run well enough on any PC with less than 2GB of RAM even if you keep it to a single page (especially around Google's own weighty sites). 
To be honest you are missing the big picture. Everyone developing on one platform helps the internet move forward faster. There is too much convolution on the internet right now. If only everyone would take standards more seriously and actually ALL develop on 1 platform instead of thinking of their BRAND then think where we would be... Take your own website for example.  The sidebar's css rules are fucking redundant because of the damn browser prefixes.

-webkit-transform: rotateY(-15deg);
-moz-transform: rotateY(-15deg);
-ms-transform: rotateY(-15deg);
-o-transform: rotateY(-15deg);
^^======    WTF   ======^^ 
transform: rotateY(-15deg); 
+Robert Johnson I think the author of the article just commented on that and stated from his knowledge webkit implementations can render differently, which would make sense. There may be a finite number of ways to render something as simple as rotations or images, but I've experienced two browsers with webkit render the same page differently (no addons or adblocking software in the mix). 
One webkit - one browser. I don't want to go back to Internet Explorer dominance from mid 90's !!!
+Robert Johnson browser prefixes have nothing to do with a brand. They were there to test things out without breaking the web. That people used webkit prefixed things as the only setting in their code forces commercial companies like Opera to take drastic measures like this. Does this make the web better? No, as prefixed code is meant to change and not be relied on - and in all cases is meant to vanish once the functionality has been standardised. If you look at the mobile web though you find that people use white text on white background as the background is defined as - webkit - gradient only. Same with transform. My sidebar still works as I ended with a non-prefixed transform. If I only cared about - moz - or - webkit- it wouldn't work. I spent about 20 seconds adding these other lines. No skin of my nose.

No biggie in this case, but a very big issue when your web site says "have webkit or you don't get in". This is not the web, we can not - let me repeat this (and I am speaking from experience since 1997) - we can not demand from our users to have anything we have. As a movie producer I can not expect people to have a 42" high def TV, that would be silly to produce only for those, right?

Browser prefixes are a first step to try things out and make them work in a certain browser before you standardise them. It was us developers who made them a dependency and this is where everything went wrong. There is no one webkit, there is no consistent rendering and performance across all browsers and devices. If you start embracing this idea as a developer and start building things that are flexible enough to use what different environments offer you but also not lock out others then you are a web developer. If you crave a closed environment where everything works pay up and become a certified developer for one platform using only one tool and waiting for the next version of the platform for every new feature. The web is open, our users have every right to choose whatever they want to consume it. We create the experience how to consume that content and need to be flexible. Instead of celebrating that creative challenge we complain constantly that things aren't fixed. Can we stop doing that? I'd be bored stiff if every browser, computer, resolution and speed were the same. I love that I can read a blog on my macbook air, my mobile device, write a script to read and convert the RSS and resize it to my tablet. I love the challenge to give the best experience to various users of different abilities. This means more work, but I also reach more people. This is what to focus on. We need to beat TV and closed platforms, not wave the banner of one browser or another.
The right to consume web content should never be determined by the device, speed or browser that I have. If we violate that we might as well write native solutions.
Disliked for the ponyfaggotry. Also you just runined my favorite browser, asshole.
+Christian Heilmann 1. The prefixes do have to do with the brand or there wouldn't be a reason for anyone to do anything different than what standards lies down. 

2. It may have taken you seconds to write in the extra browser prefixes, or as I call it Bloat code, the browsers read everything CHARACTER BY CHARACTER. So this means the more companies that decide they have to try to grab their own piece of the market share just make the job of the developer harder, and the rendering on all browsers suffer.

3. I never said it was okay for Apple to not allow other rendering engines on their phones. Again that is the very thing I am against, that is a company that is blinded by its brand.

The whole point of my comment was not to troll you or your wonderful website, it was just simply to try and look at the bright side of this situation. It was a brilliant article and I definitely see where you are coming from, but as they always say 2 brains are better than one. So now with 3 multi-million/billion dollar businesses putting their heads towards one webkit goal it could mean the birth of a better standards compliant world and then resource consumption can come down as well. Now if only microsoft would get their shit together and switch to webkit ;P
+Norea Herbrechtsmeier This is very true but as I said in my reply to the author, I think with the amount of resources all of these companies have and now that they all have a common stake in webkit all of them can help craft it to be the best engine for the people instead of having a prick fest, as George Carlin would call it, and saying their engine is the best.
+Robert Johnson this is not how standards work any longer, for good reason. In the past we made up standards and browsers innovated according to their needs. That's why we have different event handling in IE and other browsers. Now things become standardised that have working implementations in two browsers so we ensure that what we standardise is really in use and proved as working. requestAnimationFrame for example came from Mozilla, got taken on by Chrome and now is a standard. CSS gradients came from Apple, got a much simpler syntax in the Mozilla implementation and then got taken on by Chrome and standardised and is now available in the Mozilla proposed syntax by all. Same with geolocation or the battery API. We need to test and implement in non-lab conditions to say this is a standard people should follow.

Browsers do not read CSS character by character, prefixes can add to the overall size of the CSS and that is an overhead, but the amount of CSS is the least of the issues when it comes to performance of CSS (adding lots of gradients and dropshadows is though). I agree that it seems superfluous to have all that code, but to try things out it is right now needed. In the future we might be able to have developer flags to test things out, but for now this is needed.

It is very important that we try things out in different platforms and submit them as standards proposals. Once browser vendors agree that the implementation is working we have a standard. That's why it is such a massive blow that Presto is gone, as testing a standards proposal in 4 engines gives us a lot more bug reports and test data than in 1 or 2.
+Christian Heilmann lol yet again I was just giving some silver lining type thinking. I understand how standards work and I can see with my eyes how the same effect changes from engine to engine so don't act like adding a -blah in front of what is standard for each browser makes it somehow uniform. The point is to conform to one way so we can move forward together and think of whats next instead of everyone implementing what they THINK is best. 
+Robert Whiting
Couldn't you also say that browser vendors and platform providers only supporting HTML/CSS/JS and not other content like that generated by plugins is vendor lock-in for the webs future (maybe even for computing devices in general)?
+Robert Johnson
I think the problem is that developers shouldn't be using vendor prefixes on live sites. They should just be used for testing and learning.

I think this is the fault of the browser vendors. They should have never allowed vendor prefixes to work by default in browsers. They should have been something that had to be turned on in the browser manually by the user that put the browser into something like a development or beta mode.
Why is my little pony in this thing?
For people who are interested this guy made a chart a while back about various implementations of webkit for mobile to show that there really isn't one webkit:

The Great WebKit Comparison Table
On this page I compare 21 WebKits in order to prove that there is no “WebKit on Mobile” and to figure out which one is the best. My hope is that eventually I’m going to gain some insight in the “family tree” of all WebKits.

What do you think about LESS CSS to avoid typing alot of prefixes ?
+Guillaume Liautard
I think things like LESS are a blessing and a curse. It helps solves problems but in a way also enables them from needing to be resolved.

Really I feel like web tech in general is a jumbled mess right now with a lot of cross-over tech.
Add a comment...