I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? Right?
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. There’s a few parts to this.
Firstly, we won’t be migrating the existing
-webkit- prefixed properties to a
-blink- prefix, that’d just make extra work for everyone. Secondly, we inherited some existing properties that are prefixed. 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. 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. Lastly, we’re not introducing any new CSS properties behind a prefix.
Totes. New stuff will be available to experiment with behind a flag you can turn on in
about:flags called “Experimental Web Platform Features”. 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.
The Blink prefix policy is documented and, in fact, WebKit just nailed down their prefix policy going forward. 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 [37:20].
How long before we can try Blink out in Chrome?
Blink’s been in Chrome Canary as of the day we announced it. The codebase was 99.9% the same when Blink launched, so no need to rush out and check everything. All your sites should be pretty much the same.
Chrome 27 has the Blink engine, and that’s available on the beta channel for
Win, Mac, Linux, ChromeOS and Android. (See the full beta/stable/dev/canary
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?
Nothing too alarming, layout and CSS stuff is all staying the same. 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.
Will features added to Blink be contributed back to the WebKit project? Short term; long term?
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.
When are we likely to start seeing Blink-powered versions of Chrome on Android? Is it even possible on iOS, or is iOS Chrome still stuck with a Safari webview due to Apple’s policies?
Blink is now in the Chrome Beta for Android. Chrome for iOS, due to platform limitations, is based on the WebKit-based WebView that’s provided by iOS.
Part of this move seems to be giving Google the freedom to remove old or disused features that have been collecting dust in WebKit for ages. There must be a few things high on that list—what are some of those things, and how can we be certain their removal won’t lead to the occasional broken website?
A few old ’n crusty things that we’re looking at removing: the isindex attribute, RangeException, and XMLHttpRequestException. Old things that have little use in the wild and just haven’t gotten a spring cleaning from the web platform for ages.
Blink also has over 32,000 tests in its test suite, and manual confirmation that over 100 sites work great before every release ships. And we’re working closely with the W3C and Adobe to share tests and testing infrastructure across browsers, with the goals of reducing maintenance burden, improving interoperability, and increasing test coverage. Eventually we’d like all new features to ship with shared conformance tests, ensuring interoperability even as we add cutting-edge stuff.
Still, any deprecation has to be done responsibly. There’s now a draft Blink process for deprecating features which includes:
- Anonymous metrics to understand how much any specific feature is used “in the wild”
- ”Intent to deprecate” emails that hit blink-dev months before anything is
- Warnings that you’ll find in your DevTools console if you’re using anything
- Mentions on the Chromium blog like this Chrome 27
Have any non-WebKit browsers recently expressed an interest in Dart? A
scripting language that only stands to work in one browser sounds a little
Will Opera be using the Chromium version of Blink wholesale, as far as you know? Are we likely to see some divergence between Opera and Chrome?
Why the name “Blink,” anyway?
Haha. Well… it’s a two parter. First, Blink evokes a certain feeling of speed and simplicity—two core principles of Chrome. Then, Chrome has a little tradition of slightly ironic names. Chrome itself is all about minimizing the browser chrome, and the Chromebook Pixel is all about not seeing any pixels at all. So naturally, it fits that Blink will never support the infamous
<blink> tag. 😉
4 Reader Comments
I wish people would stop picking on the BLINK tag. Not because I liked it but because the guy who created it did it as a joke and didn’t know his team was going to put it into any public implementation. It’s just too easy of a target to try to make yourself look clever by picking on it.
Good stuff. I think I was most excited to read that Google is finally doing something about webfont rendering for Chrome on Windows. Can’t wait to see the results.
Yea the like Michael mentioned the rendering in Chrome on Windows is poor, despite many ‘fixes’ floating around at the moment that technically arent, if this move aids on improving things then its welcomed.
It’s not necessarily picking on blink tag per se, but rather always reminding us of the massive social and technical implications that a small change in a browser, even a minor one, can make on the whole web.
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions