6 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? The W3C meeting discussion on this was very depressing. Rather than trying to collaborate on standards that move the web forward, Webkit contributors want to get a leg up with proprietary extensions and make the others struggle to catch up. tantek: I think if you're working on open standards, you should propose your features before you implement them and discuss that here. smfr: We can't do that. sylvaing: We can't do that either. tantek: We're going to push you to do that sooner and sooner. jdaggett: If you're proposing something that's going to be put on a Web page, how is that proprietary? http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h... And we've just started this developer nightmare; right now it's mainly focused on CSS prefixing. Thanks to Apple refusing to share its touch patents, the W3C is stalled on touch event standards as well.

macspoofing 15y ago
>Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution No, it's not, but it isn't going away. Designers and Web Developers want to do more than current standards (and browser implementations) allow for.
rmc 15y ago
Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution A lot of the new CSS stuff doesn't require the vendor prefixes, since those vendors now support the prefix-less version. So you don't need to go "-webkit-border-radius: … -moz-border-radius: …", instead do "border-radius: …". We're at the stage where we need less CSS declarations. The problem is that some sites only have "-webkit-border-radius:…". They should just drop the "-webkit-".
- dmethvin 15y ago
  "A lot" isn't really true, here is some quantification: https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility Long-standing ones like border-radius are unprefixed but most of the recent ones like transition are not. And the overhanging problem for non-Webkit vendors is that all that legacy content out there prefixed with -webkit- isn't likely to be fixed until their next design iteration, if ever.
  - MatthewPhillips 15y ago
    It's a problem only in that other vendors want the sites to work with their browser. For really popular sites Mozilla hardcodes workarounds, it's very unfortunate. There's a fine line between sticking to spec and bad user experience so sometimes the vendors are forced to do things they'd prefer not to. From my perspective the market should work things out. If a transition doesn't work in Firefox, those users will complain and the developers will fix it; or they won't and people will stop using the services. We are to blame on HN because we upvote blog posts when someone releases a css3 flower that only renders in webkit. We are encouraging the behavior, and ultimately it's users that suffer.
    - khuey 15y ago
      Do you have links to those workarounds? As far as I know Mozilla is the only major browser (out of IE, Chrome, Opera, and Safari) that doesn't have site specific hacks/workarounds.
bonzoesc 15y ago
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?
MatthewPhillips 15y ago
You only need to use prefixes on experimental not-yet-standard features. When the feature is standardized the prefixes are dropped. If you want to only support standardized features then only support standardized features. That's a decision for individual developers to make. What you are proposing is to strip developers of the ability to test out non-standard features.
- huxley 15y ago
  Agreed. I'm concerned that this backlash will also slow the adoption of CSS3 features back to the glacial pace we saw with CSS2.x
- dmethvin 15y ago
  > When the feature is standardized the prefixes are dropped. More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that. > What you are proposing is to strip developers of the ability to test out non-standard features. If it's only the developers we're inconveniencing, then sure let's have the W3C dictate that prefixed features are available in preview/beta/canary builds but disabled in builds intended for non-developer release. That would create some healthy pressure to get things standardized quickly, eh? > If you want to only support standardized features then only support standardized features. Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.
  - MatthewPhillips 15y ago
    > More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that. I think you're misattributing malice here. This isn't a WebKit only issue, this is a first-to-market issue. When some new css or js feature is proposed and vendors implement it with the prefix, some developers rush to hack on it, submit their demos to HN, and then forget about it weeks later. They don't bother to go back and update the css later with other prefixes. The same issue exists when WebKit isn't the first to market. WebKit doesn't support calc() yet. Mozilla does. Plenty of abandoned webpages will never be updated with other prefixes. But are these serious websites/businesses? Is Facebook or Twitter sticking in -webkit and never bothering to go back? >Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them. Legacy content would still be broken because sparkle will likely be changed in the process of standardization. IndexedDB has seen some dramatic changes in the course of its development; all those sites that implemented an earlier version will be broken when the standard is finalized. The vendor prefix sends a warning to the developers. Browser sniffing is a far bigger problem than vendor prefixes. Google is one of the worst offenders, especially in mobile where they send UAs not equal to iOS or Android to some poorer version.
chc 15y ago
If we allowed the W3C to become a bottleneck like you propose rather than a seal of approval like it is in practice, we wouldn't have CSS transitions in any browser this decade, we wouldn't have AJAX, we wouldn't have canvas, etc. It would be really nice if things could work the way you want, but history has shown time and again that if progress in Web standards is going to proceed at a reasonable pace, it is almost always implemented as a proof-of-concept and then standardized once its utility is recognized. This back-and-forth between shipping code and the standards bodies has evolved as part of the process. And contrary to your claim that prefixes are just applied blindly, some CSS features have indeed been implemented differently by different browsers — gradients and the flexible box model, to name just a couple. Prefixing is the only reliable way to get the feature before the W3C actually produces a standard with it 10-15 years down the road (I wish that was hyperbole, but it isn't — just look at how long they plugged away at XHTML 2 with no end in sight before everybody got tired of waiting and started implementing HTML5). The point of prefixes is to ensure that the W3C are never faced with a choice between standardizing a CSS feature against their will and breaking the Web. Although I don't like the bloat from an ideological standpoint, in practice this is the best way we've come up with. But to make reading, writing and maintenance easier, I generally like using a CSS metalanguage with a library like SASS+Compass or Stylus+Nib. That way, you can just write, say, "transition: color .5s linear" and it'll get translated into the appropriate cross-browser code.
ugh 15y ago
The alternative – no prefixes – is even more horrible. That would be chaos and disaster. Webkit’s might is the problem here. Dropping prefixes without having some alternative solution in place is definitely not the solution. That’s why it’s a hard problem.

