Wednesday, June 5, 2013

WebGL Draft Extensions in Chrome

I mentioned this was coming in my last post, but it's a significant enough change that it's worth addressing on it's own. New Chrome builds, starting with today's Canary build, will begin including a new option in about:flags called "Enable WebGL draft extensions"

(This can also be activated via the command line with the --enable-webgl-draft-extensions flag)

When you enable this it will allow WebGL to access extensions that Chrome has implemented but are still in draft status on the WebGL Extension Registry. Previously these extensions would have been exposed without the flag, but with a "WEBKIT_" prefix. That goes against Blink's policy of avoiding vendor prefixes wherever possible, however, hence the new flag.

The only extension this flag exposes currently is the newly implemented EXT_frag_depth, and any extensions that you previously queried using a prefix will continue to work just fine. 

So what does this mean for you, daring WebGL developers? 

The biggest change is that you probably won't want to release WebGL apps publicly that rely on a draft extension. The flag is there to let you develop against upcoming features, so that they'll be ready to go the moment they become publicly available, but 99.9% of your sites visitors won't see the extension till it's been approved by the community. You can always pop up a dialog telling users how to go flip the flag, but that's not a terribly good first impression for your app to have.

That sounds like a bad thing, but despite the inconvenience it's actually beneficial long term. For starters, features have historically been hidden behind a prefix/flag when they're not finalized. This means that in some cases things may change drastically between the initial vendor-prefixed version and the final product. (See: CSS gradients). The problem is that prefixed features are still visible to users without any effort on their part, so sites begin to rely on the experimental syntax/behavior. This means that even when everyone collectively decides that the initial implementation was a bad idea the browser must continue to support it forevermore or risk breaking sites and angering both developers and users. So the browser bloats over time and it becomes harder to add new features because you're constantly tiptoeing around crusty old features that nobody likes anymore.

It also means we're less likely to break your live app. If you're using an extension that's in flux on a live site and we change the behavior (it happens, especially when it comes to WebGL security issues) suddenly your site has broken and you get to go digging through browser commit logs to figure out what changed. Joy. WebGL extensions are far less likely to undergo sweeping changes once they've been moved out of draft status, though. By encouraging you not to rely on them till they've solidified we make life easier on everyone.

Of course, this implies some responsibility on the part of the WebGL implementors as well. We need to approve extensions in a timely manner to prevent them from being stuck behind a flag in perpetuity. That's actually something that you as a developer can help with! If you are using a flagged extension please provide us with feedback on the public WebGL mailing list! We want to hear about any implementation bugs you find or problems with the extension specs, but we're also happy to hear about your uses of the extensions as well. If we receive a lot of feedback that a draft extension is being widely used or eagerly anticipated it's far more likely for that extension to be moved forward quickly.