Why the browser vendor -prefix- saved the web

Posted: 19 January 2012
Did the implementation of DOCTYPE, the browser vendor prefix, save the use of CSS on the web?

In a world where new CSS specifications are constantly evolving, the existence of browser prefixes has never been more important. Despite the flexibility we now have, some developers are complaining of having to repeat themselves in their code to achieve the same effect in several browsers, and that there should be just one ‘development’ prefix for all browsers. So why wouldn’t this work? Surely we shouldn’t have duplicate code?

A brief history

Back in the late ‘90s, the varying browser implementation of certain CSS properties was such that a site could render perfectly in one browser, but completely fail in another; hence the classic “This site works best in….” plaques found on many landing pages back then. Out of this and several other problems, the ‘standards’ and ‘non-standards’ (quirks) DOCTYPE implementation was born, which arguably saved the use of CSS on the web.

The generic ‘development’ prefix

If browser vendors were forced to use the same development prefix for a property i.e. dev-border-radius, developers would be forced to accept each browser’s interpretation of the property.

But if one browser implementation is different from another browser and breaks a site layout, the only options available are either to sniff out (not nice) the offending browser(s) and hide the property or abandon the use of the property altogether in all browsers, until the browser(s) changes its implementation.

Of course there’s every chance it won’t ever change and developers decide to abandon the use of the property altogether thus securing its journey into obscurity, never to be seen again.

The browser specific prefix

Browser-specific prefixes allow browser vendors to develop and potentially fix bad implementations, with the ability to leave any flawed behaviour behind in the prefixed version of the property.

During a property’s specification development, it allows developers to serve the property only to browsers which implement the behaviour correctly, preserving graceful degradation in other browsers. Whilst this might seem like an unnecessary duplication of code, it ensures the best possible development of the property implementation in all browsers.

Conclusion

Generic prefixes stifle property specification development, they offer developers limited flexibility, and potentially create more work in cross browser support.

Browser-specific prefixes save developers time and effort, and ensure healthy development of new property specifications which have seen the dramatic rise of CSS3 and its cross-browser support. Now there are even solutions that automatically add the relevant browser prefixes, allowing developers to code prefix free, without duplication of code.