4 ms·

What are CSS Shaders?

45 points by tilt 15y ago

5hoom 15y ago
I'm not a web developer so cannot comment on the merits of this technology, but is anyone else excited by the increasing use of hardware accelerated graphics on the web? Developments like this along with the rise of WebGL would suggest we are going to be seeing a lot more shader files being served to browsers in the near future.
- bgarbiak 15y ago
  I'm excited and a bit afraid at the same time. Excited because hardware supported web pages is something I had wanted for years. I'm not even talking about some fancy possibilities here, just the fact you don't have to worry about performance when user moves a few DOM elements too much is awesome. At the same time I'm worried, because with every new feature like this the web loses a bit of it's greatest beauties, which is simplicity and minimalism. It's not about web development - developers will be fine. Actually, a few more things to learn for a common 'jQuery/CSS guy' could only be a good thing. My point is: without this simplicity the web could transform from being a fast and accessible source of information into heavy, bloated piece of multimedia provider which drains your batteries, CPUs usage and - foremostly - your patience. The ability to load a "Quake 3" level with a web browser is amazing but the internet made with websites that load some sort of "Quake 3" levels 90% of times is not a lovely perspective. Well, I think I can sum up my "rant" saying it's another "books versus TV" type of conflict.
geuis 15y ago
I think I'm a bit of a stick in the mud, as far as frontend engineers goes. I can visually see the effects that shaders allow in the Adobe demo videos. They're quite impressive. However, at this time I just don't think this has a place in css. SVG maybe, perhaps DOM api's accessible with javascript, but not css. My thinking is that this is shoveling yet another spec that fellows like me have to learn and support. For years, css2.1 wasn't quite enough to really do what we needed. To do even slightly advanced layouts we had to come up with all kinds of crazy html/css/image arrangements to do things. css3 was a welcome addition finally, especially as its widely supported in modern browsers now. It filled in many of the gaps that were missing. css3 also added some interesting new features relating to animations. We got transitions, translations, animations, etc. The specs on these are fairly simple and really powerful once you learn them. But unfortunately css isn't the only thing we have to know to do our jobs. We have to know html(5) layouts and rules. We have to know all of the in's and out's of how every popular browser implements the layout of html and css and all of their bugs. We've had to learn to use the newer html5 features, almost all of which were welcome. Even here though, we run into insanely stupid cross-platform issues like dealing with media formats for video and audio tags. Can you name support matrix of browsers for video and audio? I can, and it sucks that I had to learn that. And lets also be honest, you can't truly be a well-rounded frontend engineer if you don't have at least a moderate amount of experience writing javascript. These days, you can't just get by only being the member of the team that lays out html & css. You need to be able to write javascript to make our increasingly interactive pages come alive. Not only is javascript a lovely yet tricky language to learn, the bigger issue is dealing with the DOM api's for each and every interactive DOM element. And you have to know those DOM api's and how they differ for the most common browser platforms. Yeah, older versions of Internet Explorer are still popular enough to need supporting and their DOM api's can be insanely buggy and inconsistent. To layer on top of that, now that we have awesome css3 features we also have to learn the DOM api's for those too! At this point, many people reading this might start the valid argument that we have good javascript libraries (ok, only one and that's jQuery) to smooth over lots of those rough bits. Yeah, they help tremendously but its yet another thing that has to be learned to be effective. Another thing is that css is really meant for layout and styling. While I truly love css3 animations and transitions, they're right on the border of needing to be somewhere else. They're wonderful for spicing up a page and doing cool designs that were impossible before but if they were even slightly more complex then I'd start arguing they shouldn't be in css. Finally, getting back to the proposed css filters, I feel those are finally crossing that line. Like I said earlier, I may well be a stick in the mud Luddite but adding yet another css feature that literally lets you run code on the GPU is just too much. Its not layout any more and its moving into something further out than the css3 animation line. One of the few reasons that I am up to speed on all of this stuff is that I've been doing it for years. I was able to learn this stuff gradually as it came out and get pretty good at it. However, if I were a younger version of myself getting started now I might read this comment I'm writing at length and get totally turned off from even trying to do frontend development. I know there have to be others who disagree with my position. I'd love to get some other points of view that tell me where I'm wrong so I can re-analyze my thoughts on this. I'm open to change. Its just one more thing I have to learn.
- melling 15y ago
  I'm mostly a server side guy so maybe i don't see the problem. :-). However, the examples given do seem to make sense. I don't think everything should have to be turned into svg to apply the effects.
- vidarh 15y ago
  I think CSS is exactly where stuff like this belongs. The more of the page layout that is defined in mostly static ways, the easier creating tools to do the layout becomes. E.g. witness the multitude of websites with tools create CSS3 for various effects.
  - kaylarose 15y ago
    And the easier sites become to maintain. Which is easier, maintaining rounded corners applied via CSS3, the old-school sliding doors, or JS? See also: text shadow, and box-shadow.
    - geuis 15y ago
      Could you expound on your thoughts a bit kayla? I'm unsure on your position.
      - kaylarose 15y ago
        Let me precede this by saying - JS is one of my favorite programming languages. And I agree, unless you know JS you will not be a well-rounded client-side engineer. But... Unless the styles are integral to the functionality of a certain component (usually layout or box model), I prefer to keep the styles where they belong. To me, it is much easier to maintain styles in a stylesheet - especially if you have jr. devs or designers working with you. Yes, CSS easily becomes a big ball of mud. But if you organize it properly - and maybe even use something like LESS or SASS - it is much more maintainable. It is also the responsibility of a good developer to know when to apply certain techniques. For instance - a simple "grow on hover" is very easy to achieve via CSS animations - with a fallback to non-animated grow on IE etc. But a "grow on hover and then do crazy animations" is probably better accomplished with JS.
pilif 15y ago
Why did they need to propose the name filter: for the property? Old versions of IE (5.5ish to 8) supported a filter-property that was hooking into DirectX to do something similar, but by no means identical. filter: is still used for the various PNG fixes out there. This is going to cause endless issues and confusion and I just hope IE copes with a filter: it doesn't understand or we will be back to browser-sniffing and serving different markup to different browsers.
- dstorey 15y ago
  The CSS filter property comes from SVG [0], and has been around for quite a long time already. IE 10 will support filters in SVG [1], so IE should be able to cope with it ok. [0] http://www.w3.org/TR/SVG10/filters.html#FilterProperty http://www.w3.org/TR/SVG10/filters.html#FilterProperty [1] http://msdn.microsoft.com/en-us/ie/hh440437 http://msdn.microsoft.com/en-us/ie/hh440437

45 points by tilt 15y ago

5hoom 15y ago

I'm not a web developer so cannot comment on the merits of this technology, but is anyone else excited by the increasing use of hardware accelerated graphics on the web? Developments like this along with the rise of WebGL would suggest we are going to be seeing a lot more shader files being served to browsers in the near future.

bgarbiak 15y ago
I'm excited and a bit afraid at the same time. Excited because hardware supported web pages is something I had wanted for years. I'm not even talking about some fancy possibilities here, just the fact you don't have to worry about performance when user moves a few DOM elements too much is awesome. At the same time I'm worried, because with every new feature like this the web loses a bit of it's greatest beauties, which is simplicity and minimalism. It's not about web development - developers will be fine. Actually, a few more things to learn for a common 'jQuery/CSS guy' could only be a good thing. My point is: without this simplicity the web could transform from being a fast and accessible source of information into heavy, bloated piece of multimedia provider which drains your batteries, CPUs usage and - foremostly - your patience. The ability to load a "Quake 3" level with a web browser is amazing but the internet made with websites that load some sort of "Quake 3" levels 90% of times is not a lovely perspective. Well, I think I can sum up my "rant" saying it's another "books versus TV" type of conflict.

geuis 15y ago

