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

On Sun, Oct 18, 2009 at 4:27 AM, Giovanni Campagna <
scampa.giovanni@gmail.com> wrote:

> 2009/10/16 Robert O'Callahan <robert@ocallahan.org>
>
>> 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.
>

Yes. There is a fundamental restriction in CSS that the cascade operates on
complete property values only, so a complex value cannot have different
parts set by different rules. The problem is that there are all kinds of
places you might want to be able to cascade parts of a complex value
independently, and making them all into separate property values leads to an
explosion of properties, and ultimately madness. I really don't want to go
down the path of
background-image-opacity:0.3;
list-style-image-opacity:0.5;
content-image-opacity:0.5;
background-image-2-opacity:0.3; /* affects the second image of multiple
backgrounds */
background-image-2-linear-gradient-stop-3-color: red;

Perhaps it's worth taking a step back and asking whether we can deal with
this problem at its root by making it possible for multiple rules to combine
to create a complex value.

2) You cannot use that for "drop-shadow" (because the drop-shadowed
> border-image would be clipped, making it no better than Photoshop)
>

Not sure what you mean here.


> 3) You cannot use that for content-only effects (unless you hack "content")
>

I'm not sure what you mean here either. One advantage of introducing new
image constructor functions is that you can use them anywhere you can use an
image. For example,
background-image: image-opacity(url(foo.png), 0.3);
content: image-opacity(url(foo.png), 0.3);
list-style-image: image-opacity(url(foo.png), 0.3);
border-image: image-opacity(url(foo.png), 0.3);
cursor: image-opacity(url(foo.png), 0.3);


>
>> For arbitrarily complicated stuff, I recommend SVG filters with additional
>> named source images representing the CSS components of the source element.
>> We probably need to figure out a mechanism so that filters can be
>> parameterized with CSS values though --- both for ease of reuse and easy
>> animation. Something like
>> filter: url(effects.svg#LSD), 10, 10, 2;
>>
>> effects.svg contains
>>   <feOffset in="CSSBackground" x="$1" y="$2"/>
>>   <feColorMatrix type="hueRotate" values="$3"/>
>>
>>
> There's an SVG Param spec on the filter side, we only need syntax on the
> CSS side. But I would object to that use of comma, I believe there are
> use-case for multiple filters.
>

Yes, there are. It would be even better if CSS could support multiple rules
that each supply a filter to be applied to an element simultaneously.


> 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've asked the SVG WG to define this. Last I heard they were happy with the
way we're doing it; IMHO what we're doing is about as SVG-like as you can
get.

Thanks for the pointer to the parameters spec. That indeed addresses the SVG
side of the problem.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]