WebKit Developers Discuss Removal of Google-Specific Code

← Back to Stories (view on slashdot.org)

WebKit Developers Discuss Removal of Google-Specific Code

Posted by Soulskill on Friday April 5, 2013 @12:50AM from the cleaning-house dept.

hypnosec writes "WebKit developers have already started discussing the removal of Chrome- and Chromium-specific code from the rendering engine in a bid to make the code easier to maintain. Just a couple of days back, Google announced it will go ahead with a WebKit fork to develop a new browser engine — Blink. According to Google, having multiple rendering engines — just like multiple browsers — will allow for innovation as well as contribute toward a healthy open-web ecosystem. The discussion was started by Geoffery Garen, an Apple WebKit developer. He said Google's departure is an 'opportunity to streamline' the code of WebKit, which would eventually make development 'easier and more coherent for everyone.' Garen expects that developers who will be working on WebKit in the future should help to clean up the code. However, Adam Barth and Eric Seidel — two Google WebKit developers — have already offered their help." Google plans on making the switch to Blink in the stable Chrome release in around 10 weeks. They've posted a half-hour video explaining how the transition will work.

92 comments

Min score:

Reason:

Sort:

Clean It Up Boys by Anonymous Coward · 2013-04-05 00:57 · Score: 5, Interesting

The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.
The down side to all this is checking code in another browser model as well as a different js debugger in Blink.
World Wide Web of Moving Targets
1. Re:Clean It Up Boys by mwvdlee · 2013-04-05 01:16 · Score: 2
  
  I just hope they make it a fork in the sense that Linux distro's are forks; actively exchanging code with the upstream project for the benefit of both.
  
  --
  Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
2. Re:Clean It Up Boys by Anonymous Coward · 2013-04-05 01:34 · Score: 1
  
  Directly contradicting the first post. The announcement suggests neither will be upstream of the other.
3. Re:Clean It Up Boys by Digicrat · 2013-04-05 01:49 · Score: 1
  
  That still doesn't preclude sharing on equal terms, at least until the two projects diverge enough to make that impractical.
4. Re:Clean It Up Boys by Anonymous Coward · 2013-04-05 01:57 · Score: 2, Insightful
  
  Linux distros like ubuntu are technically not forks, but rather derivatives. A fork becomes independent after the fork takes place, even if they do merge code back and forth with the parent project. A derivative, on the other hand, is still dependent on the upstream project for core functionality.
  Autonomy is what makes a fork a fork. Dependence is what makes a derivative a derivative.
5. Re:Clean It Up Boys by KugelKurt · 2013-04-05 02:48 · Score: 1
  
  The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.
  Please explain to me: What negative impact do cleanly separated platform adaptions have? So WebKit devs will delete the chromium directory in https://trac.webkit.org/browser/trunk/Source/WebCore/platform and Google will delete all directories except chromium (and probably android) but I don't see why a buggy BlackBerry adaptation would have any negative impact on the Chromium adaptation and vice versa.
6. Re:Clean It Up Boys by thetoadwarrior · 2013-04-05 03:37 · Score: 2
  
  WebKit doesn't include a JS engine cheome has always had V8 and safari didn't. So your JS development should be any different.
7. Re:Clean It Up Boys by afidel · 2013-04-05 03:42 · Score: 2
  
  Yeah, the BSD projects borrow fairly liberally from each other despite the fact that the code can rarely be copied and pasted.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
8. Re:Clean It Up Boys by BasilBrush · 2013-04-05 05:33 · Score: 3, Informative
  
  Webkit does have a JavaScript Engine. It's called JavaScriptCore. But Chrome didn't use it.
9. Re:Clean It Up Boys by XSEnergy · 2013-04-05 06:44 · Score: 1
  
  That would make sense, but the discussion has now veered off into also removing the ability to plug in components such as your own JavaScript engine, because it is expensive to maintain....if anything the cleanup should go the other way of making it more easy to plug-in different implementations for specific pieces into WebKit. The lesson here should be IMHO, to avoid future forks by making ports less expensive, not use this as an opportunity to cut down on extensibility.
10. Re:Clean It Up Boys by Anonymous Coward · 2013-04-05 07:57 · Score: 0
  
  I wish these targets (implementations) would move even faster, so developers would finally code to standards and standards alone.