I think I'm a bit of a stick in the mud, as far as frontend engineers goes. I can visually see the effects that shaders allow in the Adobe demo videos. They're quite impressive. However, at this time I just don't think this has a place in css. SVG maybe, perhaps DOM api's accessible with javascript, but not css. My thinking is that this is shoveling yet another spec that fellows like me have to learn and support. For years, css2.1 wasn't quite enough to really do what we needed. To do even slightly advanced layouts we had to come up with all kinds of crazy html/css/image arrangements to do things. css3 was a welcome addition finally, especially as its widely supported in modern browsers now. It filled in many of the gaps that were missing. css3 also added some interesting new features relating to animations. We got transitions, translations, animations, etc. The specs on these are fairly simple and really powerful once you learn them. But unfortunately css isn't the only thing we have to know to do our jobs. We have to know html(5) layouts and rules. We have to know all of the in's and out's of how every popular browser implements the layout of html and css and all of their bugs. We've had to learn to use the newer html5 features, almost all of which were welcome. Even here though, we run into insanely stupid cross-platform issues like dealing with media formats for video and audio tags. Can you name support matrix of browsers for video and audio? I can, and it sucks that I had to learn that. And lets also be honest, you can't truly be a well-rounded frontend engineer if you don't have at least a moderate amount of experience writing javascript. These days, you can't just get by only being the member of the team that lays out html & css. You need to be able to write javascript to make our increasingly interactive pages come alive. Not only is javascript a lovely yet tricky language to learn, the bigger issue is dealing with the DOM api's for each and every interactive DOM element. And you have to know those DOM api's and how they differ for the most common browser platforms. Yeah, older versions of Internet Explorer are still popular enough to need supporting and their DOM api's can be insanely buggy and inconsistent. To layer on top of that, now that we have awesome css3 features we also have to learn the DOM api's for those too! At this point, many people reading this might start the valid argument that we have good javascript libraries (ok, only one and that's jQuery) to smooth over lots of those rough bits. Yeah, they help tremendously but its yet another thing that has to be learned to be effective. Another thing is that css is really meant for layout and styling. While I truly love css3 animations and transitions, they're right on the border of needing to be somewhere else. They're wonderful for spicing up a page and doing cool designs that were impossible before but if they were even slightly more complex then I'd start arguing they shouldn't be in css. Finally, getting back to the proposed css filters, I feel those are finally crossing that line. Like I said earlier, I may well be a stick in the mud Luddite but adding yet another css feature that literally lets you run code on the GPU is just too much. Its not layout any more and its moving into something further out than the css3 animation line. One of the few reasons that I am up to speed on all of this stuff is that I've been doing it for years. I was able to learn this stuff gradually as it came out and get pretty good at it. However, if I were a younger version of myself getting started now I might read this comment I'm writing at length and get totally turned off from even trying to do frontend development. I know there have to be others who disagree with my position. I'd love to get some other points of view that tell me where I'm wrong so I can re-analyze my thoughts on this. I'm open to change. Its just one more thing I have to learn.

melling 15y ago
I'm mostly a server side guy so maybe i don't see the problem. :-). However, the examples given do seem to make sense. I don't think everything should have to be turned into svg to apply the effects.
vidarh 15y ago
I think CSS is exactly where stuff like this belongs. The more of the page layout that is defined in mostly static ways, the easier creating tools to do the layout becomes. E.g. witness the multitude of websites with tools create CSS3 for various effects.
- kaylarose 15y ago
  And the easier sites become to maintain. Which is easier, maintaining rounded corners applied via CSS3, the old-school sliding doors, or JS? See also: text shadow, and box-shadow.
  - geuis 15y ago
    Could you expound on your thoughts a bit kayla? I'm unsure on your position.
    - kaylarose 15y ago
      Let me precede this by saying - JS is one of my favorite programming languages. And I agree, unless you know JS you will not be a well-rounded client-side engineer. But... Unless the styles are integral to the functionality of a certain component (usually layout or box model), I prefer to keep the styles where they belong. To me, it is much easier to maintain styles in a stylesheet - especially if you have jr. devs or designers working with you. Yes, CSS easily becomes a big ball of mud. But if you organize it properly - and maybe even use something like LESS or SASS - it is much more maintainable. It is also the responsibility of a good developer to know when to apply certain techniques. For instance - a simple "grow on hover" is very easy to achieve via CSS animations - with a fallback to non-animated grow on IE etc. But a "grow on hover and then do crazy animations" is probably better accomplished with JS.

pilif 15y ago

Why did they need to propose the name filter: for the property? Old versions of IE (5.5ish to 8) supported a filter-property that was hooking into DirectX to do something similar, but by no means identical. filter: is still used for the various PNG fixes out there. This is going to cause endless issues and confusion and I just hope IE copes with a filter: it doesn't understand or we will be back to browser-sniffing and serving different markup to different browsers.

dstorey 15y ago
The CSS filter property comes from SVG [0], and has been around for quite a long time already. IE 10 will support filters in SVG [1], so IE should be able to cope with it ok. [0] http://www.w3.org/TR/SVG10/filters.html#FilterProperty http://www.w3.org/TR/SVG10/filters.html#FilterProperty [1] http://msdn.microsoft.com/en-us/ie/hh440437 http://msdn.microsoft.com/en-us/ie/hh440437