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

Re: Solving the alpha images and background-color problem

From: Emrah BASKAYA <emrahbaskaya@hesido.com>
Date: Sat, 13 Aug 2005 14:05:59 +0300
To: "Laurens Holst" <lholst@students.cs.uu.nl>
Cc: "www-style.w3.org" <www-style@w3.org>
Message-ID: <op.svf039bk8nstxa@lomarnona>

On Sat, 13 Aug 2005 13:19:08 +0300, Laurens Holst  
<lholst@students.cs.uu.nl> wrote:

> Kelly Miller wrote:
>> I disagree with the syntax of this, but not the idea.  The problem is  
>> "onimageload" suggests that this should be the color on ALL image  
>> loading.  Remember that CSS3 also has a method of adding foreground  
>> images in CSS, through the global 'content' property.  What you're  
>> suggesting sounds like it should only work with background-image  
>> (though it may be better to have it work with both; but this might be  
>> difficult).
> Good point. Iíd say this notation generalises the problem by making it a  
> property value that can potentially be applied to different values  
> accepting colours as well. But if it only works for background images  
> anyway, I donít see the need for it, and why would we not just create a   
> background-standin-color property then?

I now have to agree defining imageload is on shaky grounds, but a seperate  
property is useless, while it was me who came
up with the stand-in color property idea (maybe I wasn't the first but  
can't confirm) e.g.:

background: transparent url(foo.png);
background-standin-color: red;

This ruins the accessibility for CSS2 browsers. However the following  
method is perfect in case of cascading (from defining a stand-in color  
perspective instead of onimageload):

background: transparent standincolor(red) url(foo.png);

As only new browser would parse that info, so an author, if he wanted,  
could choose to not send a bg-image to css2 browser with the following CSS:

background: red;
background: transparent standincolor(red) url(foo.png);

without a dedicated @support feature. (BTW, Opera parses the second line,  
which may be a severe standards violation, it turns the background color  
to transparent even if it should not parse that line. FF and IE applies  
red background like they should. Which is the correct behaviour??)

I will aggree with you that stand-in color approach seems a better option  
than onimageload, it is much more straight forward in understanding and it  
bodes well with the existing CSS authoring habits.

Received on Saturday, 13 August 2005 11:06:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:20 UTC