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

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

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Wed, 19 Aug 2009 15:11:38 +0200
Message-ID: <cb7bb73a0908190611t5a3a9d16m6f120e426bd9bd69@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style@w3.org
On Wed, Aug 19, 2009 at 2:54 PM, Tab Atkins Jr.<jackalmage@gmail.com> wrote:
> On Wed, Aug 19, 2009 at 7:08 AM, Giuseppe
> Bilotta<giuseppe.bilotta@gmail.com> wrote:
>>
>> 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.

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.

OTOH, I just thought that it is always possible to specify the same
attribute twice, once with the old syntax and once with the new one,
so that older browsers (which OTOH are the most likely to need the
actual fallback since they are the least likely to support the most
recent formats) would still find something usable.

Where can I find pointers to past discussions on this? Searching
'fallback' and 'alternatives' on the mailing list archive doesn't seem
to give significant references. Also, is there some documentation on
how to prepare formal proposals for this kind of syntax?

Thanks very much,

-- 
Giuseppe "Oblomov" Bilotta
Received on Wednesday, 19 August 2009 13:12:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:20 GMT