- From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
- Date: Wed, 19 Aug 2009 14:08:17 +0200
- To: www-style@w3.org
Hello all, I've recently found myself considering what kind of fallback capabilities current web standards offer, in case where referenced content is either unavailable or unsupported by user agents. The situation is not particularly nice, although some form of fallback support is being built e.g. in HTML5 with the 'source' tag for audio and video (although it is not being added to img, which is a pity; but anyway, that's for another place to discusse). I was now looking at the fallback capabilities offered by CSS3. If I'm not mistaken, CSS3 offers fallback only for a few properties (namely, for what I could see, font-family and content; anything else I missed), but is missing it for other properties where it might still be needed, e.g. border-image and background-image (in fact, I first started looking at fallback capabilities specifically because I discovered that Opera supported SVG images for background while Firefox did not, which meant I could not offer a prerender of the SVG to Firefox users, for example). What makes things slightly worse is the fact that in the font-family and content properties fallback is offered by providing a sequence of comma-separated values, a syntax that could not be extended to e.g. background-image where the comma-separated list of values is already accepted, but with a different meaning (multiple images instead of fallback). Additionally, the extremely limited fallback capability offered by border-image uses the slash (/) as a separator instead of the comma. (Perusing the www-style archives I saw a mention of a rpoposoal to use / consistently for fallbacks, and that it was rejected, but I could not find a reference to the actual motivations for the rejection.) Another important limitation to the present fallback mechanism in CSS3: when the fallback is due not to a broken reference but to an unsupported MIME type, user agents need to hit each one of the fallbacks until a supported one is found. In the hopes that the affected parts of CSS3 are not in such an advanced state of drafting that such changes are not allowed anymore, I think it would be better to define a consistent interface for fallbacks, usable in all properties (that can make use of it), with a provision for the specification of the MIME type for linked content. I'll have a better look at the mailing list archives looking for the motivations behind the rejection of / as separator for alternatives (even though I was actually thinking of |, whoe traditional meaning is to present alternatives, and which doesn't conflict with the / in the MIME types), although pointers would be appreciated. For the MIME type, I was thinking of some kind of extensions to the url() syntax, something like url(someuri [mime/type]). Suggestions? Comments? Regards, -- Giuseppe "Oblomov" Bilotta
Received on Wednesday, 19 August 2009 12:09:17 UTC