11. Re:Clean It Up Boys by Anonymous Coward · 2013-04-05 14:33 · Score: 0
  
  Are you nuts? Extensibility for its own sake is not a good thing.
  If you read through those messages carefully, you'll notice that they came to the conclusion that, with Google gone, literally every organization directly contributing to WebKit trunk uses JavaScriptCore. And that those who are using V8 in downstream projects don't seem to consider it a disaster if it goes away in trunk. So there isn't much reason for WK maintainers to continue V8 support.
  It doesn't sound like there's a real plugin API involved either. What I take away from those emails is that JS is very tightly tied to the guts of WebKit, and that the present dual-engine support is a pile of #ifdef hurt which everyone only put up with because Google was providing enough value to the project (and getting enough value in return) to make the pain worthwhile.
  Also consider that Google's reasoning for forking WebKit included doing much the same kind of cleanup in the new Blink fork, so that Blink will be easier to maintain and will also get faster. Why would WebKit want to leave those same benefits on the ground now that the only real force requiring them to support lots of alternate technologies is gone?
Good by Anonymous Coward · 2013-04-05 00:58 · Score: -1

Fuck Google and Fuck Apple. Why not just remove both their code.
1. Re:Good by siride · 2013-04-05 01:02 · Score: 1
  
  As of this article, that's exactly what's happened.
2. Re:Good by KugelKurt · 2013-04-05 02:55 · Score: 2
  
  Nobody is removing anyone's code from WebCore itself. They are only talking about now unmaintained platform adaptions. Unmaintained adaptions have always been removed. Nobody within the public even noticed when the Symbian S60 adaptations were deleted.
Hurr durr Google by Anonymous Coward · 2013-04-05 01:00 · Score: 0

Here's to DART, NativeClient and Google's never ending quest to push their own battery-killing video and audio codecs as no hardware supports it natively.
1. Re:Hurr durr Google by Anonymous Coward · 2013-04-05 01:05 · Score: 5, Funny
  
  http://prng.net/blink-faq.html
2. Re:Hurr durr Google by Anonymous Coward · 2013-04-05 01:35 · Score: -1
  
  Wow, whoever wrote that might actually be retarded.
3. Re:Hurr durr Google by Anonymous Coward · 2013-04-05 02:12 · Score: 0
  
  Clearly he's not a big fan of Google (unless Google was in the back seat of Thelma & Louise's car, then he'd be cheering them on for their gusto), but there is truth in his sarcasm.
  I wonder how this will affect Chrome on iOS?
4. Re:Hurr durr Google by Anonymous Coward · 2013-04-05 02:26 · Score: 1
  
  What a bunch of FUD. Did whoever wrote that actually read the original?
  For example:
  
  1.4 How does this affect web standards?
  We have sufficient market share on the desktop that a few months from now, we will be in a position to unilaterally dictate them.
  We hope to leverage this control to achieve the same dominance in mobile eventually.
  1.5 Will we see a -chrome vendor prefix now?
  No. See 1.4.
  vs
  
  Will we see a -chrome- vendor prefix now?
  We’ve seen how the proliferation of vendor prefixes has caused pain for developers and we don't want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla's recently announced policy.
  In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the “Experimental WebKit Features” flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels.
  For legacy vendor-prefixed features, we will continue to use the -webkit- prefix because renaming all these prefixes to something else would cause developers unnecessary pain. We've started looking into real world usage of HTML5 and CSS3 features and hope to use data like this to better inform how we can responsibly deprecate prefixed properties and APIs. As for any non-standard features that we inherited (like -webkit-box-reflect), over time we hope to either help standardize or deprecate them on a case-by-case basis.
  How does giving devs a chance to use new features ahead of time, without vendor-specific prefixes, while keeping the -webkit- prefixes and saying "we won't use vendor prefixes for new features" translate into highjacking the standards process? If they are using the same approach as Mozilla, is Mozilla being accused of hijacking the standards process?
5. Re:Hurr durr Google by Anonymous Coward · 2013-04-05 07:16 · Score: 0
  
  Hurr durr, bullshit hardware lies from YEARS ago. VP8 has hardware support you twit, quite a bit of it, read the fucking specs.
Like this part by Anonymous Coward · 2013-04-05 01:01 · Score: 4, Funny

#ifdef __CHROME__ doCheckpoint( 1332 ); // load additions to keystroke log and browser history doCheckpoint( 1335 ); // compress doCheckpoint( 1337 ); // send contents to gmail server #endif
1. Re:Like this part by allo · 2013-04-05 04:24 · Score: 1
  
  > implying, there is the #ifdef line
On the Origin of Species by Anonymous Coward · 2013-04-05 01:03 · Score: 5, Insightful

I don't see why people get so scared of forking code. Differentiation and species drift happens in nature all the time, and a code-base that tries to fit too many different requirements is awful to maintain (and also unstable).
1. Re:On the Origin of Species by Anonymous Coward · 2013-04-05 02:15 · Score: 1, Funny
  
  Because Adria Richards thinks forking is sexist and puts women down, that's why!
  God forbid you using your 4g dongle to connect to the internet in order to fork webkit's repo, she'd probably have the cops arrest you!
