On Wed, 21 Mar 2012 00:57:03 -0700, Brion Vibber brion@pobox.com wrote:
On Mar 19, 2012 8:44 PM, "Daniel Friesen" lists@nadir-seen-fire.com wrote:
CSS image fallbacks may be a little annoying. Last time I checked browsers don't consider "I don't understand that
image filetype." an invalid url(). In other words in:
background-image: url(foo.png); background-image: url(foo.svg); Every browser jumps to url(foo.svg) and the ones that don't understand
.svg's choke.
D'oh! I don't suppose @media queries can help with this... no doesn't look like it.
Ooh! We may be able to handle this like the js/nojs styles.
Have a bit of JS on startup check for svg support and add a class to the HTML root element. Then we just need .svg .foo {} entries with the svg background overrides.
Not ideal but should work, with the downside that non-JS browsers don't get svg.
-- brion
Another theoretical option could be to try and coax the vendors into implementing it.
Add image() into our css and poke all the browser vendors saying that Wikipedia is going to be supporting image() to give it's ui high-quality graphics so they should implement support for it. Most of the relevant browsers should be ones which are on a short release period. So we could try it for a few months to give them time to go through the releases and see if it works.
The browser vendors seam to like everything that they can prance around with demos and high-traffic blog posts for and ignore smaller portions of css. But some of these smaller parts of css3 like image(), @supports, etc... are the really important parts of it. All these new features are near worthless when a number of designs and patterns cannot be done without proper fallbacks like css was intended to have.