221–230 of 326 posts
Earlier quoted context omitted.
> 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…
and it gets fixed You had me until that. I've had legit, simple, reproducible bugs sit in browsers for years when they're on "new" features that aren't standardized, yet somehow, every other browser that implements the same feature doesn't have the bug. Browser vendors use the "not-standardized yet" claim to avoid fixing bugs, while still shipping those features, in my experience.
Another issue with Chrome is that percentage widths are rounded or truncated to the nearest pixel, so creating three 33.3% divs won't fill 100% of the space. It makes a fluid grid difficult to create. I reported this one with the built-in bug reporter, so I don't have an issue link.
Earlier quoted context omitted.
I mean use the monopoly to take the tech, clone, tweak, and then don't contribute back. Thankfully google will keep it open source since they're making money from it quite indirectly. But still.. A "fork you" to apple that would make the web suffer. Douchy.
Isnt "take the tech, clone, tweak, and then don't contribute back" exactly the model Apple used to create webkit from khtml. If memory serves, the khtml team was incredibly unhappy with apple trying to submit giant monolithic and undocumented commits.
Earlier quoted context omitted.
>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. 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 p…
>> 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. > 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. Are you aware of the…
The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work.
>It had nothing to do with SFI (which wasn't brought up at the time) or complexity. It was for the reasons I stated upthread.
I still don't get what that reason is supposed to be. Regardless, the resulting WebKit2 design was clearly incompatible with the existing Chrome architecture. And the fact that they were continuing to diverge and place a burden on both projects was a clear problem. This was raised repeatedly, but never seemed to receive any serious consideration.
Earlier quoted context omitted.
Sincerely curious: why are you still a full-time Safari user in light of all those complaints?
Like most things, habit probably. Also, I used to work a lot on Safari/WebKit, so I guess sentimental value? That being said, I do like the way Safari "feels" a lot more than Chrome. I think Chrome is actually quite ugly, and bad from a UI perspective. For example, Safari's overflow tab menu is a much nicer solution than Chrome's insistence on shrinking tabs ever smaller until you can't tell them apart at all. Additi…
Earlier quoted context omitted.
> The major difference here being that WebKit2 is part of the webkit project, so as the rendering engine (which sits atop both webkit1 and webkit2) is improved by all the various parties involved in WebKit's development, it gets better for everyone. Google's fork now means that changes to the rendering engine they make to Blink will no longer have any effect on the WebKit project, which does seem to be a major differ…
Well that's ultimately kind of sad, right? It's certainly not the argument that was made in this blog post, but it certainly is a believable one. WebKit is a giant open source project that is relied upon by many many different companies and Google contributed a lot to that. Now they are gone and all those companies are left continuing to build WebKit with a goal of interoperability between the myriad different client…
Why is it sad for Chrome development not to be held back by WebKit when each project prefers a different approach?
Personally, I think its win-win: Chrome and WebKit, which have conflicting approaches to a variety of different issues, are free to take their own approaches and prove them. This is a good thing for progress.
> It's certainly not the argument that was made in this blog post, but it certainly is a believable one.
Its actually exactly what the post says when it says "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. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit."
Earlier quoted context omitted.
Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines How is that not engineering based?
Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.
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…
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…
Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…