There has been some major advances over the last few years in front-end development. Almost to the point where it is becoming impossible to know everything about all the technologies in which it encompasses.
One of this technologies is CSS and browser vendors needed a way to offer developers the opportunity to experiment with new properties and syntaxes before the specifications were fully completed. Therefore introducing vendor prefixes into the mix.
I’m not here to comment on whether this was a good thing or not, but what I will say is that now being a few years down the line, we are now in a state of disconnect with the technology.
To get around needing to know what the current state of the properties and the technologies we are using, we got into a habit of prefixing anything new. Out of assumption rather than best practice.
And as the technologies have progressed, so have the tools we have available to us. With the increase of popularity of CSS pre-processors and libraries such as Sass and Compass, we have lost touch even more with the CSS which is being produced for our website and relying on these tools to do this stuff for us. Often leaving us with unnecessary properties being defined in our production CSS and at a time when performance is a hot topic*.
The problem – if you could call it that – is browsers are making constant releases as the CSS specification gets better standardised and certain CSS properties are no longer needed to be prefixed.
Do you know when and which properties no longer need prefixing?
Over time I have some interesting features that I want to introduce, but it is a step in the right of direction for us to get back to knowing the CSS we are writing, better. I encourage you to check it out and test your knowledge of the CSS you are writing.
* Since the release of Compass 1.x, vendor prefixes for popular CSS3 properties are determined using Can I Use data, similarly to unprefix.me