Since Blink launched there’s been a few patches that have been landed in both Blink and WebKit, though this is expected to decline in the long-term, as the code bases will diverge. Will features added to Blink be contributed back to the WebKit project? Short term long term? A recent proposed experiment is called Oilpan, where we’ll look into the advantages of moving the implementation of Chrome’s DOM into JavaScript. If you’re interested in these experimental efforts or watching new feature proposals, take a look at the blink-dev mailing list.
#WEBKIT VS BLINK MAC#
We’re already doing multi-threaded painting on ChromeOS and Android, and looking into doing it on Mac & Windows. We’re also interested in better taking advantage of multiple cores on machines, so the more we can move painting, layout (aka reflow), and style recalculation to a separate thread, but the faster everyone’s sites will render.
#WEBKIT VS BLINK WINDOWS#
Grid layout is still in development, though, and our Windows text rendering has been getting a new backend that we can hook up soon, greatly boosting the quality of webfont rendering there. Nothing too alarming, layout and CSS stuff is all staying the same. While the internals are apt to be fairly different, will there be any radical changes to the rendering side of things in the near future? All your sites should be pretty much the same.Ĭhrome 27 has the Blink engine, and that’s available on the beta channel for The codebase was 99.9% the same when Blink launched, so no need to rush out and check everything. How long before we can try Blink out in Chrome?īlink’s been in Chrome Canary as of the day we announced it. If you’re really into prefix drama (and who isn’t!) Chris Wilson and I discussed this a lot more on the Web Ahead podcast. The Blink prefix policy is documented and, in fact, WebKit just nailed down their prefix policy going forward. When the feature is ready, it’ll graduate to Canary, and then follow its ~12 week path down through Dev Channel, Beta to all users at Stable. New stuff will be available to experiment with behind a flag you can turn on in about:flags called “Experimental Web Platform Features”. Lastly, we’re not introducing any new CSS properties behind a prefix.
Others, like -webkit-box-reflect are not standards track and we’ll bring them to standards bodies or responsibly deprecate these on a case-by-case basis. Some, like -webkit-transform, are standards track and we work with the CSS WG to move ahead those standards while we fix any remaining issues in our implementation and we’ll unprefix them when they’re ready. Secondly, we inherited some existing properties that are prefixed. There’s a few parts to this.įirstly, we won’t be migrating the existing -webkit- prefixed properties to a -chrome- or -blink- prefix, that’d just make extra work for everyone. Nope, none! They’re great in theory but turns out they fail in practice, so we’re joining Mozilla and the W3C CSS WG and moving away them. I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? Right? 3 days of design, code, and content for web & UX designers & devs.
0 kommentar(er)
