[deleted]
Blink: A rendering engine for the Chromium project
101–110 of 326 posts
Re: Blink: A rendering engine for the Chromium project
#102This paragraph makes me happy:
From a short-term perspective, monocultures seem good for developer
productivity. From the long term perspective, however, monocultures
inevitably lead to stagnation. It is our firm belief that more options in
rendering engines will lead to more innovation and a healthier web ecosystem.
Re: Blink: A rendering engine for the Chromium project
#103Chromium have a very agressive innovative agenda, compared to other players.. im sure they will benefit from this move..
They were probably carrying webkit in their own shoulders anyway, cause nobody does so much experiments as chromium team does..
If they have the energy to do it.. thats good news for us :)
Re: Blink: A rendering engine for the Chromium project
#104The good news is no -blink prefixes! Blink, like Mozilla, will avoid shipping vendor-prefixed features: 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 ... we will instead keep the (unprefixed) feature behind the…
Finally! Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider…
So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes.
All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.
Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience".
Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.
Re: Blink: A rendering engine for the Chromium project
#105The Chromium team will be running a Hangout tomorrow to answer any questions that pop up. Hit this Moderator page to ask whatever's on your mind: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&...
Re: Blink: A rendering engine for the Chromium project
#106Wow, finally an attempt to speed up the DOM
Re: Blink: A rendering engine for the Chromium project
#107Super excited about this! There was a long discussion on the webkit mailing list after google tried to add support for multiple language VMs in webkit. The goal was to have a native Dart VM. https://lists.webkit.org/pipermail/webkit-dev/2011-December/... If I remember correctly, the patch was not merged in. I guess now google can do whatever it wants!
I've only read the first dozen of so entries of that thread but it's so depressing…
We've been waiting for Apple to include support for the W3C Navigation Timing for a long time so their pissing match over multi-VM support in WebKit because it doesn't conform to standards rings hollow.
Re: Blink: A rendering engine for the Chromium project
#108Earlier quoted context omitted.
Finally! Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider…
So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes. All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better. Nor do…
>So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes.
>All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.
The situation is no different just now, because -webkit- applies to Safari, Opera and many mobile browsers, not just Chrome. :/
>Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience". Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.
"Use a modern browser [actually, Chrome] to get the full experience" is not an uncommon sight these days.
Re: Blink: A rendering engine for the Chromium project
#109Earlier quoted context omitted.
So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes. All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better. Nor do…
>So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes. >All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better. The s…
I was being polite. I'm talking about IE specifically.
>"Use a modern browser [actually, Chrome] to get the full experience" is not an uncommon sight these days.
Yup, and it's sucky. It's no different to "this site is optimised for Internet Explorer".
Re: Blink: A rendering engine for the Chromium project
#110Earlier quoted context omitted.
Blink remains very much open source: the repository should be visible in a minute or three. We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features . I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
Of course, I wasn't claiming otherwise, but over time porting code to WebKit from Blink will become more trouble than it's worth. They can still learn from it, but you can hardly deny that this move is going to cause WebKit some pain to fill in the tremendous amount of work you guys were doing (the part about this being the reason for the move was, of course, completely a joke.
The two engines will diverge, yes. I think it'll be better for both in the long run, as we simply have fundamentally different architectural approaches to some pretty core problems the engines are meant to solve. There will be short term adjustments on both sides as we get used to the new options that are now available.
I'm honestly quite hopeful, both about Blink, and about WebKit.