CSS Shader - Adobe brings WebGL to CSS | Hacker News Reader

CSS Shader - Adobe brings WebGL to CSS

adobe.com

62 pointsvjeux12 comments

I guess I'm just trying to understand why Abobe went the route of turning DOM elements into 3D rendering contexts, instead of just giving developers a way to get textures from DOM elements, and decide how to use those textures themselves. The latter would be much more useful in my mind (and yes I've written a lot in WebGL). Adobe's approach doesn't stop any cross domain security issues either, and it just limits the flexibility the animations programmer has.

It makes me suspicious that Adobe is just trying to get something that they see as useful for themselves incorporated into Webkit, even though it doesn't fit the WebGL work flow.

Well, this would certainly fit my workflow. Because I'm not a 3D-programmer and this approach is a much better fit for the casual 2D-games I want to make.

I guess I can come around to how this might be useful for some effects. I don't necessarily think it would be useful for 2D games though, as there's a lot going on there so you might be better off to just do a 2D-canvas based game.

Just off the top of my head: cheap glow effect, ripple effect (e.g. when a bomb goes off), post-processing filters for things like film effects, etc. You don't need to be doing 3d work to make great use of shaders.

"instead of just giving developers a way to get textures from DOM elements"

I'm guessing this functionality is already in progress. Canvas has a bunch of draw operations on it and browser makers are already extending it with functions like drawWindow(). I'm guessing it won't be long before we see a Canvas.drawDOM() method

The numerous security issues make it unlikely that a drawWindow will ever make it into the canvas API for content, from my perspective.

Firefox has supported it as an extension for a while now but it's not enabled for content due to the security problems.

No, there are too many security problems. You could do history sniffing with drawWindow(), for example, by making a link and checking the color. Or you could read the contents of cross-domain iframes, allowing web pages to discover your Facebook identity.

It does help cross domain security issues a bit. Without WebGL's readPixels the only possible information leak is a timing attack, which is much less practical.

I was actually referring to the timing attack. And it isn't impractical, it's the reason Firefox and Chrome now require CORS for cross-domain images.

From my discussions with some of the folks implementing this the approach has the advantage of leveraging peoples existing understanding of the DOM.

The security considerations of allowing web content to load arbitrary compiled shaders onto the GPU are important. This of course also applies to ordinary WebGL.

Adobe addresses the topic briefly in their W3C proposal: https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#s...

I wonder how the shaders will be vetted in practice?

While the ability to write your own shaders is awesome, I'm actually most excited about the built-in options. The ability to add a non-crappy (read: not a simple box) dropshadow with one line of CSS makes me jump for joy.

If they pull this off it'll remove one of my biggest sore points from transitioning from Flash. Flash had these filters, and they were incredibly useful (color transform, glow, blur, and dropshadow especially).

Reply on news.ycombinator.com