Re: [css-shaders] GLSL implementation defined limits

On Fri, Nov 11, 2011 at 3:14 PM, Chris Marrin <cmarrin@apple.com> wrote:
> On Nov 11, 2011, at 3:07 PM, Tab Atkins Jr. wrote:
>> On Fri, Nov 11, 2011 at 3:02 PM, Chris Marrin <cmarrin@apple.com> wrote:
>>> True, but I'm not sure we can solve every problem that this brings up. There are other places in CSS where properties work together to get a desired effect and if they're not all supported you get something less than useful. I think there needs to be a more general CSS solution for that problem. What I was trying to do was to give authors the ability to use more complex shaders and still work everywhere. I can imagine many cases where the fallback shader can be made to do enough of the effect to make it look right in combination.
>>
>> We *are* solving the generic problem with the @supports rule.
>> Unfortunately, I don't think that would help Gregg's use-case. :/
>
> Do you say that because we don't know whether or not the shader will fail when the @supports rule is evaluated, or is there some other way it doesn't meet Gregg's use case? If we could somehow get @supports to give the right answer for shaders, it seems like it would solve Gregg's problem just fine. You make sure you supports all the properties needed for an effect and if not you choose something else.

The former - we don't know if it'll fail until we start running it,
which I think is incompatible with how @supports should work.

Though, on further thought, it might not be incompatible.  It might
just work out of the box, with sufficient word-smithing.  If not,
adding some more syntax to @supports to explicitly address this could
do the job.

~TJ

Received on Friday, 11 November 2011 23:20:13 UTC