CODEWITHSUNDEEP
javascriptcssgoogle-chromebrowser
GMchris
GMchris

Reputation: 5648

Why exactly are browser prefixes necessary, from the browser creator's point of view

There are many tools to work around browser prefixes, be it IDE auto-expansion for troublesome properties or making mixins with precompilers, but why exactly do browser manufacturers NEED to implement prefixes. From what I've heard it's so they can implement their own implementation of something, but what prevents them from doing so without a prefix. Nowadays especially almost all browsers try to follow the W3 specifications, so I doubt Safari would make, say box-shadow, draw a rainbow inside an element.

Isn't it better to leave their "solution" although maybe a bit buggy or lacking in functionality, unprefixed, so when they actually roll out a working version that meets all criteria, sites written using that style of JavaScript property can function as intended? I just really can't see how everyone decided that it's a good idea to implement them.

Upvotes: 2

Views: 159

Answers (1)

BoltClock
BoltClock

Reputation: 723618

The idea was that authors who wanted to "try" out these experimental features locally could do so with the prefixed properties on shipping browsers, rather than having to deal with nightly builds or even downloading and compiling the source manually, because shipping buggy behavior unprefixed was akin to shipping beta software as production-quality.

What the vendors didn't see coming was that authors would take the prefixed properties, put them on production sites, and encourage other authors to do the same. As a result the prefixes spread like wildfire to the point where vendors were too afraid to break sites by removing the prefixes after shipping stable, unprefix implementations as originally intended. I mean, just look at what happened when Mozilla dropped support for -moz-opacity, a prefixed property that was relatively little used compared to today's -webkit- properties, less than 4 years ago. For perspective, -moz-opacity was unprefixed in Firefox 0.9, almost 12 years ago.

Another unfortunate result of this prefix fiasco? Opera, Microsoft, and finally Mozilla, have all reluctantly changed their CSS implementations to recognize -webkit- prefixes because WebKit was making its way into practically every mobile device and every niche browser, and authors were under the impression that WebKit was the One True Layout Engine™, and so they coded for WebKit and nothing else. Clearly we haven't learned from the IE/Netscape browser wars.

And this is why vendors have agreed not to use prefixes for experimental implementations of upcoming standards anymore going forward. New CSS features will ship unprefixed, but not made available by default. For example, Firefox hides these features behind special about:config options and switches them on by default at a later date, while Chrome hides them in about:flags in a similar fashion.

Upvotes: 4

Related Questions