Skip navigation

Chris Wilson

warning: Creating default object from empty value in /var/www/vhosts/ on line 33.
Original author: 
(author unknown)

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 -chrome- or -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.

Pinky swear?

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.

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. We’re already doing multi-threaded painting on ChromeOS and Android, and looking into doing it on Mac & Windows. If you’re interested in these experimental efforts or watching new feature proposals, take a look at the blink-dev mailing list. A recent proposed experiment is called Oilpan, where we’ll look into the advantages of moving the implementation of Chrome’s DOM into JavaScript.

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.

Now, we don’t want to break the web, and that’s something that web browser engineers have always been kept very aware of. We carefully gauge real-world usage of things like CSS and DOM features before deprecating anything. At Google we have a copy of the web that we run queries against, so we have a pretty OK idea of what CSS and JavaScript out there is using.

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

Did part of the decision to branch away from WebKit involve resistance to adding a Dart VM? WebKit’s goals explicitly mention JavaScript, and Apple representatives have been fairly vocal about not seeing a need.

Nope, not at all. The decision was made by the core web platform engineers. Introducing a new VM to a browser introduces considerable maintenance cost (we saw this with V8 and JavaScriptCore both in WebKit) and right now Dart isn’t yet ready to be considered for an integration with Blink. (more on that in a sec). Blink’s got strong principles around compatibility risk and this guides a lot of the decisions around our commitments to potential features as they are proposed. You can hear a more complete answer here from Darin Fisher, one of the Chrome web platform leads.

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

Not yet, but since Dart compiles to JavaScript and runs across the modern web, it’s not gated by other browsers integrating the VM. But it’s still early days, Dart has not yet reached a stable 1.0 milestone and that there are still technical challenges with the Dart VM around performance and memory management. Still, It’s important to point out that Dart is an open source project, with a bunch of external contributors and committers.

Let me take a moment to provide my own perspective on Dart. :) Now, as you know, I’m a JavaScript guy, so early on, I took a side and and considered Dart an enemy. JavaScript should win; Dart is bad! But then I came to realize the Dart guys aren’t just setting out to improve the authoring and scalability of web application development. They also really want the web to win.  Now I’ve recently spoke about how The Mobile Web Is In Trouble, and clarified that my priorities are seeing it provide a fantastic user experience to everyone. For me, seeing the mobile web be successful trumps language wars and certainly quibbling over syntax. So I’m happy to see developers embrace the authoring advantages of Coffeescript, the smart subset of JavaScript strict mode, the legendary Emscripten & asm.js combo, the compiler feedback of TypeScript and the performance ambitions of Dart. It’s worth trying out technologies that can leapfrog the current expectations of the user experience that we can deliver. Our web is worth it.

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?

As I understand it, Opera Mobile, Opera Desktop, and Opera Mini will all be based on Chromium. This means that they’ll not only share the exact version of Blink that Chrome uses, but also the same graphics stack, JavaScript engine, and networking stack. Already, Opera has contributed some great things to Blink and we’re excited about what’s next.

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. ;)


Your rating: None

dust1.pngIGF Student Showcase finalist Dust takes the trimming of a traditional side scrolling game and makes it magical. Players assume the roll of a moth that must escape from an old attic, collect its fallen moth brethren, and find its way to the ultimate source of light and its greatest attraction: the moon.

Visual attractiveness was important to Team Dust's eight members, who all wanted their game have a storybook feel. Through Dust's development, the team actually derived more inspiration from Trine than classic Disney movies. Even after Team Dust found its inspiration, the game never became a laborious nor mechanical for its members. Dust remained their "art".

Here Dust's environment and world building artist Patrick Sullivan explains how the game was intended and remained to be a tool to better the developers who worked on it. He also discusses how Dust's enormous environments come to life and even how the team avoided having a moth, who possesses the power of light, be attracted to itself.

What development tools did you use? How long was the development cycle?

Our engine was Unity, we all used 3Ds max as our modelling program, and Photoshop. As a school project, Dust was technically done after 6 months, but since then the team has been making minor adjustments here and there.

What inspired you to create Dust?

From the beginning we decided to go with a storybook feel and I think we pulled that off. Our earliest inspirations were from Old Disney references like Lady and the Tramp, and colorful and exaggerated art styles like Matt Gaser's work, but I think our implementation of those styles was pretty off.

