6 ms·

Whatever happened to web standards? background: -o-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%); background: -ms-linear-gradient(top, #ECEC

Whatever happened to web standards? background: -o-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%); background: -ms-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%); background: -moz-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%); background: -webkit-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%); background: linear-gradient(top, #ECECEC 50%, #D1D1D1 100%); Wasn't the whole point of web standards to move beyond bullshit like that?

Groxx 15y ago
Yes. But forward-consistency and early access are both valuable for site-makers, so pre-standardized features are prefixed in case they change when the standard comes out. If you want to use standards, you need to select what's available to you by your target audience, and ignore the non-standard-compliant cases. If you want to do things, and keep as large a target audience as possible, you need to either hack them together with old tech or jump through hoops to do it with new tech. Especially given the web's rocky past, many developers would prefer to use the new stuff. And there are tools to help - Less or Scss, for instance, make those prefixes essentially free. But that's just a fact of programming in general - you could write a web-app and get it on any computer with a modern browser. Or you could write it in Ruby, and get it on any computer with a Ruby interpreter, and include an installer / instructions for those that don't. Or you could write it in C, and get it on any computer with a C compiler, and you may have to write your own library code / preprocessor controls to handle strange architectures, and change things based on your target OS. Or you could write it in assembly, and have it run on almost anything, but have to handle multiple flavors and an endless variety of available memory, and input and output devices. Or do any of the above, pick a subset of the devices that are technically capable of reading your code, and screw the rest. Porting Doom 3 to Commodore 64 probably isn't going to work, despite the code being written to the standard of whatever language it was written in (probably C, which I will assume for now), and compilers adhering to the same standard for targeting the C64. That you can't run Doom 3 on your C64 doesn't mean the standard is broken or useless. -- The nice thing about those prefixes is that, in general, it means you can use new features and know they'll work as you designed for years to come. If a re-design every year or so is cheaper than vendor prefixes, then yes, they're a pain - wait until the standard comes out. If not, they're a time saver to get handy new features a couple years early, and free switch-over to the standard when and where it's implemented.
- kennywinker 15y ago
  I agree it's better than what we had before, but... 1. Basically now we're stuck with +five lines to specify one thing. When can we switch to just one line, and drop the prefix versions? I doubt any time soon. We're only now dropping support for IE6. 2. how useful is it to be able to build stuff that only works in some browsers? I get that it helps push stuff forward, but you get myriad posts on HN that are like "look at this sweet thing I built (only works on chrome)" or something similar. Good for you, you built something cool, but you might as well have done it as a native app because I can't run it without downloading a different browser. Interoperability is one of the basic premises of the web.
  - Groxx 15y ago
    Which is why many projects have moved beyond writing such things by hand, and use css-compilers. And interoperability is never one of the premises of the bleeding edge, which is generally what those myriad posts touch on (HTML5 audio, for example). Many of the older CSS3 specs are now supported in modern browsers, so I'd say we're pretty close, really. Or now, if you only support the most recent version (which accounts for what, >50%?). A stupendously far cry from where we used to be not too long ago.
mzarate06 15y ago
The benefit of being able to use prefixed features sooner outweighs the cost of having to wait for the standards process to complete, then for browser vendors to implement the features, then for those features to ship in some future version. Prefixed features are about creating value sooner, and they do, but it is unfortunate that the standards process can't keep up.
po 15y ago
A Javascript-based solution to this problem: let Javascript customize the web-standard version to your browser's version if supported. http://leaverou.github.com/prefixfree/ http://leaverou.github.com/prefixfree/ Not a perfect solution, but it's interesting.
ugh 15y ago
It's not bullshit, it's pretty great and much better than what we had before. This is a desired result of the standards process, exactly the opposite of what you seem to think it is. There has to be a way for browsers to test new features in the wild. That's how it's always been and will always be, which also has the nice side effect that the standards body (or single vendors inside the body) cannot slow everyone down. If everyone could only implement features when they are really done and part of the standard the world would be a dreary place indeed. The problem with this is that when two browsers implement a feature with either a different syntax or different results you would be forced to do browser detection and have two stylesheets or use hacks. That reallx used to happen and it sucked. The prefixes avoid this problem altogether. When everyone agrees about a feature the prefixes can be dropped – in this case (if the syntax doesn't change) nobody even has to change anything. All the designer has to do is delete lines as more browsers adopt the standard. What you are seeing is the necessary result of a standards process with many vendors.
notatoad 15y ago
i believe that linear-gradient without any prefix works in the latest version of all those browsers.
- kennywinker 15y ago
  So how long until we can drop the prefix versions. If the answer is > 2 years I say --prefix tags are bullshit.
  - notatoad 15y ago
    I don't use prefixed versions in any of my work. pretty much all of them are for non-layout styles, which just means that people who don't upgrade their browsers to the latest version get a slightly uglier version of the site. I like to give people a reason to upgrade without breaking my site for them.
rmc 15y ago
The "background linear-gradient" is the web standard and supported by all. the -$PREFIX ones are for old versions of those browsers.

Groxx 15y ago

Yes. But forward-consistency and early access are both valuable for site-makers, so pre-standardized features are prefixed in case they change when the standard comes out. If you want to use standards, you need to select what's available to you by your target audience, and ignore the non-standard-compliant cases. If you want to do things, and keep as large a target audience as possible, you need to either hack them together with old tech or jump through hoops to do it with new tech. Especially given the web's rocky past, many developers would prefer to use the new stuff. And there are tools to help - Less or Scss, for instance, make those prefixes essentially free. But that's just a fact of programming in general - you could write a web-app and get it on any computer with a modern browser. Or you could write it in Ruby, and get it on any computer with a Ruby interpreter, and include an installer / instructions for those that don't. Or you could write it in C, and get it on any computer with a C compiler, and you may have to write your own library code / preprocessor controls to handle strange architectures, and change things based on your target OS. Or you could write it in assembly, and have it run on almost anything, but have to handle multiple flavors and an endless variety of available memory, and input and output devices. Or do any of the above, pick a subset of the devices that are technically capable of reading your code, and screw the rest. Porting Doom 3 to Commodore 64 probably isn't going to work, despite the code being written to the standard of whatever language it was written in (probably C, which I will assume for now), and compilers adhering to the same standard for targeting the C64. That you can't run Doom 3 on your C64 doesn't mean the standard is broken or useless. -- The nice thing about those prefixes is that, in general, it means you can use new features and know they'll work as you designed for years to come. If a re-design every year or so is cheaper than vendor prefixes, then yes, they're a pain - wait until the standard comes out. If not, they're a time saver to get handy new features a couple years early, and free switch-over to the standard when and where it's implemented.

kennywinker 15y ago
I agree it's better than what we had before, but... 1. Basically now we're stuck with +five lines to specify one thing. When can we switch to just one line, and drop the prefix versions? I doubt any time soon. We're only now dropping support for IE6. 2. how useful is it to be able to build stuff that only works in some browsers? I get that it helps push stuff forward, but you get myriad posts on HN that are like "look at this sweet thing I built (only works on chrome)" or something similar. Good for you, you built something cool, but you might as well have done it as a native app because I can't run it without downloading a different browser. Interoperability is one of the basic premises of the web.
- Groxx 15y ago
  Which is why many projects have moved beyond writing such things by hand, and use css-compilers. And interoperability is never one of the premises of the bleeding edge, which is generally what those myriad posts touch on (HTML5 audio, for example). Many of the older CSS3 specs are now supported in modern browsers, so I'd say we're pretty close, really. Or now, if you only support the most recent version (which accounts for what, >50%?). A stupendously far cry from where we used to be not too long ago.

mzarate06 15y ago

The benefit of being able to use prefixed features sooner outweighs the cost of having to wait for the standards process to complete, then for browser vendors to implement the features, then for those features to ship in some future version. Prefixed features are about creating value sooner, and they do, but it is unfortunate that the standards process can't keep up.

po 15y ago

A Javascript-based solution to this problem: let Javascript customize the web-standard version to your browser's version if supported. http://leaverou.github.com/prefixfree/ http://leaverou.github.com/prefixfree/ Not a perfect solution, but it's interesting.

ugh 15y ago

It's not bullshit, it's pretty great and much better than what we had before. This is a desired result of the standards process, exactly the opposite of what you seem to think it is. There has to be a way for browsers to test new features in the wild. That's how it's always been and will always be, which also has the nice side effect that the standards body (or single vendors inside the body) cannot slow everyone down. If everyone could only implement features when they are really done and part of the standard the world would be a dreary place indeed. The problem with this is that when two browsers implement a feature with either a different syntax or different results you would be forced to do browser detection and have two stylesheets or use hacks. That reallx used to happen and it sucked. The prefixes avoid this problem altogether. When everyone agrees about a feature the prefixes can be dropped – in this case (if the syntax doesn't change) nobody even has to change anything. All the designer has to do is delete lines as more browsers adopt the standard. What you are seeing is the necessary result of a standards process with many vendors.

notatoad 15y ago

i believe that linear-gradient without any prefix works in the latest version of all those browsers.

kennywinker 15y ago
So how long until we can drop the prefix versions. If the answer is > 2 years I say --prefix tags are bullshit.
- notatoad 15y ago
  I don't use prefixed versions in any of my work. pretty much all of them are for non-layout styles, which just means that people who don't upgrade their browsers to the latest version get a slightly uglier version of the site. I like to give people a reason to upgrade without breaking my site for them.

rmc 15y ago

The "background linear-gradient" is the web standard and supported by all. the -$PREFIX ones are for old versions of those browsers.