

What are CSS Shaders? - tilt
http://dstorey.tumblr.com/post/11059109286/cssshaders

======
5hoom
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
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.

------
pilif
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
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> [1]
<http://msdn.microsoft.com/en-us/ie/hh440437>

------
geuis
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.

~~~
vidarh
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
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
Could you expound on your thoughts a bit kayla? I'm unsure on your position.

~~~
kaylarose
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.

