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: Sun, 14 Aug 2005 04:11:57 +0300
To: "www-style.w3.org" <www-style@w3.org>
Message-ID: <op.svg397z68nstxa@lomarnona>

On Sun, 14 Aug 2005 00:46:44 +0300, David Woolley
<david@djwhome.demon.co.uk> wrote:

>
>> background: red;
>> background: transparent standincolor(red) url(foo.png);
>
> background is a shorthand property, so this is equivalent to:
>
> background-color: red;
> background-color: transparent;
> /* whatever the standalone equivalent of standincolor(red) is */
> background-image: url(foo.png);
>
> which is equivalent to:
>
> background-color: transparent;
> /* whatever the standalone equivalent of standincolor(red) is */
> background-image: url(foo.png);
>
> which for a browser with no image support but colour support, or
> with images off and colour support, but without the new property is:
>
> background-color: transparent;
>

Does this mean, you would somehow support the other way around
( onimageload() ) ? It is really hard to tell.

Even so, stand-in color, for a CSS3 browser, will be the color used until
an image can be loaded, and css2 browser should, by CSS rules, correct me
if I'm wrong, should ignore unknown syntax??

So a CSS3 browser who understands this but does not support images, would
always use the stand-in colour. A CSS2 browser should *ignore* that line.
Am I wrong??

On firefox and ie, this produces an element with a red background and not
transparent, I have, indeed, tried, which actually *is* the correct
behaviour, isn't it??
background: red;
background: transparent standincolor(red) url(foo.png);

And this too should be allowed:
background-color: transparent standincolor(red);

If this still doesn't make sense, would you support the onimageload
stance? I'm just curious.



On Sun, 14 Aug 2005 01:51:51 +0300, Ron van den Boogaard <ron@ronvdb.com>
wrote:

> I read the older posts , Rest assured. I don't think standards should be
> bothered with latency or not.

*User* *turns off* *images*
*User agent* *does not* *support* *images*

Those are supposed to be the main selling points. Others are there to
support the idea.

CSS is about presentation. Images are part of it. They can be turned on or
off. It affects the presentation. But somehow, there is an unspoken rule
about standards not caring whether it can show images or not? (I even did
try a @images-off kind of media query after the first stand-in proposal,
but people than asked what would happen when there is a network failure,
and rightfully so.) I said I would not discuss why we don't need it, but
somehow, I keep myself repeating because a) either my messages are not
clear  b) you are reading the wrong old posts.

> What we do need is as clean and as simple a mark-up as possible. Latency
> on images have more to do with band-width, server anomalies and UA
> imperfections. The code should not provide work-arounds for these things.
I am somehow really sorry I brought up the latency issue, but that was not
the point, it was just a side issue. Please disregard anything I said
about latency.

Also, it is as if people would suddenly have to forget anything they
learnt about CSS with the introduction of onimageload() . There are many
features of CSS I do not use. I don't have to know all parts of it.

-- 
Emrah BASKAYA
www.hesido.com
Received on Sunday, 14 August 2005 01:12:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:40 GMT