2. Re:On the Origin of Species by Anonymous Coward · 2013-04-05 03:14 · Score: 4, Interesting
  
  Well, in this case Webkit is planning to drop V8 support. I'm kinda freaked out by the fact that Webkit apparently isn't script engine agnostic as it should be, but now all the incentive to make it such may be lost.
  Forks in general tend to cause much duplication of effort, especially if both branches remain popular. Given enough time, fixes for one fork aren't obvious to implement in the other. You shouldn't really fork a project unless you cannot reach a peaceful decision.
  In this case however, Google just didn't want to contribute to the new Webkit2 with generalised multi-process support, because that would make it easy to develop a multi-process browser, which just happened to be Chrome's main selling point.
  The Webkit folks made the right technical decision, Google made the right marketing decision. A fork was inevitable, sadly.
3. Re:On the Origin of Species by SeaFox · 2013-04-05 05:47 · Score: 2
  
  I don't see why people get so scared of forking code. Differentiation and species drift happens in nature all the time...>
  
  I think the fear here is that the forking of code will lead to browsers that interpret "standards" differently and don't display web pages the same way. We'll be back to "I have to use Internet Explorer for site x and Netscape to get site y to work right."
  One thing about homogenous browsers, we're more likely to all be on the same page on how to read the web (pun not intended).
4. Re:On the Origin of Species by AmiMoJo · 2013-04-05 09:40 · Score: 1
  
  We'll be back to "I have to use Internet Explorer for site x and Netscape to get site y to work right."
  That's a problem with the design of the site. HTML was never designed for pixel perfect layout, quite the opposite in fact. CSS gives you a lot of control but also wasn't designed for the kind of perfection that web monkeys seem to want. Aside from anything else a site should at least be able to cope with different font sizes, for example.
  If it uses so much tricky HTML/CSS/JS that it doesn't render reasonably in standards compliant browsers then I'm not browsing it.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Why not? by RocketRabbit · 2013-04-05 01:06 · Score: 2, Insightful

It only makes sense to trim unused legacy code from any library. If Google isn't using Webkit any more, why leave their own specific stuff in there?
It isn't a problem to fork code and remove legacy stuff. It was done when KHTML was forked into Webkit, and it will probably be done again. The only losers in the event of a fork like this are possibly the independent developers who contribute to Webkit, but it is doubtful that they were contributing code that is Google specific.
Good luck with that by turkeyfeathers · 2013-04-05 01:11 · Score: -1

Google's posted a half-hour video explaining how the transition will work? They're crazy if they think any regular user is going to spend a half hour learning how to use a new browser... just make it work like the old one or don't expect people to use it.
1. Re:Good luck with that by MightyYar · 2013-04-05 01:14 · Score: 1
  
  I thought about going for the first "woosh", but I'll leave it for another :)
  
  --
  W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
2. Re:Good luck with that by AikonMGB · 2013-04-05 01:18 · Score: 2
  
  The video is for Chrome(ium), WebKit, and now Blink developers, not for the end users or the browser(s).
3. Re:Good luck with that by Anonymous Coward · 2013-04-05 01:18 · Score: -1
  
  You misunderstood. The video explains to website developers how they can use the new privacy-reducing features in Blink to better track their users behavior. Google is adding so many of these features that it's amazing they can fit them into a half hour video.
4. Re:Good luck with that by Rich0 · 2013-04-05 01:20 · Score: 3, Insightful
  
  This is an open source project, and the video is directed at people who work with the browser source code or who have an interested in webkit/blink. It isn't targeted at end users.
  It is a rendering engine. How many end users have even heard of webkit?
  Obviously the browser will work the same after as before. The only thing a user might notice is that it is faster (some day) or that it has some new feature that perhaps would not have been as easy to develop without the fork.
  I for one appreciate that a company like Google takes the time to actually create videos like this. I can certainly say that my employer doesn't put half-hour videos on Youtube discussing the software engineering decisions it makes for its closed-source systems.
5. Re:Good luck with that by loufoque · 2013-04-05 01:22 · Score: 1
  
  Especially since none of the answers are useful at all.
  It just says "it's a fork, so right now, it's the same thing". I don't know why they thought they needed to repeat this for 30 minutes.
6. Re:Good luck with that by spacepimp · 2013-04-05 01:23 · Score: 1
  
  The video isn't about how to use the browser. The article isn't about how to use the browser, or changes in UI of Chrome. Forking WebKit serves to accelerate and simplifying Chrome development.
7. Re:Good luck with that by flimflammer · 2013-04-05 01:41 · Score: 1
  
  Yikes, the FUD is strong with this one.
