I disagree. If the tags had been standalized then we would be using them. Unfortunately the standards commity dropped the ball on this one because they are unable to act fast enough.
These are features which changed semantics and syntax multiple times over the course of their standardisation, it's not like standards guys were slow because they found it fun
> If the tags had been standalized then we would be using them.
Webkit browsers have all supported unprefixed box-sizing since the release of Safari Mobile 5.1 in March 2012. 2 years later… https://github.com/search?l=CSS&o=desc&q=-webkit-box-sizing&...
That query means developers by and large don't care and just cargo-cult through.
> The prefixed one is there for backwards compatibility.
Backwards compatibility with what, fucking Chrome 6? How many of these sites have been tested for backwards compatibility in Chrome 6? I'd bet it's somewhere around "none whatsoever".
And while IE and Firefox have supported unprefixed CSS transforms for a while now, Chrome and Safari only support the -webkit-prefixed version of CSS transforms so far. So if you want to do transforms, you have to use -webkit prefixes...
Oh for fuck's sake, the query is specifically looking for -webkit-box-sizing, not for webkit-prefixed properties in general.
Chrome won't remove them because it breaks these sites relying on the webkit prefix remaining - so there's sufficient ground there to indicate developers are failing. But it's not the developers who include the non-prefixed standardised version.
Yes, there are lots of developers who don't care - the ones who rely on the webkit-prefix support remaining. That is contrary to the spirit of vendor prefixes - experimental CSS properties that should not be relied on.
Those using both the webkit prefixed and the standard non-prefixed versions are using the typical graceful fallback - one that doesn't make other browsers "unsupported"