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

91–100 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#91

Post by TazeTSchnitzel »

jmesserly wrote: post #86
TazeTSchnitzel wrote: post #59

Earlier quoted context omitted.

Rendering engine monoculture isn't a good thing though. If a single rendering engine dominates, then there is less reason to write standards-compliant code - after all, everyone uses WebKit, right?

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.

Re: Blink: A rendering engine for the Chromium project

#93

Post by ellyagg »

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…

"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 developers to weigh the use of cutting edge features against their own communities, needs, and goals. That calculation would change depending on how many browsers were offering a proposed recommendation and the browser proportions of your viewers. Lots of interesting stuff was posted around the web, including here, taking advantage of these things. 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.

Re: Blink: A rendering engine for the Chromium project

#94

Post by MatthewPhillips »

mikewest wrote: post #84
MatthewPhillips wrote: post #77

Earlier quoted context omitted.

If you want to really put a tinfoil cap on, you could say that by Google contributing to WebKit they are giving Apple a lot of free code, allowing them to devote fewer resources to their browser. Once Blink diverges father from WebKit it won't be practical for WebKit to merge in changes from there. One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink.…

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.

Re: Blink: A rendering engine for the Chromium project

#98

Post by mikewest »

rictic wrote: post #87
oellegaard wrote: post #54

I know it might be an unpopular comment, but I really don't like this. I had hoped every browser would eventually use the webkit rendering engine. I have a hard time feeling sorry for those engineers that have to maintain compatibility, when I think of the many frontend engineers that now have to test a different rendering engine :(

I'll say from personal experience on two recent projects: if you're only testing in one webkit browser and not hitting the others there's a good chance that you're missing a couple of bugs. There are a ton of different ways to build webkit, Chrome and Safari were never identical enough to ignore. Fortunately, after developing in Chrome it took about as much effort to support Firefox as it did to support Safari, which…

Paul Irish has a great article outlining the technical background of this sort of inter-WebKit diversity: http://paulirish.com/2013/webkit-for-developers/

Re: Blink: A rendering engine for the Chromium project

#100

Post by TazeTSchnitzel »

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

Actually, HN is exactly the sort of place where people might be willing to do so. Things are posted here which require specific browsers or about:flags changes in Chrome, what would change?

Post reply on HN