Re: [css3-background] possibly too late for last call, but: background-opacity?

On Oct 17, 2009, at 8:27 AM, Giovanni Campagna wrote:

> 2009/10/16 Robert O'Callahan <>
> Out of all the ideas presented so far, new image functions sound  
> best to me, e.g.
> background-image: image-opacity(url(foo.png), 0.3);
> background-image: image-offset(url(foo.png), 100, 0);
> background-image: image-rect(url(foo.png), 100, 0, 100, 200);
> These are animatable with transitions, compose well and don't  
> require changes to CSS fundamentals.
> Not that well, actually.
> 1) You need to repeat the URI every time, and you cannot cascade  
> independently the image and its opacity.
> 2) You cannot use that for "drop-shadow" (because the drop-shadowed  
> border-image would be clipped, making it no better than Photoshop)
> 3) You cannot use that for content-only effects (unless you hack  
> "content")

I wasn't sure I understood ROC's idea, but it looks to me as though he  
is saying that "image-opacity()", for instance, would be an image  
value type,[1] alongside "url()" and proposals such as "linear- 
gradient". If so, then I see a couple more problems with it:

4) You wouldn't be able to do "image-opacity()" and "image-rect()",  
for instance, on the same image.
5) It seem that you wouldn't be able to apply the effect to other  
image value types, such as the proposed "linear-gradient", "radial- 
gradient", sprites, or using 'image()' for fallbacks. Or at least not  
without making the notation extremely complex and hard to read (by a  
human, I mean), and kind of painful to animate (by a typist).

> Besides, we still need to define the processing of "filter" in the  
> CSS realm. We may go with "what mozilla currently does" or "what's  
> more SVG-like" or "what's more author-friendly".

I vote for the latter.  :)

> We may need to think of the IE side of "filter" too.

Why? They should follow the same standards as everyone else.


Received on Saturday, 17 October 2009 16:57:42 UTC