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.