3 ms·

Prefixing just did not work. We should push the standards bodies to drop that nonsense ASAP. Making all of us blindly insert 5 or 6 duplicate declarations in e

Prefixing just did not work. We should push the standards bodies to drop that nonsense ASAP. Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution, and in fact circumvents the original purpose of prefixing--you're assuming that all vendors implement the feature identically, in which case why prefix at all? In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it. Prefixing isn't a function of the standards bodies, it's a function of browsers that want to implement stuff without worrying about peoples' experiments doing something stupid when the standards body picks the same property name but with different semantics. edit: here's a scary thought, what if standards bodies picked Microsoft's version of CSS Transforms back in the '90s: #myObject { filter: progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand', M11=1.5320888862379554, M12=-1.2855752193730787, M21=1.2855752193730796, M22=1.5320888862379558); }

wwweston 15y ago
"In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it." Maybe the right thing to do here is make the prefix optional. That is, let webkit/gecko/ie/etc recognize -webkit/-moz/-ms/-etc prefixes just in case you need to invoke a rule differently for a special snowflake case, but let the non-prefixed rule work when a prefixed rule hasn't been specified.
- bonzoesc 15y ago
  That makes it difficult to provide progressive enhancement though. If I use a prefixed property, I have the ability to make sure it works fine without it, and I can assume that in the future, if the semantics of it change when it becomes non-prefixed, it'll either disappear (i.e. if it was a -webkit property being rendered on firefox) or still work (i.e. if it was a -o property being rendered on opera). If I use an experimental non-prefixed property, how do I make sure future browsers that might implement it differently render it usably?

wwweston 15y ago

"In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it." Maybe the right thing to do here is make the prefix optional. That is, let webkit/gecko/ie/etc recognize -webkit/-moz/-ms/-etc prefixes just in case you need to invoke a rule differently for a special snowflake case, but let the non-prefixed rule work when a prefixed rule hasn't been specified.

bonzoesc 15y ago
That makes it difficult to provide progressive enhancement though. If I use a prefixed property, I have the ability to make sure it works fine without it, and I can assume that in the future, if the semantics of it change when it becomes non-prefixed, it'll either disappear (i.e. if it was a -webkit property being rendered on firefox) or still work (i.e. if it was a -o property being rendered on opera). If I use an experimental non-prefixed property, how do I make sure future browsers that might implement it differently render it usably?