W3C home > Mailing lists > Public > www-style@w3.org > August 2009

[CSS3] content, background-image and fallbacks

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Wed, 19 Aug 2009 14:08:17 +0200
Message-ID: <cb7bb73a0908190508o7196a722hd80c81dc68a69c50@mail.gmail.com>
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?


Giuseppe "Oblomov" Bilotta
Received on Wednesday, 19 August 2009 12:09:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:28 UTC