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

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

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.

> 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.

Yup, precisely.  One of the wonders of the forward-compatible syntax
and error parsing.  It makes these sorts of changes *way* easier to
deploy.

> 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.

Googling with site: is usually your best bet; the actual archive
search is useless.

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

> Also, is there some documentation on
> how to prepare formal proposals for this kind of syntax?

You don't; you just kick it around on the list and get the editors
interested.  It does help to have a document that explains things
clearly with examples, but that's about the limit.  You have to be
part of the actual WG to write specs.

(At least, that's what I understand, and have always done.)

~TJ

Received on Wednesday, 19 August 2009 13:41:54 UTC