Re: Updated CSS shaders proposal

On the interactivity issue, issue #3

Given that as currently specified there is no way for the browser to
determine where the mouse pointer is in relation to what the shader has done
with the elements it seems like the spec needs to say that all interactivity
is turned off for elements with CSS shaders applied to them.  In other
words, elements that have CSS shaders applied direclty or indirectly will
not receive mouse events nor touch events at a minimum.  Similarly 'hover'
will no longer work.

Maybe in a future version you can supply some JavaScript to transform the
touch positions?



Another issue, GLSL shader length and limits.

Up until this point, AFAIK, CSS you either have a feature (like 3D css) or
you don't but if you do have the feature then for the most part there aren't
too many situations where you'll run into serious limits.

In other words, while you have to worry that whether or not gradients exist,
if they do exist you can generally count on them working for all reasonable
inputs.

But that's not true with CSS shaders.  It will be very easy to create CSS
shaders that work on some hardware but not on others either by making them
too long or by exceeding other limits of the user's GPU.

WebGL leaves this up to the dev to deal with but it's a programatic API. CSS
is generally declare and forget.

Should it be that if any CSS shader on a page does not compile that all CSS
shaders on the page should be ignored? That would at least mean that you
don't have some elements displaced and others not. You either get everything
you intended or you get your fallback, no CSS shader layout.

Of course that's problematic since CSS shaders can be changed and/or applied
on the fly

Maybe specifying some maximum limits?

Received on Friday, 21 October 2011 00:41:49 UTC