Go forth and use proprietary browser features

Here’s why you shouldn’t be afraid to use proprietary browser features–especially with stuff that’s more experimental and explorative in nature:

First of all, lots of good things come from once-proprietary features. My favorite example perhaps is the .innerHTML property of DOM elements, that originated on Internet Explorer. This property is not only easier to use than (just stick any HTML string in), but also much faster than classic DOM manipulation. Now all browsers support this, no big surprise there.

Useful features will be carried over into the “browser mainstream”, and are standardized retroactively.

Almost all features available in modern browsers came from a browser vendor to scratch a specific itch, be it CSS Transitions, client-side storage and databases, extensions to the DOM such as CSS Selectors, 2D drawing surfaces, vector graphics, and so on and so forth. The list continues endlessly.

Early adopting of new features you find useful is a good way to see them broadly implemented.

Of course, some proprietary features won’t make it, or only in vastly different form (Google Gears come to mind). But mind you, it’s not that hard to adopt once things change. Client-side storage is client-side storage after all. APIs might also change (mostly in subtle ways) when they make the transition from proprietary to widely-adopted. If you do use these, you’ll probably have to check from time to time if everything works as expected on the latest browser version (if you’re serious about web development, you’re probably doing that anyway, as new browser versions can break existing, well-working code by introducing new bugs).

Most of the time, there are ways to cope with backwards-compatibility in case you need it, by falling back to other technologies (for example, a lack of WebSockets support might be worked around by using Flash). But, don’t concentrate on the problems, think about all the awesomeness you can create. Solutions to problems can always be found.

Participate on open-source wrapper libraries that are useful to more people than just you.

A great way to cope with this issue is to use libraries that wrap the proprietary APIs and can react to changes to the underlying APIs, or even use different underlying frameworks depending on the browser (for example, Raphaël uses either SVG or VML, transparently), and as a team, you can do so much more.

By developing a popular library you might even be asked to participate in the future development or standardization of the feature and contribute your experience with it.

Always watch out for new developments!

There’s always something going on. It pays to check out beta verions and nightly builds of browsers, and try out some of the wonderful features that are coming up (check out WebGL, for example!).

Don’t be shy, and don’t let yourself be told “But! You can’t do that! It’s against the Web-Gods will! No committee approved that!”

With that said, go ahead and create the next amazing thing!