url() fallbacks (was Re: content: url() is bad)

On 4/12/04 9:41 AM, "Anne van Kesteren (fora)" <fora@annevankesteren.nl>
wrote:

> 
>>> Compare:
> 
>>> h1 { content: url(xyzcompany-logo); }
>>> h1 { content: "Logo: " url(xyzcompany-logo); }
>>> h1 { content: "\160  " url(xyzcompany-logo); }
>>> h1 { content: "\feff  " url(xyzcompany-logo); }
>>> h1 { content: url(something) url(xyzcompany-logo); }
> 
>> Do you have a better proposal? I haven't fully thought this through yet.
> 
> I think that when image within a "serie" could not be found, the next
> "serie" (separated by commas) should be used. If none such serie exists,
> as with all the examples from Boris, "contents" should be used instead
> (as final fallback).

Yes, such an "all or nothing" approach to the value makes sense to me, and I
think is in the spirit of how CSS values are supposed to be handled, that
is, if a UA can understand and handle the *entire* value, it should use it,
otherwise it should ignore it.  A URL that fails to load (or is of a type
not handled by the UA, or is too big for the device etc.) seems to fall into
that category.

Perhaps this should be a consideration for all CSS properties that have some
form of URL among their valid values?  E.g.

CSS1:
- background(-image)
  does not have "all or nothing", no explicit fallback (the color is
*always* rendered under the image, thus it isn't a fallback per se).

It might be interesting to be able to say:
  background: url(bigimage.tiff) silver no-repeat 0 0,
              url(smalltileimage.png) white,
              gray;

- list-style(-image)
  does not have "all or nothing", explicit fallback to list-style-type

CSS2.1:
- content
  does not have "all or nothing", no explicit fallback
 
- cursor
  *does* have all or nothing, explicit fallback via comma delimited list

CSS3 UI:
- cursor
  *does* have all or nothing, explicit fallback via comma delimited list
- icon
  *does* have all or nothing, explicit fallback via comma delimited list
(will be in CR draft).

etc.


Tantek

Received on Monday, 12 April 2004 13:42:44 UTC