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

141–150 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#141

Post by macrael »

mikewest wrote: post #126
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…

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc. Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run…

A stunningly reductive question deserves to be responded to in kind :)

I don't know much of this history, but was integrating Chrome's processor model into WebKit feasible at the time that WebKit2 was built? What were the reasons for not doing so?

Re: Blink: A rendering engine for the Chromium project

#142

Post by silencio »

gsnedders wrote: post #81
cromwellian wrote: post #74

Earlier quoted context omitted.

Does Apple already maintain a private WebKit fork for iOS?

Yes. It's (finally) slowly being upstreamed, however. iBooks uses a separate fork of WebKit, too.

iBooks does not use a separate fork of Webkit - I've talked to some Apple engineers about it in the past.

Re: Blink: A rendering engine for the Chromium project

#143

Post by dragonwriter »

hbbio wrote: post #115
TazeTSchnitzel wrote: post #69

Earlier quoted context omitted.

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.

> Firefox will be using Servo.

Maybe, someday. Servo is a long-term, high-risk effort.

Re: Blink: A rendering engine for the Chromium project

#144

Post by plorkyeran »

robryan wrote: post #132
kaolinite wrote: post #120

Earlier quoted context omitted.

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

The parent was likely referring to them being in the stylesheet at all, rather than the way they are managed. Any stylesheet compiler is still going to have the vendor prefixes in the compiled stylesheet.

In practice you won't actually be able to drop them from the compiled stylesheet for a very long time, of course.

Re: Blink: A rendering engine for the Chromium project

#145

Post by zmmmmm »

TazeTSchnitzel wrote: post #56
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…

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…

Hmm, isn't it true though, for example, that without that we'd have had to wait a long time to get simple things like border-radius that were supported in all the browsers but hidden behind vendor extensions?

Having experimental features available to developers creates pressure for all browsers to move forward. Without that we won't know what is important to developers because they'll be stuck using what the browser maker's deign to make "official".

Just playing devil's advocate here ...

Re: Blink: A rendering engine for the Chromium project

#146

Post by coldtea »

drivebyacct2 wrote: post #4

Interesting timing, given the Samsung+Mozilla+Servo news today.

Yes. Announcing this especially today seems like a "fuck you" at Samsung.

Downvotes? Anybody thinks that two companies that are in some heat over Android/Tizen et all, just coincided to release information about new rendering engines on the same day?

As if rendering engines are announced every other day, right?

Re: Blink: A rendering engine for the Chromium project

#147

Post by macrael »

candybar wrote: post #121
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…

Isn't WebKit2 as much a fork of WebKit as Blink is? And it's not production ready?

The name doesn't make it clear, but I believe the answer is "no". My understanding is that WebKit2 is actually just a part of the whole WebKit platform. It's the process model, but all the other parts of webkit (the rendering and javascript, for instance) are the same as they were before WebKit2 was introduced.

Re: Blink: A rendering engine for the Chromium project

#148

Post by TazeTSchnitzel »

zmmmmm wrote: post #145
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…

Hmm, isn't it true though, for example, that without that we'd have had to wait a long time to get simple things like border-radius that were supported in all the browsers but hidden behind vendor extensions? Having experimental features available to developers creates pressure for all browsers to move forward. Without that we won't know what is important to developers because they'll be stuck using what the browser…

Well, hopefully things might get through quicker. But that is indeed a problem.

Re: Blink: A rendering engine for the Chromium project

#149

Post by mikewest »

macrael wrote: post #141
mikewest wrote: post #126

Earlier quoted context omitted.

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc. Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run…

A stunningly reductive question deserves to be responded to in kind :) I don't know much of this history, but was integrating Chrome's processor model into WebKit feasible at the time that WebKit2 was built? What were the reasons for not doing so?

Generally, I think WebKit2 and Chromium simply disagree about where to hook into the platform, and what the responsibilities of the embedder should be. The description at http://trac.webkit.org/wiki/WebKit2 is written from Apple's point of view, but I think it's broadly fair.

The position we're taking is that the Content layer (in Chromium) is the right place to hook into the system: http://www.chromium.org/developers/content-module That's where we've drawn the boundary between the embeddable bits and the Chrome and browser-specific bits.

Regarding the history, I'd suggest adding some questions to the Moderator for tomorrow's video Q/A: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&#38... The folks answering questions there were around right at the beginning... I only hopped on board ~2.5 years ago. :)

Re: Blink: A rendering engine for the Chromium project

#150

Post by dragonwriter »

ellyagg wrote: post #93
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…

"Let's face it: developers start to rely on new features the moment they're added." "So this is a huge win for us, the developers." There's a contradiction here, and I'm not being cute. Your argument is not the only argument to be made, and personally, as a developer, I preferred the old way. Yep, there are negative externalities, and that always has to be weighed, but I think it was a reasonable approach to allow de…

> On the other hand, there's virtually no community for whom it would be reasonable to ask to make config changes to view a site, so you you simply can't use cutting edge features. Experimental site designs will be harder to show off and we'll have less public consideration of the implications of new recommendations since there's much less joy in putting together projects that few people will see.

Showing off demos leveraging experimental browser features that don't happen to be CSS features has often been done with requests to make config changes, because the "put it behind a config flag until it is ready" is pretty standard for everything other than CSS (and, actually, browser vendors have also done it for plenty of experimental implementations of CSS, whether or not the features themselves are standard or vendor-prefixed experimental extensions.)

Post reply on HN