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

On Wed, Aug 19, 2009 at 3:40 PM, Tab Atkins Jr.<jackalmage@gmail.com> wrote:
> On Wed, Aug 19, 2009 at 8:11 AM, Giuseppe
> Bilotta<giuseppe.bilotta@gmail.com> wrote:
>>
>> This is something I had thought about, in the form fallback(blah,
>> blah, blah) or fallback(mime/type blah,  other/mime blah, etc) (or
>> 'alternatives' instead of 'fallback'), but I thought it would not be
>> taken into consideration because it would make a significant
>> difference from older syntax and thus be totally not backwards
>> compatible.
>
> Any change to the syntax isn't backwards compatible, though.  Minting
> fallback() as an <image> value would actually be fairly non-disruptive
> - you just swap it into existing properties as necessary.

I was actually thinking of making fallback somewhat more generic than
just for image values. However, I'm starting to think that a generic
yet flexible fallback mechanism would be very complex.

One thing that _could_ be done would be extend the url() syntax to be

url(<uri> [<mimetype>] [,<uri> [<mimetype>]*)

which would allow fallbacks in any place where url() is allowed (thus
including images). However, this method does not allow falling back to
non-URI contents.

More about this below.

> A search brought up references to the current Editor's Draft of CSS3
> Images Module, which already has this sort of thing addressed in the
> image() function.
>
> http://dev.w3.org/csswg/css3-images/##image

That's an interesting approach. The proposed notation has a few downsides:

1. there is no provision for specifying MIME types of the linked
image. The standard proposes to look at the extension, which is not a
bad idea per-se, but could be enhanced by allowing an actual MIME type
to be specified after the URI
2. the 'or color' syntax, which is a nice solution to the problem I
exposed above (having non-URI alternatives), is an odd-out with the
'or' separator, and also has the downside of assuming an image with
'no intrinsic dimensions'; some way to specify dimensions would be
nice, although this should be something referred to ALL the fallback
values, probably.

Taking inspiration from this image() draft, then, I would propose the
following new fallback() [name to be decided, maybe alternatives() or
even better something shorter] instead of extending url():

fallback( [ <fallback-decl>,] <fallback-decl-final>)

where a fallback-decl is given by

<fallback-decl> = <uri> [<mimetype>] [<options>]

and

<fallback-decl-final> = <fallback-decl> | value:<value>

(i.e. a fallback declaration is given by a comma-separated list of
'enhanced' URI specifications, except for the last item that may be
something else).

<uri> is either an url() function or an argumento to url() [i.e.,
url() is optional]

<value> is a CSS value that could be used instead of an URI in the
context where fallback is used (e.g. a color, a <glyph>, etc)

<mimetype> is the (optional) MIME type for the referred object. If it
is not specified, and the uri ends with an extension well-known to be
used for files of a given MIME type, the UA SHOULD assume the referred
object to be of that type.

<options> are context-specific options for the given URI; for example,
for images it would be the snap and dpi options.

How does this sound?


-- 
Giuseppe "Oblomov" Bilotta

Received on Wednesday, 19 August 2009 17:58:34 UTC