- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 11 Nov 2011 12:29:11 -0800
- To: Chris Marrin <cmarrin@apple.com>
- Cc: Vincent Hardy <vhardy@adobe.com>, "Gregg Tavares (wrk)" <gman@google.com>, "public-fx@w3.org" <public-fx@w3.org>
On Fri, Nov 11, 2011 at 10:17 AM, Chris Marrin <cmarrin@apple.com> wrote:
> I'm not actually sure of how CSS handles fallback. Maybe we could do this:
>
> .filtered: {
> filter: shader(<my complicated shader>);
> filter: shader(<my less complicated shader>);
> filter: blur(3);
> }
>
> So if the complicated shader fails, it will try the less complicated one. If that fails, it will use a simple blur. Would that work?
No, that sort of fallback is parser-level, to allow you to provide
fallback for *syntax* that legacy UAs don't understand. UAs are
allowed to (and do) throw away all the rules that are "replaced" by
later ones. In your above example, the .filtered class would just
receive a blur(3).
We do have some feature-level fallbacks, but they have to be defined
explicitly. The 'font-family' property takes a list of fonts and uses
the first one it can find that has the correct glyph. The 'image()'
function defined in CSS3 Image Values takes a list of images and
represents the first one that the browser understands. One could
design something similar for shaders, but I'd want a clear explanation
of the use-cases, but I don't think copying the 'image()' solution
would help Gregg.
~TJ
Received on Friday, 11 November 2011 20:29:59 UTC