Slashdot Mirror
Blink! Google Is Forking WebKit
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 @ webkit for sites written that way
"We think WebKit has become too mainstream for people as cool as we are"
Opera has said that they will also be moving to Blink as they transition away from the Presto engine.
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... :-/
Blink and you’re dead.
Don’t turn your back.
Don’t look away.
And don’t blink.
Good Luck.
I've seen web developers tout for years how great webkit was and so they built specific features with the webkit functionality in mind. This is the same group that hates and laments (and very rightly so) IE6 for not using web standards. It is nice to see the entire process go full circle :)
So remember, if you're developing, stick to standards, don't use custom code for each browser and please remember that not everyone has a locally cached version of the page on their machine - load times do matter.
I imagine most browsers will start sending a UA with both blink & webkit and then slowly phase out the webkit token.
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".
by "slowly phase out," i mean each individual browser (for now just chrome & derivatives) will make the decision on their own time when to remove the webkit tag. probably when blink and webkit have diverged significantly.
so, as Mozilla? ;)
Maybe that will be the browser's default unless NOBLINK is specified.
I'm sure Google will take this opportunity to add native bindings for Dart, which will make dart a whole lot more interesting now.
Where is the location of this webkit at which it will identify itself?
We bloated WebKit to the extent it's not usable now, let's start from scratch!
And its the one that will kick you to the curb vis-a-vis a fork that takes what you've built and moves it in a direction you can't build on without a massive effort.
<blink>I want to blink my text again!!</blink>
Blink and you're dead.
Donâ(TM)t turn your back.
Donâ(TM)t look away.
And donâ(TM)t blink.
Good Luck.
Slashdot is letting me down.
I knew I heard a collective gasp and crying off in the distance. Now I know what I was. Soon all those lazy jerks who design only for Webkit will have to do their jobs again.
EJECT EJECT EJECT
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
Don't blink!
...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)
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.
Someone flopped a steamer in the gene pool.
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.
Who on Slashdot, besides the paid shills/editors, actually thinks of Google as a "model open source" citizen at this point?
I get the whole need to fork thing... but why name it after the most annoying non-standard tag from the 90's? Someone in marketing should be sacked.
Tomorrow is another day...
If I remember it right from ye olde days, it would be "embrace, extend, exterminate". They already embraced webkit, which is now some de facto standard, now they'll fork it, which implies some added functionality in the process, and you people know the rest. we are still trying to get off IE's dark era.
By that measure, none of the browsers have diverged significantly from Mozilla.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Oh shut up, this is nothing like MS and IE. Blink is open source.
Yeah who cares if it has differences from webkit, it's all open source! If it doesn't work you just download the source code and a compiler, fix it to work like webkit, re-compile, root your device and deploy your new fixed version, sounds perfectly reasonable for everybody, hooray for open source!
Blame Microsoft and web developers.
Does this mean that browsers that currently use webkit would be able to go multi-threaded sandbox more easily?
Chromes move to sandbox each tab in its own thread may have been the biggest noticeable improvement in browser performance I have seen. (So many times I have gone to a bad website and had Firefox completely freeze up). But at the same time I am a firm believer in a minimalistic approach to a web browser.
Advertising is being as annoying as possible.
Couldn't they even say "thank you"?
Am I part of the core demographic for Swedish Fish?
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.
Pretty good is actually pretty bad.
You forgot about the marquee tag. Protip: If you want to bring a browser to its knees, nest marquee tags.
"Bikini Google is Forking WebKit" and had to do a double-take?
STOP . AMERICA . NOW
Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....
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 was there along with the improved version, so if you just sent frames to everyone, old IE versions would break.
Still, there is no excuse in doing this nowadays, period. Browsers should break the goddamn sites that still do this, and for developers: if you haven't updated your site from the time when this kind of browser sniffing was required, please get out of the internet, you are making it a worse place.
Opera was the only browser that really tried to not spoof any other browser's identity (unless required). When it got to version 10, it broke many pages.
not even mozilla and internet explorer originally diverged from mosaic :) (I know, lots of work has been done since)
If Google do as good as job with Blink as they did with V8, I think this could put Chrome way ahead of the others and make it an incredibly advanced and fast browser, even more than it already is. I'm excited to see what Chrome will be with Blink in a few more versions.
If it is called the webkit tag, does this mean that we'll finally see the return of the blink tag?
signature is pants
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.
I'm not sure it's possible to fork it up more than it already is.
Embrace, extend*, extinguish
*you are here
Long ago, whenever I was developing a webpage, I would include a message to note that the page was my development copy.
It took the form of <blink><marquee>{Descriptive text}</marquee></blink>
I hate grammar Nazi's.
With pedigree like that it's not surprising you haven't mastered comment formatting on forums.
If Apple had done this, people would be shouting about Apple trying to do something "proprietary" and making sure they were incompatible. Or some such idiocy.
That would be idiotic, because creating an open source project is the opposite of "proprietary". If you are going to invent a straw-man, please make it less of an idiotic straw-man.
But people who love Google are willing to make up whatever excuse they need to make up to support almost anything their beloved company does.
Huh? You say above that it is "idiocy" to criticize this move, and then say that people need to make up an excuse to say it is good? Make up your mind!
The whoosing sound... what is that? Where are you? You don't know where you are?
This is idiotic.
Apple did exactly this with Webkit, which is a fork off of KHTML.
It's hard to tell whether you're truly ignorant or you're just trolling. Apple was never a part of the KHTML project, so they never worked with those guys. They simply picked up their code and started using it when they wanted to launch a browser. Apple and Google have been working together on WebKit for years now, and Google is splitting off to go its own way. The two situations aren't even close to analogous if you actually know what happened. This would only be similar if Google had never had a browser of its own and never contributed to WebKit and then announced that they were going to create an engine of their own based on WebKit. There's nothing WRONG with it, but I'm amazed at how fanboys treat the two companies very differently and have "selective" memories about the past.
Oh to be a developer that contributed to the 4.5 million lines of code that is being "scrapped"
Good leaders run toward problems, bad leaders hide from them.
Apple *did* fork Webkit from KHTML. Google is just forking Webkit, nothing more, and nothing special. Apple can always take any version of Blink and fork that too.
" I'm amazed at how fanboys treat the two companies very differently and have "selective" memories about the past"
No, it was *you* that forgot Apple forked Webkit from KHTML. You are just trying to pretend they didn't, or that it doesn't count somehow as a fork.
I wonder if history will show that the old saying applies here: "Blink and you'll miss it."
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 flavors of IE 10 (RT and desktop) that aren't totally compatible with each other!
If only life were so simple that we could just "stick to standards"!
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".
I'm guessing it's a reference to the staring contest between Google and Apple over who would control WebKit. Google Blinked.
"exterminate" isn't possible in open source. Apple could take Blink and fork that.
The funny thing is, supposedly, Blink really is named after the obnoxious HTML tag!
This CNET article has an interesting explanation:
Quoting from the article:
The Blink name is a reference to the despised and now extinct blink tag of early HTML that made text blink off and on. It follows the pattern of Google naming projects after what it deems relics from the past: Chrome is designed to minimize user-interface "chrome" that surrounds Web pages; the Chromebook Pixel's high-resolution screen is designed to make pixels disappear; and Blink is designed to do away with browser engine irritations.
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?
PlusFive Slashdot reader for Android. Can post comments.
But will it require a dongle to run?
I was promised a flying car. Where is my flying car?
Big difference is that other developers besides Microsoft weren't allowed to embrace, extend, etc IE6. But here Google is allowing other opensource developers to do their own embrace and extend, so at worst the third part is likely to be a repeat of step 1: embrace, extend, embrace fork.
Which browsers doesn't <a href="someaudio.mp3"> work in?
Or did you mean "play audio without the users permission", like Flash ads?
there is no single way to play audio today, that works across all browsers!
Unless you're talking about IE https://developer.mozilla.org/en-US/docs/HTML/Element/audio
I fully agree with the styling issues though. Browser-specific hacks FTW!
$(echo cm0gLXJmIC8= | base64 --decode)
meant to say:
Unless you're talking about IE < 9, yes there is: https://developer.mozilla.org/en-US/docs/HTML/Element/audio
$(echo cm0gLXJmIC8= | base64 --decode)
Ah, I see. "Out-of-Process frames" means better management of advertising.
It is probably hard to type correctly after having his fingers broken multiple times.
Learning HOW to think is more important than learning WHAT to think.
Oh God, I had forgotten about those. Now I'm beset with horrifying flashbacks to my very first webpage, that blinking, rolling, animated hell. I even changed the cursor and the color of the scroll bar!
Error: No error occurred
Chrome blazed the trail on multi-process isolation of the web engine (so one ill-behaved tab doesn't crash the whole browser among other things) but that trail was built above the WebKit API layer. The WebKit team implemented a similar model, but cross-platform and inside WebKit itself so anyone using WebKit can take advantage of it.
Google has a lot invested in Chrome, so it doesn't surprise me they'd rather fork and do their own thing, rather than adopt the common model. It also allows them to stop caring about so much of the cross-platform stuff, though Chrome for MacOS will continue to exist so its not like they are saving anything compared to adopting Apple's commits (which typically target the OS X core).
Natural != (nontoxic || beneficial)
Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....
It doesn't support the blink tag ... when you're looking
You know the other option is simply not to do things like play audio, etc. I'm not saying that pushing the envelope is bad (it is very good), but sometimes it has some unintended consequences. If you're making a website that is designed to be used long term, follow the W3 standards, don't go overboard and don't use customizations. In essence stick to basics that have been proven to work. If you want a media page that will be redone in a year or two, go nuts for the extra features!
No, removing code not used by Chrome is a short-term benefit cited, not a goal. There are goals and motivations cited in the second paragraph regarding improved pace for implementing improvements. If you click through to the Blink project page, as anyone who wanted more than the orbital overview could be expected to, the details of the planned architectural changes (including discussion of what held those changes back while Chrome was tied to WebKit) are discussed.
Well-played, sir!
That's not the point. The point is not to be held back by constraints imposed by commitments of the WebKit project. A short term benefit to the split is removing a lot of code that Chromium doesn't use -- not because it supports different "platforms", but because it supports different WebKit-based browsers with different approaches (e.g., WebKit2's alternative to Chromium's multi-process model, etc.)
Google doesn't want to ignore it, they want to fix WebKit's networking code to improve performance on platforms that people actually use, however, doing that while not breaking the legacy bits has produced fragile workarounds that are themselves the source of bugs. Google wants to cut to the heart of the matter, and streamline the whole networking layer rather than continue to work-around the "can't touch this" legacy bits, which they can't do within WebKit given the present constraints imposed by the WebKit project.
Apple, clearly, can ignore it just fine and will no doubt continue ignoring it as Google leaves WebKit.
Less importantly, because WebKit2 doesn't work the way Chromium wanted a multiprocess model to work.
More importantly, because WebKit2 was an alternative response to Chromium's multiprocess model, so it would have required a time machine for them to do that.
V8 is a JavaScript engine used by Chrome, Node.js, and a number of other things.
You are probably thinking of VP8, which is completely unrelated.
Anyone that is using prefixes all over their style sheets is doing it wrong.
Or, more likely, the website CSS hasn't been updated / refactored since prefixes were necessary.
Moderated 'Insightful.' 2 points left.
You should've left XBMC off the list, which is easily the most
half-assed project ever built by non-programmers, for that is the
only reason I could ever discern why the architecture was so
poorly developed.
XBMC is pretty, and will eventually get cleaned up, but it is
hardly pristine. Look under the hood, and you'll barf a few times
as you realize how ugly some bits of its codebase are.
Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....
Does anyone miss blinks and marquees?
WALSTIB!
In addition to testing on Trident 8, 9, and 10; Gecko; and WebKit, we've now got to add Servo and Blink! to the pile. Thanks, Mozilla and Google, for making my job as a web developer much harder! Yay! Innovation! And when we come out the other end, we'll have HTML5! Well, uh, sort of, I guess. The existing engines aren't all standards compliant. But I'm sure these new ones will be better. Hurray for progress!
This is not a forum. Also, using "code" as the format is the easiest way to avoid having to escape HTML to prevent it from being parsed as HTML. If you so loathe fixed width font, there's not much I can do for you.
I hate grammar Nazi's.
.
Full text:
Full text:
Funny that you didn't keep the title (I put back again) ...
Of course news about a fake are Fake News.
The funny thing is, supposedly, Blink really is named after the obnoxious HTML tag!
This CNET article has an interesting explanation:
Quoting from the article:
The Blink name is a reference to the despised and now extinct blink tag of early HTML that made text blink off and on. It follows the pattern of Google naming projects after what it deems relics from the past: Chrome is designed to minimize user-interface "chrome" that surrounds Web pages; the Chromebook Pixel's high-resolution screen is designed to make pixels disappear; and Blink is designed to do away with browser engine irritations.
Shouldn't it be called "BLING!" then?
Of course news about a fake are Fake News.
I just want to double-check here: you have found that getting stuff to work with both gecko and webkit, has been a "major pain in the ass?"
I can't help but suspect that you're really talking about one very special case of multiple browser engine implementations, involving a particular nonstandard one made by a certain company who shall remain nameless. And I don't think that company's browser should be used as an indictment of multiple implementations. It's just an indictment of that one company and their very special place in the market and their unaccountability for basic quality and standards compliance. Fuck them.
There's really just two types of browser: that one special one, and all the others. And the wide implementation diversity within the "all the others" type hasn't ever seemed like a "major pain in the ass" to me. That isn't to say I've never found a gotcha, just that it's not a big deal, and the problems are pretty smalltime compared to the problems created by the real special case.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This is not a forum. Also, using "code" as the format is the easiest way to avoid having to escape HTML to prevent it from being parsed as HTML. If you so loathe fixed width font, there's not much I can do for you.
Actually, the easiest way to avoid having to escape HTML to prevent it being parsed as HTML is to configure your commenting preferences to prevent it. If you must have HTML directly from the wysinwyg comment box, then put the code tags around the markup, not around the entire post....
yeah... after I posted that I realized the two ways that sentence could be interpreted.
In this case, "missed" = "was not alive/writing HTML markup at the time"
Have a look at the proposed architectural changes. It looks like they plan to make some rather sweeping changes, as well as moving the portability code to a different layer of the architecture. At some time, a project diverges enough that only a fork makes sense. It is nearly impossible to maintain a shared source base when making such fundamental architectural changes. It is a waste of time and the resulting mess only makes development increasingly difficult for both parties.
At least that is my understanding of the situation. My first reaction was also not positive, but I acknowledge that it might be necessary and desirable given the desired direction and constrains imposed by maintaining WebKit compatibility.
You appear not to understand the extent of my laziness. I didn't use code tags at all, I picked "Code" from the drop down. (Yes, I understand this cause code tags to be used)
I hate grammar Nazi's.