Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

Post reply on HN
Print view View original

111–120 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#111

Post by TazeTSchnitzel »

tomelders wrote: post #109
TazeTSchnitzel wrote: post #108

Earlier 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. 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".

>I was being polite. I'm talking about IE specifically.

Well, this won't help you here anyway. By the sounds of things, features won't be enabled by default until they're ready. Things currently aren't unprefixed until they're ready. The only way to avoid IE if the feature is unprefixed is UA sniffing.

No change.

>Yup, and it's sucky. It's no different to "this site is optimised for Internet Explorer".

It's quite different, actually. Chrome is just quick at implementing web standards, they aren't dictating things and people aren't relying on proprietary APIs.

Re: Blink: A rendering engine for the Chromium project

#112

Post by macrael »

So, I'm pretty sure this is a correct history:

1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing)

2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1]

3. Google says that the pain in maintaining their separate, non standard, process architecture is too much of a burden to continue to contribute into WebKit proper, so they must fork.

Why can't Chrome implement WebKit 2? Are there major advantages to Chrome's process model that are not present in WebKit 2? Is there a reason why WebKit 2 cannot be patched to provide those advantages?

This seems like a failure of open source.

[1]: see the first paragraph on http://trac.webkit.org/wiki/WebKit2

Re: Blink: A rendering engine for the Chromium project

#113

Post by dragonwriter »

tomelders wrote: post #104
TazeTSchnitzel wrote: post #56

Earlier 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?

You file a bug report on the Chrome (and/or Blink) issue tracker, and it gets fixed.

> Something you might, as a developer, want to disable in Chrome, but leave in for everything else?

Then you use user-agent sniffing to disable it, if you must. The same as you'd do for any flaky implementation of a generally-used feature in a browser. That's not really the notional purpose of vendor-prefixing, anyway (which is about not using the unprefixed name space for things which might later end up with a different standard semantics, not about making it easier for developers to avoid buggy implementation of cross-browser common features).

> All this means is we'll have to go back to the old ways of sniffing out browsers

Or only use features that are well supported across common browsers if you want to avoid browser sniffing.

Re: Blink: A rendering engine for the Chromium project

#114

Post by ConstantineXVI »

TazeTSchnitzel wrote: post #91
jmesserly wrote: post #86

Earlier quoted context omitted.

Yeah. It would be the same problem that WebSQL had: http://www.w3.org/TR/webdatabase/ As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.

Indeed. It's a shame WebSQL died, though, since I would have loved to have had SQLite in the browser. Maybe the solution would have been to specify a similar, new, SQL database for the web? I would have liked that more than IndexedDB.

Why not a JS implementation of a SQL database?

Re: Blink: A rendering engine for the Chromium project

#115

Post by hbbio »

TazeTSchnitzel wrote: post #69
AaronMT wrote: post #57

So which Chromium will Opera be based on now?

They're following them to Blink. So we'll have Trident in IE, Gecko in Firefox (OS), WebKit in (Mobile) Safari and Blink in Chrome/ium and Opera.

Firefox will be using Servo.

Re: Blink: A rendering engine for the Chromium project

#116

Post by dragonwriter »

mankyd wrote: post #7
ebbv wrote: post #2

I can't help but think that forking WebKit is a business based decision since Apple controls WebKit. This blog post doesn't make an engineering based argument* so I'm left with the business ones. Which sucks. * - Just vague "we need to innovate faster" boilerplate. Which is what business people say when there's not a solid engineering based reason. EDIT: At the bottom of the project page are some engineering reasons:…

a) Why does that suck? b) Although it is a little hand wavey, they do make an engineering argument: "However, 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."

> Although it is a little hand wavey, they do make an engineering argument:

Immediately being able to eliminate and not worry about maintaining 7,000 files comprising 4.5 million LOC seems to be a pretty concrete benefit, rather than a hand-wavey one.

Re: Blink: A rendering engine for the Chromium project

#117

Post by jimray »

macrael wrote: post #112

So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…

Reading the utterly passive tone of the OP, with Webkit somehow "emerging" out of KHTML all on its own, nary a mention of Apple, makes it pretty obvious this move is mostly about politics.

Re: Blink: A rendering engine for the Chromium project

#118

Post by makomk »

macrael wrote: post #112

So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…

Apple's current commit approval policies appear to be fairly hostile to non-Apple developers and users of WebKit, and especially to non-Apple users of WebKit2. They now reserve the right to break builds on non-Apple platforms randomly and delay patches to fix them, amongst other things.

Re: Blink: A rendering engine for the Chromium project

#119

Post by jfoster »

account_taken wrote: post #24

Competition is good. Nobody wants to be left behind by Google, so time for Apple and MS to step it up again.

That's an interesting way of looking at it. Apple no longer get a free ride. On the other hand, now that Firefox is using WebKit perhaps Mozilla just replaces Google there.

Re: Blink: A rendering engine for the Chromium project

#120

Post by kaolinite »

kmfrk wrote: post #52
cpeterso wrote: post #42

The 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…

I, for one, can't wait to cut 20% of the code in my stylesheets.

In the meantime, you can use LESS mixins to reduce duplication. This library is pretty handy: http://lesselements.com/
Post reply on HN