Re: Stand-in color before images load

Barry wrote:

>
> I was invited to send the following to this list by the author, Emrah 
> BASKAYA, who is having trouble posting to www-style (the administrator 
> has been contacted). I think it's a good idea. I've used background 
> colors to stand in for images while they're loading, but that could be 
> a problem with transparent images. For example, if the image is mostly 
> red, a red background would be a good stand-in, but only if  the image 
> isn't transparent. If the background color disappears once the image 
> is loaded, a transparent image could be used. Here's the idea in 
> Emrah's own words:
>
> Hi to all.
>
> I am new in this arena, and a staunch supporter of standards. After the
> short intro, let me go ahead:
>
> Summary for the people in a hurry:
> A styling property called "background-standin-color" that will be used to
> define the background color until a 'potentially' multi- bit alpha image
> is loaded using background-image property. Then the background-color is
> switched back to "transparent".
>
>
>
> Details:
> Png is a W3 recommendation, and with Png alpha, one can do many 
> compelling
> designs. I now use it for great many things without
> caring for IE5.0 . And with the introduction of custom borders in CSS3,
> PNG will be webmasters best friend.
>
> Using transparent PNG's as background e.g. for a heading is really good
> IMHO, but then you cannot use the background-color
> because once the PNG loads, the background-colour shows thru. Yet, if the
> user-agent chooses to not load images or can't load
> images due to device limitations etc, (a heading in this example)
> text-color might be too hard to read. What I'd propose is a
> styling command called:
> background-standin-color (background-fallback-color?)
>
> Any colour given using this command will be used by the user-agent 
> *until*
> the background image is loaded. This way we can define a good color that
> will be used until the image is loaded, and when our beautiful 
> transparent
> image is loaded, the backgroud-color is switched back to transparent 
> so it
> doesn't interfere with the alpha image.
>
> example:
>
> div {
> background-color: #fff;          /* white bg in div */
> }
>
> h2 {
> color: $fff;                     /* white text in header */
> background-image: url(cool.png); /* a dark yet transparent image */
> background-standin-colour: #000 ; /*the bg will be black till image
>                                 is loaded, so text is readible,
>                                 also in no image browsers*/
> }
>
> An alternative would be a styling command like:
>
> background-switchback: true|false; which would be used like:
>
> background-color: #000;
> background-image: url(cool.png);
> background-switchback: true; /* tells the user agent to switch bg
>                             color to transparent once bg image
>                             is loaded. */
>
>
> I wouldn't know which one is more useful. But for the sake of backwards
> compatibility, the first example is better.
>
> Also, the "standin" approach could be applied to anywhere we might have
> multi level transperancy, e.g.:
> border-standin-style: dotted; /* used until border image is loaded
>                                  or on non-image browsers */
> border-image: url("border.png") 27 27 27 27 round stretch;
>
>
> -------------
>
> Hope this was the right place to post this.
>
> Take care all, awaiting your feedback.
> Emrah BASKAYA
> www.hesido.com
>
imho an onload handler to the url() would be more appropriate, or if you 
are using <IMG> tags |onload| itself would be appropriate.

if implemented it should be a seperate module of CSS3, with little to 
nothing depending on it...and be a may in relevant specs where it 
could/would apply "user agents may respect an onload handler in url()'s 
and must if they support the @script declaration" or some such...

This may be difficult to do, and these scripts should not have access to 
the pages DOM imho, as they should only have access to their scoped 
stylesheet(s) [as in not what included them, but what it includes via 
@import and itself].

Behavioral (such as this) features, again in my very humble opinion 
belong to scripting languages, why add yet another property to CSS 
(which is calculated for every element) when we could add a new feature 
which does some of the work for you.

Just some random thoughts, (I hope these made sense, if not I can rephrase)
~Justin Wood (Callek)

P.S. I would not be surprised if some form of this was already proposed 
and turned down.
P.P.S. :alt and its related suggestions seems a bit odd and un-intuitive 
to me.

Received on Wednesday, 30 March 2005 00:46:46 UTC