8. Re:Good luck with that by gstoddart · 2013-04-05 02:00 · Score: 1
  
  It is a rendering engine. How many end users have even heard of webkit?
  Anybody who has ever looked at their task manager and wondered WTF WebKit2WebProcess process was and why it was using so much memory.
  I find it tends to try to use as much memory as it possibly can, and even if it's sitting just on a single web page over time it bloats enough that I have to exit the browser and restart it to reclaim it
  I just wish Safari could actually delete cookies without that webkit process crashing. I suspect both Apple and Google would far rather I kept cookies so they could make money from me.
  I'm starting to lose my patience with webkit based browsers.
  
  --
  Lost at C:>. Found at C.
9. Re:Good luck with that by Anonymous Coward · 2013-04-05 18:05 · Score: 0
  
  Idiot... the video for developers, regular users will notice absolutely nothing, like they don't notice anything right now with seamless autoupdates.
Know your audience. by RivenAleem · 2013-04-05 01:19 · Score: 5, Insightful

The "how the transition works" video will be for people interested in how the transition works, not a regular user. Your comment is like saying a 30 minute video on "how the internal combustions engine works" is a pointless exercise, because the regular driver just wants it to work
quid pro quo by roman_mir · 2013-04-05 01:22 · Score: -1

By the way, why the fuck is there any Google specific code in anything that is used in a browser?
Microsoft specific code is not OK, but Google specific code is just fine?
Ok, let's do blue specific code. I want code that is specific to blue. I like the colour blue, so I want code that is very specific to that colour, so that the colour has special privileges and execution strategies and tags that are only available for things that are blue.

--
You can't handle the truth.
1. Re:quid pro quo by flimflammer · 2013-04-05 01:47 · Score: 3, Insightful
  
  Erm... You're confusing external functionality that isn't cross platform (ActiveX, the old DirectX-labeled text effects, etc) versus internal functionality designed to integrate better with the browser. This is obviously the latter.
2. Re:quid pro quo by moronoxyd · 2013-04-05 01:50 · Score: 4, Informative
  
  For the same reason there is Apple specific code in WebKit. And (probably) PowerPC code, and x86 code, and Android code, and iOS code, and ...
  Why is HyperV code in the Linux kernel?
  Or code that is for Intel graphics?
  If a piece of software tries to support many platforms and usage cases, you have code that is only used in specific scenarios.
  And if the reason to support this platform or usage case is gone (i.e. iOS support for Blink, and Google support for post-split WebKit), then you remove it.
