Blink! Google Is Forking WebKit 252
Carewolf writes "In a blog post titled Blink: A rendering engine for the Chromium project, Google has announced that Chromium (the open source backend for Chrome) will be switching to Blink, a new WebKit-based web rendering engine. Quoting: 'Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation... This was not an easy decision. We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem. ... In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs.'"
I wonder if blink will still identify itself @ web (Score:2)
I wonder if blink will still identify itself @ webkit for sites written that way
Re: (Score:3, Informative)
Phasing out WebKit from UA string (Score:2)
Yeah, I imagine Chrome and other Blink-based browsers will be phasing out "WebKit" from their UA just after they phase out "KHTML", "Like Gecko", and "Mozilla".
Re:I wonder if blink will still identify itself @ (Score:5, Interesting)
Which is exactly why CSS preprocessors were invented (ok, at least part of the reason).
Anyone that is using prefixes all over their style sheets is doing it wrong. It's so much simpler to simply use `border-radius: 5px` than to have to deal with `-webkit-border-radius: 5px; -moz-border-radius: 5px;` .... etc.
Just stick whatever prefixes you think you're going to need this month inside the mixin for `border-radius` and let the preprocessor handle all that prefix garbage.
Of course, you could always just be an asshole like me and completely ignore the fact that prefixes even exist.
Re:I wonder if blink will still identify itself @ (Score:5, Funny)
If it is called the webkit tag, does this mean that we'll finally see the return of the blink tag?
Re:I wonder if blink will still identify itself @ (Score:5, Funny)
Re: (Score:3)
Web developers mainly. The whole "compatibility" and "don't break any page" bullshit has always been developers' fault.
But one needs to be aware that probably, when all this started, there was no good way of doing "capability testing" instead of browser sniffing, as Javascript was there but was a "stupider" language. Also, browsers did do things in a very different way, not like nowaways when most differences are small layout issues.
There was also no automatic updates, so probably the first version of IE wa
Chrome user agent (Score:5, Informative)
If by "@" you mean "as", then, probably. I mean, Chrome's user agent string now also identifies itself as "Mozilla", "KHTML", "like Gecko", and "Safari" as well as "Chrome" and "AppleWebKit".
Re: (Score:2)
Where is the location of this webkit at which it will identify itself?
Re:I wonder if blink will still identify itself @ (Score:5, Funny)
Re:I wonder if blink will still identify itself @ (Score:5, Funny)
You forgot about the marquee tag. Protip: If you want to bring a browser to its knees, nest marquee tags.
Re:I wonder if blink will still identify itself @ (Score:4, Interesting)
Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....
Re: (Score:2)
It took the form of <blink><marquee>{Descriptive text}</marquee></blink>
Re:I wonder if blink will still identify itself @ (Score:5, Funny)
With pedigree like that it's not surprising you haven't mastered comment formatting on forums.
Re:I wonder if blink will still identify itself @ (Score:5, Funny)
It is probably hard to type correctly after having his fingers broken multiple times.
Forking is good (Score:2)
Re: (Score:2)
I wonder if blink will still identify itself @ webkit for sites written that way
You mean "Mozilla/5.0 (${OS}), GoogleBlink (like AppleWebKit (KHTML, like Gecko)) Chrome" plus a few random version numbers?
In other words... (Score:3, Funny)
"We think WebKit has become too mainstream for people as cool as we are"
Re:In other words... (Score:4, Insightful)
I was more thinking "We don't want to help contribute our improvements to all the other users of WebKit, so we're going to say 'we're forking it' rather than 'we're going to start ignoring the coding standards to make sure everyone gets supported'".
Not exactly the model open source citizens Google are often billed as.
Re: (Score:2)
At least, that's what their post says.
Re: (Score:2, Insightful)
Or maybe "Working with Apple is hard."
In the world of web browsers, this kind of fragmentation is probably a good thing. It prevents a platform monopoly and thus strengthens web standards. I would love to see all these incompatible -webkit properties go where they belong: into testing only, and only until the unprefixed property is standardized or rejected.
Anyway, it's open source and anyone is free to port Google's code back to Webkit.
Re: (Score:3)
In the world of web browsers, this kind of fragmentation is probably a good thing. It prevents a platform monopoly and thus strengthens web standards
But in the real world, more browsers means more browsers to test against. Standards are a great theory, and you should follow them, but you still have to test against every browser if you want to make sure it works.
Re: (Score:3, Insightful)
But in the real world, more browsers means more browsers to test against. Standards are a great theory, and you should follow them, but you still have to test against every browser if you want to make sure it works.
Different WebKit based browsers are already require separate testing. This fork doesn't add to the testing burden.
The following "WebKit" browsers are already different enough that separate testing is required to support them:
* Safari on Mac
* Safari on iOS
* Chrome
* Android Browser
WebKit has an amazing number of #defines, so that different browsers using it have different feature sets.
Re:In other words... (Score:4, Informative)
Re:In other words... (Score:5, Informative)
I'm not sure they can contribute their improvements terribly easily. Apple changed their development policies recently to be fairly hostile to non-Apple users of Webkit; basically, developers are allowed to check in changes that break the build on non-Apple platforms (which is enough to make development elsewhere a pain on its own because it breaks git bisect), and commits - including ones to non-Apple platform code, even ones that fix the build - now require the approval of an Apple employee with no knowlege of other platform and no incentive to approve changes important to them promptly.
Re:In other words... (Score:4, Funny)
Relax, I'm sure someone will come along and explain that it's not anti-competitive and Apple have everyone's best interests in mind.
Re: (Score:3, Insightful)
I'm not sure they can contribute their improvements terribly easily. Apple changed their development policies recently to be fairly hostile to non-Apple users of Webkit; basically, developers are allowed to check in changes that break the build on non-Apple platforms (which is enough to make development elsewhere a pain on its own because it breaks git bisect), and commits - including ones to non-Apple platform code, even ones that fix the build - now require the approval of an Apple employee with no knowlege of other platform and no incentive to approve changes important to them promptly.
Relax, I'm sure someone will come along and explain that it's not anti-competitive and Apple have everyone's best interests in mind.
It may be a balm to your soul to pretend that Apple is being especially evil here but they aren't the only ones doing this. I was recently given the task of compiling MySQL on AIX 7. It's doable but the code is riddled with stuff committed by people who don't care what else they are breaking as long as it works on Linux. Not that I'm complaining, AIX versions newer than 5.3 are not supported by the MySQL team due to "low demand" and I can easily sympathise with the MySQL team's reluctance to support it. It'
Re: (Score:3, Insightful)
Apparently you don't realize it, but that's a false dichotomy. Officially dropping suppport for an obscure platform is not in the same league as ignoring breakage on all non-apple platforms.
Re:In other words... (Score:5, Informative)
This is not true. I have been contributing to WebKit for 2 years, and overall I feel Apple reviewers are the easiest to work with.
The problem you're referring to is due to the lack of testing infrastructure on non-popular platforms. For every patch entering the commit queue, a whole set of unit tests and layout tests need to be run, and the patch will only land if none of the tests failed. Apple and Google do provide their own buildbots for each port they maintain, to minimize chance of breaking. It is not like we are hostile against other platforms. Just that without proper test coverage it is really difficult not to break them by accident, and in the unlikely event that a port break, we try to fix it or revert the patch.
Re:In other words... (Score:5, Informative)
Forking has a long tradition in open source software, webkit itself was forked from KHTML. There is absolutely nothing anti open source about it. Find yourself a new argument why Google sucks.
Re:In other words... (Score:4, Interesting)
Notably, the norm when forking is to do so because you think you can take the project in a new and interesting direction, and the generally accepted process is to make your changes as easy to integrate and work with for the original developers as possible. In fact, Apple got a very bad rap for forking (because they thought they could take the project in a new direction), and then making it difficult to integrate their code back into KHTML. Here, google are forking exactly to make it difficult for the original authors to integrate their code, not to take things in a new direction. Given the bad rap Apple (rightly) got about this, I'd suggest it would be the hight of hypocrisy to not give google a much harder time over a worse transgression.
I'm going to give them the benefit of a doubt... (Score:5, Insightful)
and see where this leads.
If they keep it cross platform compatible, keep enough of the regularly used interfaces stable for webkit to blink transitions for third party browsers (see midori, whatever kde's browser is currently called, gnome's, etc), and don't do anything ridiculously hostile to the rest of the OS community it might actually turn out better than the WebKit handling under Apple.
Re: (Score:2)
If it's 'bad' to fork a project and not contribute all your changes back, what is the point of forking in the first place? Why not just contribute to the original project?
The only reason to do so is the desire to make changes that are not compatible with the original project.
Re: (Score:3)
It's not just that; the other reason is because you're too lazy to cooperate with the original project, such as by following their coding standards, by dividing your patches up into chunks the original project prefers so they can review them effectively, by making sure your changes don't break the build for other platforms which you don't use, etc.
Not very accurate. (Score:5, Insightful)
It's not just that; the other reason is because you're too lazy to cooperate with the original project, such as by ... dividing your patches up into chunks the original project prefers so they can review them effectively, ...
This is frequently not a matter of "lazy". Often it's a matter of having a team paid programmers working 16 hours a day adding code to something, and if they are not already insiders, there's not a chance in hell a group of volunteers is going to be able to keep up with the review load unless they are independently wealthy or work for the company that already employs the team.
That's why you frequently see the team for an Open Source project that's trying to make a go of it as a business by selling support or contracting themselves out to implement features for interested parties getting their company bought out. It's why MySQL was bought out, and it's why Oracle was bought out.
I've personally been "on a roll" and generated > 20,000 lines of code in a two week period (I ended up in wrist braces for another two weeks after that). There's no way that an Open Source project is going to be able to review at that rate unless they have a huge volunteer base, and that's practically all they do. Which generally ends badly, since it's no damn fun to get involved in a project to code, and find out you're spending all your time reviewing instead.
The truly sad part is that when you are working with volunteers, you can rarely find someone willing to do the scut-work. The volunteers are there to have fun, and scut work is generally not fun for anyone. But it's necessary for productization, and as a result, productization doesn't happen. It's rare that you see commercial quality Open Source products... it's even rarer that you see actual documentation apart from "read the source".
Finally, there's the "you can't get there from here" factor. You can rarely do something truly revolutionary in small increments, and insisting that all code do a drunkards walk from where it's at to someplace truly cool is a fool's errand. You will face objections from all sorts of people; not just the people who don't want to get from "here" to "there" because they don't want to go to "there" with the rest of you. You also get objections from people who don't want things that aren't currently being used checked in. So you are caught between committing foundation work which isn't used yet, or upper level work that can't be enabled because the foundation isn't there yet.
So you fork. It's not you being lazy, it's you being pragmatic about the inertia of projects which are incapable of accepting large chunks of change that get you where you want/need to go.
It's why Apple (rightly) forked KHTML to create WebKit in the first place, and it's why Blink is forking now -- read their web site; they have a significantly different process and sandbox architecture that part of their per-DOM rendering engine model, and staying part of WebKit means carrying around 7,000 files which are totally useless to them.
Re: (Score:2)
If it's 'bad' to fork a project and not contribute all your changes back, what is the point of forking in the first place? Why not just contribute to the original project? The only reason to do so is the desire to make changes that are not compatible with the original project.
Not really. The project may consist of several parts or subsystems, and you may want to fork in order to replace or refactor one or two of the subsystems. In that case, all changes you make to one of the other subsystems should still be easy to integrate back into the original project.
Re:In other words... (Score:4, Informative)
Re: (Score:2)
Re:In other words... (Score:4, Insightful)
Except that they've specifically identified both the new directions in which they want to take the code and the problems that they have been running into trying to take the code in those direction while meeting the commitments and constraints of the upstream project (to which they are both the largest source of commits and the largest source of reviewers.)
Chromium and WebKit have divergent goals and it has become increasingly burdensome trying to reconcile them.
Re: (Score:2)
The only goal identified in their blog post announcing this was to be able to remove all the code supporting other people's work.
Re: (Score:2)
No, the norm when forking is to do so because you don't get along with the maintainers...
Re:In other words... (Score:5, Insightful)
While it would be bad to have many standards (like HTML, MS-ML, ORACLE-ML, etc.) it's good to have many implementations of that standard (WebKit, Gecko, Blink).
The ability to "delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat" is justification alone to fork the project. Another good reason from the blog is the fragile workarounds for old APIs:
Re: (Score:2)
That might be the theory. The historical reality is that multiple browser engine implementations have been a major pain in the ass for developers, who've had to code round all their quirks, and test against them all. And they've been a moderate pain in the ass for browser users, who've experiences web-sites that haven't worked well, or at all, with their browser. So just who has been served by this "good" of multiple implementations?
Re: (Score:3)
While it would be bad to have many standards (like HTML, MS-ML, ORACLE-ML, etc.) it's good to have many implementations of that standard (WebKit, Gecko, Blink).
The ability to "delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat" is justification alone to fork the project.
Who'll be the first one to call Apple a poopy head when people start removing Chromium cruft from Webkit?
Re: (Score:3)
They already have [thenextweb.com].
Re: (Score:3)
In other news today, Samsung, have very clearly said NO to this new browser direction of Google's. They're going for a different new projectwith Mozilla. And given that they are about the only successful Android OEM, that's going to be interesting.
http://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung-collaborate-on-next-generation-web-browser-engine/ [mozilla.org]
Re: (Score:2, Informative)
In favour of a better project. KHTML was pretty stagnant.
Re: (Score:2)
No one. But then, you don't exactly have to be a model citizen to be a better one than Apple.
Re:Seriously? (Score:5, Insightful)
Compared to iOS and Windows Phone, Android IS a "model open source" project. Of course, compared to other open source projects it has some serious problems, but iOS and WP aren't open source in the slightest, so compared to those two Android looks pretty good.
Re: (Score:2)
Compared to iOS and Windows Phone, Android IS a "model open source" project.
You misunderstand the word model. The girl next door might be more attractive than your wife, but that doesn't make her a model.
To put it another way, consider the classic categories Good, better, best. Model refers to "best", not "better".
Android has some open source components, but it's certainly not all open, and it's definitely not free software. It's not a model anything.
Re: (Score:2)
Oh please. Even Windows has some OSS in it somewhere. What's important is that iOS (and WP) is closed; you can't do anything you want to it. Whereas Android, you can download the whole thing yourself, and build your own version of it to put on your device (though some devices may be locked, but that's a separate issue). Just ask the guys at CyanogenMod; you're not going to see a similar project for WP or iOS.
Chromium Won't Be the Only Blinking Browser... (Score:5, Informative)
Ugh...great (Score:2, Insightful)
We could always count on WebKit being the universal web rendering engine across iOS and Android -- now, that will no longer be the case, and I guarantee you there will be instances where Google uses the inevitable differences between "Blink" and WebKit (which is also the core rendering engine for Mac OS X and Safari) for competitive advantage with Chrome, Chrome OS, and Android, al la Microsoft and IE... :-/
Re:Ugh...great (Score:4, Insightful)
There's no reason to think that. Even though Chrome and Safari both use webkit components, they are not the same browser and they don't necessarily even act the same... even now. Google could have already done what you describe, but they didn't. Web standards were far less important when IE came about than they are now. For Google to go non standard would be an incredible shock and is unlikely IMHO.
Re:Ugh...great (Score:4, Informative)
We could always count on WebKit being the universal web rendering engine across iOS and Android -- now, that will no longer be the case, and I guarantee you there will be instances where Google uses the inevitable differences between "Blink" and WebKit (which is also the core rendering engine for Mac OS X and Safari) for competitive advantage with Chrome, Chrome OS, and Android, al la Microsoft and IE... :-/
This is true already: there are visual and performance differences between different webkit browsers. WebKit is just a layout engine, whereas a full browser requires dozens of other components. WebKit for Developers provides a nice overview on this: http://paulirish.com/2013/webkit-for-developers/ [paulirish.com]
Re:Ugh...great (Score:4, Insightful)
So, you are all for the idea of being able to fork Open Source projects depending on your needs - except when it is a disadvantage to you?
I know, people will say that's snarky, but seriously, we can't have it both ways.
Re: (Score:2)
Re: (Score:2)
Well, Blink's license is still LGPL as WebKit is LGPL, so source has to be available.
Now, it depends
Re: (Score:2)
It's possible, maybe even likely Blink will be the new universal rendering engine and WebKit an Apple only thing, timeframe a year or two. I don't know if Blink or WebKit developers even want to merge between the projects. It will be interesting to see how this saga continues, the browser war have been a bit stale as of late. Not that I like browser inconsistences but I do like competition.
Re: (Score:2)
It's possible, maybe even likely Blink will be the new universal rendering engine and WebKit an Apple only thing, timeframe a year or two.
Given that the whole point of Blink is for Google to remove support for platforms other than their own, this is is either unlikely or impossible.
Re: (Score:2)
Oh no! You mean we'll have to start supporting multiple browsers? What a shock. We should go back to the utopian days of web monoculture and IE6.
Re: (Score:2)
So code to the standards and test across browsers. You should be doing that anyway.
Re:Ugh...great (Score:4, Insightful)
Re: (Score:2)
Well, for one thing, because it is open source, other browsers (Opera, for instance) will be using its code base.
Re: (Score:2)
Sure, Chrome and Opera will behave the same as each other. How does being open source prevent it from behaving differently than WebKit based browsers?
Google's co-opted the language of open source, and many within the community are taking the ostrich approach.
Don't Blink. (Score:5, Funny)
Blink and you’re dead.
Don’t turn your back.
Don’t look away.
And don’t blink.
Good Luck.
Re: (Score:2)
Crap, I think they got me and I've gone back 2039 days.
Re: (Score:2)
Blink and you’re dead. Don’t turn your back. Don’t look away. And don’t blink. Good Luck.
who said that
Yes.
Re:Don't Blink. (Score:4, Funny)
Doctor who?
To all web developers (Score:5, Insightful)
Re:To all web developers (Score:5, Insightful)
Vendor Prefixes
Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the âoeenable experimental web platform featuresâ flag in about:flags until the feature is ready to be enabled by default. Mozilla has already embarked on a similar policy.
If they put their money where their mouth is, that will be less of a problem than today. Google can still pull a "don't be evil" when they want...
Re:Stick to standards? (Score:2)
So remember, if you're developing, stick to standards, don't use custom code for each browser
We Web developers would love to be able to just "stick to standards," if only that were possible!
Consider playing audio. Simple enough concept, right? The problem is, there is no single way to play audio today, that works across all browsers! There are many issues with applying styles and positioning that simply do not work the same on all browsers, even if you do stick to standards.
Microsoft can't even manage to stay compatible with their own previous browser versions, and now there are two different fl
Re: (Score:2)
Re: (Score:2)
Google's main problem with WebKit was not rendering, but the legacy code included by Apple for support of old Macs, most importantly the networking code, which was thousands of lines of bug-inducing insanity.
By which you mean code that hasn't been used by any Apple browser for years. And that was hard for Google to ignore, while it wasn't for Apple?
Will Blink let us blink text? (Score:5, Funny)
<blink>I want to blink my text again!!</blink>
Re: (Score:2)
Re: (Score:2)
Well, just add this line somewhere in your CSS file.
blink { text-decoration: blink; }
WebKit (TM) (Score:5, Interesting)
I bet it has nothing to do with the fact that "WebKit" became a registered trademark of Apple less than a month ago.
http://www.patentlyapple.com/patently-apple/2013/03/apples-webkit-is-now-a-registered-trademark-in-the-us.html
Surprised... (Score:5, Insightful)
...it took this long. Granted, I haven't been following the happenings with rapt attention (or pretty much any attention at all), but I had always figured that Chrome's multiprocess sandboxing approach, which appeared to be made redundant with the addition of a similar multiprocess architecture in WebKit2 that attempted to take that same idea and build it into the rendering engine itself, would push Google towards forking WebKit. After all, new software coming in or switching to WebKit would be likely to switch to WebKit2 specifically, meaning that it's likely that the pace of WebKit development might slow down unless broken out as a fork.
Whether that had any meaningful impact on their decision, I couldn't say, but it struck me as odd that something like this didn't happen earlier.
Disclaimer: IANAREEOPKOTT (I am not a rendering engine expert or particularly knowledgeable on the topic)
Re:Surprised... (Score:5, Interesting)
For reference, the WebKit team's main page for WebKit2 [webkit.org] describes some of the differences between its approach and the approach that Google took when developing their own process architecture. It more or less struck me as an indication that WebKit2 would be a point of divergence for Apple and the people switching to WebKit2, and for Google, which would likely stick with WebKit and their investment in the architecture that they had already developed. Apple switched from using WebKit to WebKit2 in Safari quite some time ago, though by all indications it has not yet done so with iOS.
The fact that forking WebKit will likely allow Google to drop support for iOS (among other platforms) as they add more features and establish a competitive advantage for themselves is more than likely a larger motivating factor than this, but it's still something worth considering.
Re: (Score:2)
You have it backwards. Google did the multiprocess stuff way before WebKit2 was ever announced. WebKit2 was actually designed that way in response to Chrome. Chromium's approach was clearly one that was more secure and better overall, but the WebKit team realized it would be even better if those ideas were built into the rendering engine itself, rather than the layer on top of the engine (as Google had done) that way everyone could benefit from them.
Since Google had already invested in developing Chromium a
IE did it first (Score:4, Interesting)
Re: (Score:3)
Well, the added functionality appears to be remove the redundancy of sandboxing and multi-processing features between chrome and web-kit i.e. non rendering related - so I wouldn't be too worried yet.
Really the main issue wont be how Chrome will play, it's if the remaining WebKit developing companies keep WebKit standard compliance up to date.
Holy shit (Score:3)
If I somehow could go back a year and tell my past self that in 2013 Opera would be using WebKit, but Chrome would be using something else I would not have believed it. Yet, here we are. It's bizarro world.
Re: (Score:2)
There's not really a point where Opera is using WebKit and Chrome isn't (at least for new development); Opera's switch to "WebKit" was a switch to base off of Chromium; with Chromium forking WebKit as Blink, new Opera will now also be based on Blink.
Re: (Score:2, Informative)
Am I the only one who initially read this as: (Score:2)
"Bikini Google is Forking WebKit" and had to do a double-take?
Re: (Score:2)
Probably. When is spring break?
V8 (Score:2)
Re: (Score:2)
What's the reason for this anyway? (Score:2)
Re: (Score:3)
How do you figure? If Blink becomes better than WebKit, what's to stop Apple from dumping WebKit and switching to Blink? Or just forking it back? After all, it's not like Google is going to suddenly stop supporting OS X with Blink, given that they'll be using Blink in Chrome, which is available for OS X. They may drop iOS support, but iOS is based on OS X so I wouldn't think that updating it would be too difficult in the grand scheme of things. And if they do drop iOS (which would be a rather huge dick move
Re: (Score:2)
Doesn't Apple control commits for WebKit? Having Apple in control of something is rarely good for anybody but Apple.
Re: (Score:2)
I won't disagree with that statement (despite being an Apple fan). Even so, we're talking a definite evil vs. a hypothetical evil. Google has cited their intent to drop compatibility for various platforms as a motivating factor for this decision, which is a decidedly not-cool thing that Apple has apparently been keeping from happening, so even though I may agree that Apple's control is usually a bad thing for others involved, in this case it seems to have worked out for the best of most people involved. The
Re: (Score:2)
"Google has cited their intent to drop compatibility for various platforms as a motivating factor for this decision"
My reading was that they wanted to drop code that existed for compatibility for older Mac platforms, but I got the distinct impression that part of the desire comes from Chromium itself already not supporting these. Perhaps I'm mistaken, though.
Re: (Score:3)
And if they do drop iOS (which would be a rather huge dick move, but one that would make business sense), wouldn't that be rather evil of them?
Apple doesn't allow any browser engine besides their own WebKit implementation on iOS.
So removing iOS support from Blink seems to be a given, because it can't be used anyway.
So if there's a dick in this equation, it's most certainly not Google.
Re: (Score:3)
Smaller browsers are sorta screwed... but I think WebKit2 is likely to be the better option with what we currently know...
- WebKit2 is essentially WebKit with multithreaded sandboxing baked-in; the whole point was so anybody who uses WebKit2 will get the multithreaded sandboxy-goodness free. At least on Windows and OS X. On Linux, WebKit2 is still in development, as most apps use a widget toolkit like Qt or GTK+; Linux developers have to wait for the toolkits to add in support. Qt is targeting version 5, a
Re: (Score:2)
This is idiotic.
Apple did exactly this with Webkit, which is a fork off of KHTML.
Re: (Score:2)
Did Apple say "thank you" to KDE?
Re: (Score:2)
Yes. On day one.
http://lists.kde.org/?m=104197092318639 [kde.org]