- From: Chris Marrin <cmarrin@apple.com>
- Date: Fri, 11 Nov 2011 15:14:59 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Vincent Hardy <vhardy@adobe.com>, "Gregg Tavares (wrk)" <gman@google.com>, "public-fx@w3.org" <public-fx@w3.org>
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. ----- ~Chris cmarrin@apple.com
Received on Friday, 11 November 2011 23:15:27 UTC