3. Re:quid pro quo by hkmwbz · 2013-04-05 02:13 · Score: 2
  
  Chromium specific, as in, is only used when building Chromium/Chrome (that other Webkit browsers don't want or need). Not actual web standards stuff, probably. Except maybe WebGL?
  
  --
  Clever signature text goes here.
4. Re:quid pro quo by Reapman · 2013-04-05 04:51 · Score: 1
  
  Wow. A comment like that from a UID much lower then mine.
  Fascinating.
  A major user of WebKit had submitted code for WebKit. News at 11.
Say "goodbye" to 64-bit builds of Opera... apk by Anonymous Coward · 2013-04-05 01:25 · Score: 0, Informative

See my subject-line, & since Chrome-based browsers aren't 64-bit in Windows, then once the Blink/WebKit builds of Opera release (Presto = gone, what a shame imo), odds are they too will ONLY be 32-bit (that is, IF "Chrome/Chromium" & browsers derived for it for Windows are ANY kind of "indicator" here)...
* :(
(Afaik @ least? Chrome/Chromium are only 32-bit for Windows, & hence, my statements above...)
APK
P.S.=> Got to thinking about this today, & just had to note/mention it (unless anyone else KNOWS otherwise that is, & I'd appreciate that IF anyone does)...
... apk
1. Re:Say "goodbye" to 64-bit builds of Opera... apk by Anonymous Coward · 2013-04-05 01:34 · Score: 0
  
  Google recently banned ad-blockers and host files from their Google Play store. Will they now block them from Chrome? By default, Safari blocks 3rd party cookies (Firefox recently changed to the same). What will Chrome do? (Google was already busted for working around the 3rd party cookie restriction). There are a lot of good employees and a lot of talent at google... but they make their money by tracking you and selling you.
2. Re:Say "goodbye" to 64-bit builds of Opera... apk by Guspaz · 2013-04-05 01:58 · Score: 1
  
  They didn't block them before, I don't see why this fork would cause them to block them after. They may decide to do so at some point, but that decision doesn't have anything to do with the forking...
3. Re:Say "goodbye" to 64-bit builds of Opera... apk by Anonymous Coward · 2013-04-05 03:06 · Score: -1
  
  ill have 64bit opera on linux
  sucks to be a pathetic faggot microsoftie like yourself
  maybe you can code your own blink browser in delphi
4. Re:Say "goodbye" to 64-bit builds of Opera... apk by etresoft · 2013-04-05 03:08 · Score: 1
  
  I think defeating ad-blocking and enhanced ad management are one of the primary reasons for the fork.
  The first thing Google lists for architectural changes is support for out-of-process iframes
5. Re:Say "goodbye" to 64-bit builds of Opera... apk by afidel · 2013-04-05 03:51 · Score: 1, Troll
  
  Did you even bother to see why they are moving iframes to their own process? Yeah, it's all about ads, not about making a more secure product... I think this has infinitely more to do with Chromebook than it does to ad sales, in fact moving iframes to their own process would give any ad-in-iframe LESS visibility into your surfing which you would think would be the exact opposite of what an "evil" Google would want.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
6. Re:Say "goodbye" to 64-bit builds of Opera... apk by Guspaz · 2013-04-05 04:23 · Score: 1
  
  That change has nothing to do with ads, and in no way does it help or hinder ad blocking.
  Google could have handled that quite simply by banning ad blockers from the chrome store, or by not extending the API with things specifically designed to support ad blockers...
  The fork doesn't have anything to do with ad blockers because nothing was stopping them from banning those before.
7. Re:Say "goodbye" to 64-bit builds of Opera... apk by afidel · 2013-04-05 05:25 · Score: 1
  
  Sweet, posting information about why a technical change is being made is now trolling on Slashdot, it really has gone downhill.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
8. Re:Say "goodbye" to 64-bit builds of Opera... apk by etresoft · 2013-04-05 07:03 · Score: 1
  
  I said nothing about Google being "evil". Google is just providing more value to its customers. Google most definitely does not want ads to be able to access the rest of your browser information. That information should only come from Google, properly anonymized and billed. While this change would make it harder for malicious iframes to sniff data that doesn't belong to them, it would also give malicious iframes more opportunities to inject code. Currently, if such an iframe tried that and failed, it will kill the parent process, effectively ending the injection attempts. With the new system, multiple iframes could keep trying different tactics.
9. Re:Say "goodbye" to 64-bit builds of Opera... apk by DirtyLiar · 2013-04-06 20:37 · Score: 1
  
  Google is just providing more value to it's customers.
  Why is it that I find when a company says that it's providing me with "more value", that I find that they are in reality removing things that I actually value, and / or adding things I do not value, and are probably charging me more for the priviledge?
  For example:
  I called a company complaining about a new juice bottle that, because the bottom was concave, held 1/2 an ounce less than the previous bottle, but they had not lowered their already high price. The person had the nerve to tell me that the change had been made because market research showed that their consumers wanted it. She didn't have much to say when I replied, "So you can show me surveys where people say that they either want to pay more for their juice, or get less of it, right?"
  Oh, and keep in mind that the users of Google and Chrome are NOT Googles customers. Google sells targeted ads to advertisers. To be a customer really requires some kind of payment to be exchanged for a good or service.
  The consumers of Google's free products are not customers, they are the product that Google sells to it's paying customers, it's advertisers.
  
  --
  THINK! It's patriotic
One size fits all? by bitflusher · 2013-04-05 01:32 · Score: 1

I have always wondered why everyone was using the same engine while every browser has a unique selling point. Now it becomes clear a one size fits all equals a one size fits noone perfectly. Perhaps this creates a bit more diversificaton and true unique selling points for the browsers.
1. Re:One size fits all? by UnknowingFool · 2013-04-05 03:26 · Score: 2
  
  Well code reuse has greatly helped anyone who has worked on open source. They don't have to reinvent the wheel every time. Apple forked KHTML because it was small (140,000 lines) and clean. Apple could have written it all from scratch but they benefited from the work that was already done in terms of time and direction. When they got more expertise they started to take it in a different direction. Google is doing the same with Blink. It's the same pattern as Apple's ARM hardware. They used slightly customized Samsung chips in the beginning for the iPhone. Then they bought PA Semi and Intrinsity. With each generation of CPU, they have customized the ARM chip more and more. At first they modified the SOC but left the ARM core intact. With the A6, they have begun to make modifications to the core itself.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
And to think .. (paranoia) by Anonymous Coward · 2013-04-05 01:33 · Score: 0

People were saying with the whole "Opera goes Webkit" thing was going to wreck the web, this happens.
Hope you enjoy that paranoia, you guys who were crying over it.
All that paranoid reaction for no reason. No wonder the world is in ruin.
Gonna wash that man right out of my hair! by Anonymous Coward · 2013-04-05 01:34 · Score: 0

lol. They're like a bitter woman burning pictures of the ex who dumped her.
1. Re:Gonna wash that man right out of my hair! by moronoxyd · 2013-04-05 02:16 · Score: 1
  
  ... with the ex helping to burn the pictures?
  Note that at least two Google employees offered to help.
Terrible name considering... by cjjjer · 2013-04-05 01:44 · Score: 1

The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/

I can only imagine how much easier it will be for Google to track us via a custom HTML and extensions it implements...
1. Re:Terrible name considering... by Anonymous Coward · 2013-04-05 02:19 · Score: 0
  
  Said by someone with a hotmail address....
2. Re:Terrible name considering... by VortexCortex · 2013-04-05 02:46 · Score: 2
  
  The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/ I can only imagine how much easier it will be for Google to track us via a custom HTML and extensions it implements...
  Which is doubly odd, because I just recently used the forbidden <blink> element once, in all my years of development, to create a blinking terminal-like cursor for a few quick one-off temporary landing pages (excerpts from my old text based BBS game).
  Firefox actually renders the "cursor" blinking... Guess which browser doesn't? Chrome.
3. Re:Terrible name considering... by Plumpaquatsch · 2013-04-05 03:03 · Score: 1
  
  The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/
  
  And I was thinking about Bling. As in "Chrome, now with extra Bling!"
  
  --
  Of course news about a fake are Fake News.
4. Re:Terrible name considering... by keytoe · 2013-04-05 05:32 · Score: 1
  
  You may be the only other person I've heard of to use <blink> in a legitimate fashion.
  About 8 years ago, I was writing a web based application for a public facing help desk department. Appointments were limited to 15 minutes per customer, and to serve as a reminder we provided a timer right in the ticket system. At a certain threshold, the timer would turn red to indicate hurry up mode - and for the last minute, it would blink. One of my coworkers set out to write a JS timer to handle it until I reminded him of <blink>*.
  * Technically, it was done with CSS, but <blink> is nothing but a <span> with a default style, so same thing.
  
  --
  Culture is more than commerce
So... by Sollord · 2013-04-05 01:50 · Score: 0

Google is evil according to all the whiny bitches on here for Forking Webkit into Blink. So just how horrifically evil is Apple for forking KHTML into Webkit? Safari and Chrome don't share much of anything really in common save for the webkit api and even then it's a clusterfuck of vendor specific tags
1. Re:So... by Bill_the_Engineer · 2013-04-05 02:04 · Score: 3, Insightful
  
  There was a large number of "whiny bitches" on here when WebKit forked from KHTML. People react to change. Life goes on.
  
  --
  These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
2. Re:So... by Billly+Gates · 2013-04-05 02:51 · Score: 1
  
  Thats because most sites sniff useragents and serve browser specific code. This move will break apps that sniff android or Chrome and only serve -webkit specific CSs
  
  --
  http://saveie6.com/
3. Re:So... by KugelKurt · 2013-04-05 03:06 · Score: 4, Insightful
  
  Google is evil according to all the whiny bitches on here for Forking Webkit into Blink. So just how horrifically evil is Apple for forking KHTML into Webkit?
  Actually Apple at that time was a pretty bad FOSS citizen. People campaigned to Apple to rethink the way it does development and that resulted in a vendor-neutral development home for WebKit. These days KDE is a happy user of WebKit.
  Google now repeating Apple's past mistakes is not so great. 2 wrongs don't make 1 right, as they say.
4. Re:So... by Nerdfest · 2013-04-05 03:21 · Score: 1
  
  Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.
5. Re:So... by jayrulez · 2013-04-05 03:30 · Score: 1
  
  Blink will support -webkit prefix.
6. Re:So... by Anonymous Coward · 2013-04-05 03:40 · Score: 0
  
  It basically is 3 'kits' already. Just depends on how you compile it.
  Googles flavor
  Apples flavor
  and neither
  Google said they are 'done' with supporting Apple and the neither flavor for any changes they make.
  What this is is a bad merge gone horribly wrong with a bad set of internal API's to abstract these issues away.
7. Re:So... by Anonymous Coward · 2013-04-05 04:37 · Score: 0
  
  forking KHTML was a bad move, khtml was much better, but now webkit is edging out khtml.
8. Re:So... by KugelKurt · 2013-04-05 05:30 · Score: 1
  
  Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.
  You got it the wrong way around. It was Google who refused to develop a multi-process architecture within WebKit, just as they refused to improve JavaScriptCore and instead created V8 as stand-alone project under Google-exclusive control.
9. Re:So... by UnknowingFool · 2013-04-05 06:47 · Score: 1
  
  Actually Apple at that time was a pretty bad FOSS citizen.
  Can you recite specific cases? The situation with KHTML was when two different development models clash. Apple with its paid development team churned out a lot of code because they needed to develop a working browser (Safari) quickly. Apple first submitted changes in Jun 2002 and by Jan 2003 had Safari in beta. They didn't have a lot of time to document the code as necessary when they submitted their patches to upstream. It happens. The KHTML core developers are mostly volunteer so they work whenever they have free time; they didn't have time to review and implement all the code Apple was releasing and got further behind.
  Apple has contributed to and still contributes to many open source project today. LLVM, OpenCL, Darwin, cups, Bonjour/ZeroConf, etc.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
10. Re:So... by Anonymous Coward · 2013-04-05 07:25 · Score: 0
  
  It will support what's currently there, no telling about future extensions. Anything that kicks lazy devs in the butt is a good idea IMHO, stop writing to engines, morons.
11. Re:So... by Anonymous Coward · 2013-04-05 08:13 · Score: 0
  
  For a while it will support existing -webkit-* properties, but the plan is to phase them out. Which is the right thing to do.
12. Re:So... by Anonymous Coward · 2013-04-05 08:31 · Score: 0
  
  Wait a minute, the whining when KHTML was forked into WebKit was because Apple initially was very bad about contributing code back to the community in any useful way. Once they got their act together and started running WebKit as a much more open development process, there was a ton of development on WebKit from non-Apple devs and WebKit eventually was developed to the point it is today where it is the defacto standard rendering engine.
  In short, people were mad at Apple for being assholes and once Apple wised up, it was much better for everyone.
  I don't know how Google will run the Blink project. Hopefully they will continue to have an open development process (as opposed to the Android model) and code will continue to be shared between WebKit and Blink where applicable.
13. Re:So... by KugelKurt · 2013-04-06 00:03 · Score: 2
  
  Can you recite specific cases? The situation with KHTML was when two different development models clash.
  Apple's development model at that time was behind closed doors and doing that is not good FOSS citizenship.
  Another example is Apple Public Source License 1.0.
  
  Apple has contributed to and still contributes to many open source project today. LLVM, OpenCL, Darwin, cups, Bonjour/ZeroConf, etc.
  Yes, today. I was referring to Apple's initial steps into FOSS development.
  Apple dropped source code under APSL unless it had no choice. Today even Apple's own developments such as Bonjour or Dispatch are released under Apache License or BSD-like licenses and other parties can easily pick them up. Apple successfully set up WebKit as vendor-neutral project, joined LLVM and contributed Clang, even became the release manager of X.org at some point, etc.
  Google should have learned from Apple's past mistakes. Yet, Google somehow successfully presents itself as great FOSS citizen, despite:
  The Android kernel was as much of a "uncivil" fork of Linux as WebKit was from KHTML and it took much campaigning by Greg KH and others to get Google to even start to submit and maintain the patches upstream.
  Google refused to implement a multi-process architecture directly in WebKit and insisted to make it Chrome-exclusive. Same with V8: No attempt to even try to optimize WebKit's JavaScriptCore, instead insisting on adding hard to maintain bindings for V8.
I don't see how they can block hosts.. apk by Anonymous Coward · 2013-04-05 02:23 · Score: 0

It operates @ the IP stack level as a filter in ring 0/rpl 0/kernelmode (not usermode/ring 3/rpl 3, like browser addons).
* It operates NO MATTER WHAT & long before browsers (let alone their addons that layer ontop of them slowing them down even more) do...
(Only way they could really do that is to alter the IP stack itself imo or the OS, unless others know otherwise, & that's NOT going to happen...)
APK
P.S.=> Again though - I am MORE concerned about Opera NOT HAVING 64-bit builds though (since Chrome doesn't) in Windows, once the "Blink/WebKit" transition 'takes hold' @ Opera...
... apk
1. Re:I don't see how they can block hosts.. apk by Anonymous Coward · 2013-04-05 02:59 · Score: 0
  
  When chrome wants to connect to a web site, it asks the OS to convert the name to an ip address. The OS then checks the hosts file, checks it's DNS cache, then queries the DNS server.
  But Chrome could skip the OS and implement it's own DNS lookups (google run their own DNS servers)... bypassing your precious ring 0 hosts file. They could even justify it for technical reasons -- Google's DNS server blocks malware and doesn't hijack invalid domains like some ISPs do. Also, if they do the DNS lookup themselves, they'll have accurate TTL information for cache invalidation which the OS doesn't provide.
  And while we're on the subject, BSD and Linux perform their name lookups in a libc (run in usermode), not in the kernel.
2. Re:I don't see how they can block hosts.. apk by DirtyLiar · 2013-04-06 20:54 · Score: 1
  
  It doesn't even have to do that, it could just ignore everything that returns 127.0.0.1 that isn't localhost, and only THEN query the DNS server. Or, it could keep it's own small file of Google's own ad serving addresses, and translate those into IP Addresses before the request even hits the hosts file. This would have the advantage of never allowing THEIR ads to be blocked, while allowing their competitors to be blocked.
  And since most Google ads (AFAIK) are graphics and flash light, this might even be acceptable to most Chrome (and now Blink) users.
  Since I actually like the free website model mostly in use today, I only ever block ads when they begin effecting my web browsing speed, browser stability, or my privacy. So, yeah, I block all flash advertising, always.
  
  --
  THINK! It's patriotic
Anyone said it yet? by Anonymous Coward · 2013-04-05 02:36 · Score: 1

DON'T BLINK!
1. Re:Anyone said it yet? by Anonymous Coward · 2013-04-06 05:57 · Score: 0
  
  Yeah, only a million times. Congratulations on your supreme dipshittery.
Amicable parting by jayrulez · 2013-04-05 03:34 · Score: 1

That was an amicable parting if I've ever seen one. However, leave it to the internet peanut gallery and various religious nut jobs (i.e Google fan girls, Apple fan girls and certain other fan girls) to make a mountain out of this ant hill.
1. Re:Amicable parting by UnknowingFool · 2013-04-05 06:48 · Score: 1
  
  Indeed. This is what forking is supposed to do. If someone decides to take a code in another direction, they can do so as long as they meet the licensing terms.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
Editors: grammar, dammit! by Anonymous Coward · 2013-04-05 04:19 · Score: 0

Garen expects that developers who will be working on WebKit in the future should help to clean up the code. However, Adam Barth and Eric Seidel â" two Google WebKit developers â" have already offered their help
Garen expects everyone's help, which includes Barth and Seidel. "However" makes no sense if Barth and Seidel are going to help Garen. If they are going to help the forked version, then "have already offered their help" makes no sense.
Please, please, please, please, please take an english class!
mo3 3own by Anonymous Coward · 2013-04-05 08:09 · Score: -1

achieve any of the be on a wrong election to the c0ore team. They Nigger Association here, please do clothes or be a Thing for the are incompatible inventing excuses Though I have never that the project FrreBSD at about 80 Raadt's stubborn at this point BSD has always things in has brought upon The Cathedral OF AMERICA irc taken over by BSDI Was in the tea I to predict *BSD's the hard drive to to use the GNAA long term survival chosen, whatever Distro is done Here everyday...We irrecoverable the system clean users. BSD/OS since we made the Any parting shot, during this file Niggers everywhere bad for *BSD. As confirming the
True: MS does it for their sites.. apk by Anonymous Coward · 2013-04-05 08:45 · Score: 0

They'd have to "bulk up" their webbrowser more to do that though, as well as circumnavigate native TCP/IP functionality - & for what?
Tracking + Advertising purposes??
(They do that, I wager this strongly - they'll LOSE users on Chrome/Chromium in doing so...).
Lastly - Per my subject-line: Microsoft bypasses hosts:
http://slashdot.org/story/06/04/16/1351217/microsoft-bypasses-hosts-file
Albeit (& iirc), for purposes that aren't along THOSE lines (tracking/advertising), but rather for Windows Update functionality to be accurate, to THEIR servers only @ certain IP addresses (iirc)... e.g.:
DomainScreenList:
windowsupdate.microsoft.com
windowsupdate.com
microsoftupdate.com
download.microsoft.com
update.microsoft.com
HostsScreenList:
microsoft.com
www.microsoft.com
support.microsoft.com
wustats.microsoft.com
microsoftupdate.microsoft.com
office.microsoft.com
msdn.microsoft.com
go.microsoft.com
msn.com
www.msn.com
msdn.com
www.msdn.com
APK
P.S.=> GOOGLE wouldn't have to even get as "technical" as you're stating though: They could simply use a list of servers that doesn't change on THEIR end, as the DO have the ca$h for static addresses on their servers for sure (sort of the reverse of what Opera does in its urlfilter.ini, which IS a way to block sites in it), OR even "hardcode" said IP addresses to said servers of theirs in the executable of the browser itself (not a huge trick)...
... apk
Will Blink support the blink tag? by descubes · 2013-04-08 08:31 · Score: 1

One has to wonder.

--
-- Did you try Tao3D? http://tao3d.sourceforge.net
If it aint broken by martijn+hoekstra · 2013-04-08 21:05 · Score: 1

Don't fix it. Once it starts causing problems and you see no upside in maintaining, remove it. Easy as that.
Opera COULD go for another "Opera 1st"... apk by Anonymous Coward · 2013-04-11 09:15 · Score: 0

A 64-bit for Windows build of a WebKit/Blink browser though, in Opera - you never know!
* :)
(That, would be cool...)
APK
P.S.=> It's not like they haven't done their share of firsts & bests in webbrowsing tech before... I'd like that one @ least + I am sure I'm not alone in that regard either (especially if they're dropping Presto which I feel is excellent personally)...
... apk