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