Where I think we succeeded was when we started looking at Trine for inspiration. The environments were vibrant and had a lot of contrast in the lighting. We did our best to make the game feel like a child's fantasy world, and for the most part I think we pulled it off.

Why a game of dust and moths? Where are the moth balls?

The initial idea for Dust came from our concept artist, Alexis Boyer. We wanted to focus on the game as an art piece, and her idea was the best fit. We wanted to make a unique game with an unusual perspective, and building the world around a small bug meant we could make a new and interesting environment. Down at a tiny moth's perspective, chairs and tables became like massive buildings, and small objects like books, balls, and teddy bears became enormous obstacles.

The base mechanic for the game was pushing, and we wanted to give the main moth the ability to move progressively larger and larger objects. So we gave him a little zombie moth army (or marmy) to do all the grunt work. We called the game Dust because it was such an appropriate fit. The player is in a dusty old attic, resurrecting dusty mini moths, and is guided by bright particles of dust.

Unfortunately, moth balls didn't make it in the game because of time and resource constraints. There's a lot of stuff we had to cut out. We wanted enemies and interactive NPCs, and we wanted to be able to light your little mini moths on fire as they flew through candles. At one point we wanted essentially a Super Saiyan (Dragon Ball Z) moth, but the scope and scale would have gotten out of hand... Plus we were afraid that the game might have exploded from too much awesome.

A moth with the power of light: does that mean it is attracted to itself?

We had to make the moth blind so he didn't just fly around in circles trying to catch himself. His little zombie marmy is also his seeing eye marmy.

Why do you think your game deserves to win the Student Showcase?

Dust, as a project, was intended to be a tool to better the people that worked on it. Each team member was very passionate about making a fun and beautiful product, and getting a meaningful experience out of the process. It was never just some task to be completed. Dust is our art, made just because we wanted to create something awesome and unique. Dust deserves to win because it's an accurate representation of why we all wanted to be in the game industry to begin with. We just wanted to make something cool.

Why should the average gamer play your game?

Part of Dust's appeal is its simplicity. All that you're doing essentially is collecting enough resources to make yourself awesome enough to knock over big items and dominate the environment. It's fun for the average player because you get to explore a familiar world through an unusual perspective. It's also not that bad of a game to look at. It's very shiny.

What are some interesting things about your game that you haven't talked about before?

If you take the time to look for this, one of our Environment artists, Brian McClain, made caricatures of the original 6 team members, and we placed the portraits all over the level. Along with the portraits are little notes to the team that Brian left around the attic. Also, one thing that we're proud of is the music. Our composer, Blake Allen, joined the team after last year's GDC and wrote the music specifically for Dust. His contribution tied the game together perfectly. It's pretty cool that our game has its very own music.

Could you tell me about the team who worked on the game?

Team Dust was a group of artists that wanted to paint a pretty picture and evoke a sense of wonder. Even our lonestar programmer, Alex Burley, was engaged in the art process to make sure the mood was set exactly how we envisioned it. The majority of our artists label themselves as Environment Artists, but during the whole process we filled the roles that needed to be filled.

Chris Wilson and Paul Poff were our prop artists. Chris also filled a project manager role, and Poff tried his hand at Dust's animations. Alexis Boyer, Brian McClain, and I were the environment guys. Alexis also did character work and props, Brian established the environment concepts and in-game 2D illustrations, and Pat did a lot of world building and technical implementation (spearheaded by Mr. Burley).

Later on we added Blake Allen for our audio and Jessica Burg for our graphic and web design needs. This is Team Dust's first project, and at the moment we don't have plans for any others. We've all moved on to new and exciting prospects, but who knows where the members of our team will go next.

Were there any notable advisors or external sources of help for the project?

We had four advisors working with the team to make sure it stayed on track. Our academic director at the Art Institute [of Phoenix], Jim Haldy, acted like our producer, and made sure we didn't veer off course or undertake too much. RC Torres and Thomas DiCosola were our art advisors. They critiqued our work all the way through development and helped us nail down the mood. In fact it was Mr. DiCosola that came up with Dust as our title.

Helping out our programmer was David Koontz. He really helped to get us acquainted with unity. All together they were there to give us as much of a professional experience as they could. They were all amazingly helpful, and Team Dust's appreciation can't be overstated.

Your rating: None