Re: Solving the alpha images and background-color problem

On Sat, 13 Aug 2005 10:38:54 +0300, David Woolley  
<david@djwhome.demon.co.uk> wrote:

>> *Images always load with some latency, as they require seperate http
>> calls. So we have problem even if the user has turned on images due to  
>> ->
>
> Off lists as it doesn't substantially affect the argument, but, as
> you are talking futures, the data: URL scheme allows inline images.

You are right, I already use the data: URL's in some of my works. The  
better way to put it:
"Images almost always load with some latency, as they require seperate  
http calls unless they are loaded inline with the data: url scheme, where  
you still would be encouraged to use a BG-color for cases where the user  
turns off images."

On Sat, 13 Aug 2005 06:19:26 +0300, Kelly Miller  
<lightsolphoenix@gmail.com> 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).

I chose the word "onimageload" because that was the shortest that made  
sense to me. I have to agree image loading with 'content' might cause  
misunderstandings; tho not quite as many other things in CSS once you know  
what it does. If we correctly define it, I don't think there'd be a place  
for misinterpretation by the UA's either. I guess you are against the  
keyword, not the syntax?

Esp. in the shorthand version it does not cause any misunderstanding such  
as:
background: red url(foo.png) onimageload(transparent);

I am sure we can find a better keyword. Some options to replace  
"onimageload()":
bgimageloaded()
onbgimageload()
obgil()
obl() (but this might not be politically correct)
oil()


> Also, while we're discussing accessibility, wouldn't it be useful for  
> CSS to
> have some kind of syntax that tells the browser if either the  
> background-color
> or text-color is user-overridden, the opposing colors should be shifted  
> to a 'negative'
> color? As it is, changing text color or background color on any site is
> dangerous because the user may override one but not the other, leading to
> problems with accessibility and readability.
>

This was brought up some time ago. In a world where user can modify the  
style sheets, it would be illogical *not to* have such an option. Tho, for  
ease-of-use and easier understanding, I think we should *not have* both a  
BG-color and color modifying property, but a single color modifying  
property along the lines of this:
minimum-color-bg-contrast : <percentage>

or

minumum-contrast: <percentage>

(only modifying the color based on bg color)

If the element's background-color is 'transparent', the UA goes up the  
chain until it finds a color information. It will not take color instated  
with onimageload(color) into account but only the original bg-color,  we'd  
most definitely have to clarify this if it is somehow accepted.

For solutions that allow taking bg-images into account is not usable:  
Anything other than an exact negative (which also would cause  
gray-on-gray) are per-pixel decisions that would put too-much strain on  
UA's. So BG-images will not be put into account at all. User can always  
turn off images if he has set a minimum-contrast. I don't see  
mimimum-contrast being frequently used on author CSS, even if so, it would  
be logical he would not use problem causing bg-values with bg-images, he  
can test his site with his own CSS only but not with client CSS. If user  
has a CSS which uses minimum-contrast, s/he should be prepared to having  
to turn off images.

I do not want to go so much off the "onimageload()" topic tho, because it  
is more of a bigger problem.


-- 
Emrah BASKAYA
www.hesido.com

Received on Saturday, 13 August 2005 10:01:44 UTC