201–210 of 326 posts
[deleted]
Quite the opposite, see http://www.chromium.org/blink#vendor-prefixes
Earlier quoted context omitted.
As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute t…
I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. http://goo.gl/KH1Sr Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy. http://goo.gl/iTDAR
I don't know if the contents of these conversations were ever shared with the whole Chrome team as som Chrome people seemed super surprised at our announcement.
It is true that when we announced our effort, it came with a rough working prototype and not just an empty directory. Basically because we did not know if we could do it until we tried.
BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was.
Google had the right to make their choices and we had the right to make ours.
Earlier quoted context omitted.
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.
Correct- Apple's announcement of the WebKit2 changes- https://lists.webkit.org/pipermail/webkit-dev/2013-January/t...
For a cross-platform project, this is a stunning policy change. I don't know what was the chicken and what was the egg, but it looks like this split was inevitable.
Earlier quoted context omitted.
As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute t…
I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.
To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & godspeed.
This 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. From http://www.chromium.org/blink/developer-faq
I find this a doubled-edged sword. Monocultures are said to foster a culture of laziness, apathy. This hasn't been the case with WebKit. Don't get me wrong - competition is healthy. I'm simply thinking of how Jovinder experiences the web.
I've lost track of the number of times I've had to pretend to be something different (desktop Firefox, default Android, Mobile Safari ...) to make a website usable. Every time I have a fresh Firefox install on Android, the first extension I install is Phony.
Earlier quoted context omitted.
I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. http://goo.gl/KH1Sr Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy. http://goo.gl/iTDAR
We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. I don't know if the contents of these conversations were ever shared with the whole Chrome team as som Chrome people seemed super surprised at our announcement. It is true that when we announced our effort, it came with a rough working prototype an…
Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective.
>BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was.
I don't interpret Mike's comments that way. Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity. I'm comfortable that the divergence was simply a result of different needs. I just don't see how it could be presented as something malicious or anti-collaborative.
Earlier quoted context omitted.
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.
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:…
Apple doesn't actually control WebKit. A decent proportion of reviewers at http://trac.webkit.org/wiki/WebKit%20Team are Google employees. The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
1. Not affiliated with Apple or Google.
2. Not specifically associated with a port in terms of their review areas.
To me, that says a lot about how WebKit governance works in practice.
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…
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?
And in terms of Servo, Blink makes Servo more likely to succeed, not less, by breaking open the (mobile) WebKit monoculture.