Re: [CSS3] content, background-image and fallbacks

On Wed, Aug 19, 2009 at 7:08 AM, Giuseppe
Bilotta<giuseppe.bilotta@gmail.com> wrote:
> 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]).

The most common need for fallback is in images.  I think it's been
presented before, but I'm of the opinion that a generic functional
syntax would be best, as it wouldn't require possibly screwing with
stable syntaxes, and it wouldn't eat a useful separator character
("/").  Something like "first(url(), url(), ..., color)".  Allow a
mimetype for each of those, and you've got yourself covered.

~TJ

Received on Wednesday, 19 August 2009 12:55:47 UTC