Re: Generic Fallback Mechanism - added proposal: simple tying of properties

On Mon, 08 May 2006 12:07:13 +0300, Laurens Holst
<lholst@students.cs.uu.nl> wrote:

**snip
>> Generic fallback mechanism
>> (Please discuss the idea and not the syntax itself, I am sure W3 would
>> find good ways to realise it.)
>> background: [transparent url(grayishsemitransparent.png) repeat]
>>             [gray url(grayishopaque.jpg) 50% 50% no-repeat]
>>             [gray];
>>
>
> Hey Emrah,
>
> I think it sounds sensible, although there are of course a million ways
> for the syntax. E.g. one case that you didn’t think of and that the
> syntax you propose doesn’t take care of is that these things usually
> span multiple properties; in the case of background-image there is a
> convenient ‘background’ shorthand which allows you to modify several
> separate properties at once (or ‘font’ for font-family), but this isn’t
> always the case of course, and this also might not always be convenient.
>
> Just one example of this, when changing the background to a fallback
> colour when the image doesn’t work, one might often also want to change
> the text colour. Imagine a black image which should have white text, and
> a fallback background colour of ‘inherit’ or ‘transparent’ (i.e. the
> parent’s colour) in which case the colour should also be reset to  
> inherit.

Thanks a lot for taking your time to add valuable comments to the idea.

You are right. It would be much more complete if we could tie it with
related styles, but I wanted to keep things simple, and rely on the
designer to care for each fallback situation, in the sense that the
designer should provide similar colored results for each fallback block.
This is only a little different than the current situation: Authors should
define consistent background-colors for elements with background-images:
The user has to be presented with an appropriate bg color until the images
are loaded (which may indeed take a while) or not loaded at all anyway.
Similarly, jumping from black to white as fallback bg color should and
could be avoided easily by the authors.

Being able to define foreground text color separately from background
color *without* the possibility of being able to define all those in a
single property instead, in itself, is problematic (Both should be
possible).


> You dismiss this particular case in your post, but I think it should be
> carefully considered and an inherent part of the fallback mechanism. If
> you want this to be generic (which I think is a good idea), there will
> be many more occurances where different properties have to be set when a
> resource isn’t loaded.

I am afraid, that with a more complex syntax, people may start
complaining. However, there could be simple syntax to 'tie' properties
such as:

#myelementonanotherelement {
background-color: rgb(233, 150, 60);
color: #55C;
background-color: rgba(115,124,25,50) / color: #00A;
}

What this simple tying would allow us to do would be providing a separate
background-color to older UI's which doesn't support RGBA values, while
serving the new ones a RGBA value letting some color of the parent
element, allowing us to use a different foreground text color. Actually,
this is a much needed functionality: We can define alpha / opacity values,
but we can't define a separete foreground text color when opacity is not
supported, but the following should solve some headaches:

#myelementondarkishbg {
background-color: #444; /*dark gray*/
color: white;
background-color: white / opacity: 0.2 / color: #EEF;
/*we have opacity and we can use a bluish white for font text that better
suits our style as the parent shows through*/
}

Apparently, a white background with opacity 0.2 on darkish background will
not cause problems, but when opacity is not supported, user is left with
white text on white BG, if tying would not be possible. Since we tied the
opacity with background color, we can safely use Opacity. UI's without
that opacity support will have no problems as well.

>
> But I hope the CSS WG will consider it, it would be better than creating
> something that works just for fonts (although fonts ‘shine through’
> eachother, like multiple backgrounds with transparent parts, so it’s a
> slightly different case).
>
> This is certainly something that I would like to use right now on my
> website, as certain text is currently illegible when the image behind it
> somehow fails to load.

I hear you. Especially indecent support for alpha PNG's up until this
point has been causing loss of immeasurable amounts of manhours around the
world (not being able to reuse a single image and paste it everywhere,
having to re-slice images when customers ask for a different background
color etc), increasing bandwith use, and some more problems that not needs
mentioning. At least we could, in time, provide better functionality to
next generation of webmasters.

  From your other mail suggesting an alternative:
> It would allow you to simply write:
>
> background: gray;
> background: gray url(grayishopaque.jpg) 50% 50% no-repeat;
> background: transparent url(grayishsemitransparent.png) repeat;
> It’s more compatible with existing implementations as well, they will  
> simply pick the last rule and use thecurrent suboptimal fallback  
> behaviour, while your method will not be recognised, requiring the  
> author toexplicitly write an additional rule to support older user  
> agents.

This is not a bad idea at all, but would require some changes the probable
way that CSS files are being parsed (UA's would want to cache the previous
declarations when a line is deemed invalid due to the line containing a
URI, because an invalid value would become valid each time a URI becomes
available. Again, better than having nothing in our hands regarding the
issue, and in some ways more graceful in the way the CSS is written.

>
>
> ~Grauw
>



-- 
Emrah BASKAYA
www.hesido.com

Received on Tuesday, 9 May 2006 06:27:48 UTC