macspoofing 15y ago

>Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution No, it's not, but it isn't going away. Designers and Web Developers want to do more than current standards (and browser implementations) allow for.

rmc 15y ago

Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution A lot of the new CSS stuff doesn't require the vendor prefixes, since those vendors now support the prefix-less version. So you don't need to go "-webkit-border-radius: … -moz-border-radius: …", instead do "border-radius: …". We're at the stage where we need less CSS declarations. The problem is that some sites only have "-webkit-border-radius:…". They should just drop the "-webkit-".

dmethvin 15y ago
"A lot" isn't really true, here is some quantification: https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility Long-standing ones like border-radius are unprefixed but most of the recent ones like transition are not. And the overhanging problem for non-Webkit vendors is that all that legacy content out there prefixed with -webkit- isn't likely to be fixed until their next design iteration, if ever.
- MatthewPhillips 15y ago
  It's a problem only in that other vendors want the sites to work with their browser. For really popular sites Mozilla hardcodes workarounds, it's very unfortunate. There's a fine line between sticking to spec and bad user experience so sometimes the vendors are forced to do things they'd prefer not to. From my perspective the market should work things out. If a transition doesn't work in Firefox, those users will complain and the developers will fix it; or they won't and people will stop using the services. We are to blame on HN because we upvote blog posts when someone releases a css3 flower that only renders in webkit. We are encouraging the behavior, and ultimately it's users that suffer.
  - khuey 15y ago
    Do you have links to those workarounds? As far as I know Mozilla is the only major browser (out of IE, Chrome, Opera, and Safari) that doesn't have site specific hacks/workarounds.

bonzoesc 15y ago

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?

MatthewPhillips 15y ago

You only need to use prefixes on experimental not-yet-standard features. When the feature is standardized the prefixes are dropped. If you want to only support standardized features then only support standardized features. That's a decision for individual developers to make. What you are proposing is to strip developers of the ability to test out non-standard features.

huxley 15y ago
Agreed. I'm concerned that this backlash will also slow the adoption of CSS3 features back to the glacial pace we saw with CSS2.x
dmethvin 15y ago
> When the feature is standardized the prefixes are dropped. More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that. > What you are proposing is to strip developers of the ability to test out non-standard features. If it's only the developers we're inconveniencing, then sure let's have the W3C dictate that prefixed features are available in preview/beta/canary builds but disabled in builds intended for non-developer release. That would create some healthy pressure to get things standardized quickly, eh? > If you want to only support standardized features then only support standardized features. Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.
- MatthewPhillips 15y ago
  > More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that. I think you're misattributing malice here. This isn't a WebKit only issue, this is a first-to-market issue. When some new css or js feature is proposed and vendors implement it with the prefix, some developers rush to hack on it, submit their demos to HN, and then forget about it weeks later. They don't bother to go back and update the css later with other prefixes. The same issue exists when WebKit isn't the first to market. WebKit doesn't support calc() yet. Mozilla does. Plenty of abandoned webpages will never be updated with other prefixes. But are these serious websites/businesses? Is Facebook or Twitter sticking in -webkit and never bothering to go back? >Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them. Legacy content would still be broken because sparkle will likely be changed in the process of standardization. IndexedDB has seen some dramatic changes in the course of its development; all those sites that implemented an earlier version will be broken when the standard is finalized. The vendor prefix sends a warning to the developers. Browser sniffing is a far bigger problem than vendor prefixes. Google is one of the worst offenders, especially in mobile where they send UAs not equal to iOS or Android to some poorer version.

chc 15y ago

If we allowed the W3C to become a bottleneck like you propose rather than a seal of approval like it is in practice, we wouldn't have CSS transitions in any browser this decade, we wouldn't have AJAX, we wouldn't have canvas, etc. It would be really nice if things could work the way you want, but history has shown time and again that if progress in Web standards is going to proceed at a reasonable pace, it is almost always implemented as a proof-of-concept and then standardized once its utility is recognized. This back-and-forth between shipping code and the standards bodies has evolved as part of the process. And contrary to your claim that prefixes are just applied blindly, some CSS features have indeed been implemented differently by different browsers — gradients and the flexible box model, to name just a couple. Prefixing is the only reliable way to get the feature before the W3C actually produces a standard with it 10-15 years down the road (I wish that was hyperbole, but it isn't — just look at how long they plugged away at XHTML 2 with no end in sight before everybody got tired of waiting and started implementing HTML5). The point of prefixes is to ensure that the W3C are never faced with a choice between standardizing a CSS feature against their will and breaking the Web. Although I don't like the bloat from an ideological standpoint, in practice this is the best way we've come up with. But to make reading, writing and maintenance easier, I generally like using a CSS metalanguage with a library like SASS+Compass or Stylus+Nib. That way, you can just write, say, "transition: color .5s linear" and it'll get translated into the appropriate cross-browser code.

ugh 15y ago

The alternative – no prefixes – is even more horrible. That would be chaos and disaster. Webkit’s might is the problem here. Dropping prefixes without having some alternative solution in place is definitely not the solution. That’s why it’s a hard problem.