Too many developers use vendor prefixes in a way that harms website compatibility. The problem is multifaceted, and so there isn't really one group of people that are to blame, or one golden solution.
The problem has been there for a long time, but it's become visible through the rise of the mobile web and the relative quickening of implementation in browsers. I personally worked a lot with sites quite a few years ago to try to get them to add prefixes other than just -moz- for things like the CSS opacity property. IE tended to get its own path, because development was slow at the time, and many developers mainly cared about Firefox for standards-based code, and perhaps Safari—but not always.
Fast forward a few years. Chrome was released, the mobile web fundamentally changed with Safari and Android becoming the apple of developers' eyes, and CSS experimental features grew in number, thereby creating an explosion in the number of properties requiring prefixes. The end result: desktop and cross-device-focused sites using -webkit- and -moz- prefixes, and mobile-focused sites only including -webkit-.
It's not that developers are lazy, or that they are all Apple or WebKit fans. Some may be, given that the developer landscape varies like any profession, but many developers just do the 9-to-5 grind, copy-pasting code found online, hurrying to finish projects. At the other end are the artisans, who take immense pride in their work, and get every detail right. They live and breathe the web, even after they go home for the night. And then there's everyone in between.
But even artisan web developers don't agree about what to do with prefixes, and so the 9–to-5 bunch have no chance! If you include every prefix and the unprefixed version, you add page weight, and the feature could change anyway, as we've seen with gradients and 'flexbox', and even border-radius back in the day. If you don't add the unprefixed version, you guarantee that the site breaks in other browsers, unless you go back and update your old code later, but not everyone does this.
Being a web developer is exciting, but often difficult. If you're a carpenter and take a year off, it's likely when you return your woodworking skills will still be as relevant as they ever were. With the web, you'd come back and a bunch of your knowledge would be dated.
Because of changes to standards and uncertainty regarding the final syntax, you end up with articles making good points when written but that rapidly become out of date. Developers copying them will, unbeknownst to them, write code that will break in some browsers. Many sources of information are written when a feature is introduced, because that's when it's most exciting to talk about. Online content becomes stale, but newer and more accurate information takes a while to bubble to the surface, because older articles have had time to build up strong search engine ranking.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
Then there is the issue of prefixes hanging around too long. They get ingrained—developers rely on them, and so their removal may break numerous sites. WebKit tends to keep its prefixes around for a long time, even after the unprefixed version is implemented, for this very reason. Part of the problem was the CSS working group taking too long to get features from a proposal requiring prefixes to a stable, unprefixed version. This arguably allowed prefix use to blossom, because instead of just early adopters using prefixes for demos and smaller projects, mainstream sites used them, since they were the only option. And we still can't agree what kind of fall-back to use, so how can regular developers know how to do the correct thing?
The good news is the working group and the browser vendors have recognised their failings, and a bunch of important specs have been fast-tracked, so they are considered ready to be implemented without prefixes. This includes specs like Transitions, Transforms and 'flexbox', and gradients from the image values spec. Most of the browsers have followed suit, implemented updated versions and unprefixed them.
This doesn't solve the issue for vendor-specific properties for which there is no spec. Ideally, these will get proposed to the working group by the vendor that comes up with them. Things are getting better on that front. Microsoft recently proposed its Pointer Events to the W3C to replace touch events, and in the CSS space, Opera submitted @viewport to replace the non-standard meta viewport, which has since also been implemented by Microsoft. Both implementations require prefixes right now, but they should reach the state where they can be unprefixed before long.
The W3C recently launched its Web Platform initiative, with the backing of browser vendors. As it is a neutral venue, I'm expecting the information found there will show the correct way to do things for all browsers, rather than just taking care of the interests of one party. If the combined efforts of the browser vendors, the W3C and the developer community can keep this resource up to date and towards the top of the search engine rankings, this should help even copy-and-paste developers get things right.
