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

On Mon, Oct 19, 2009 at 1:50 AM, Giovanni Campagna <> wrote:

> 2009/10/18 Robert O'Callahan <>
>> 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.
> So what do you propose to address this?

I don't have a specific proposal.

3) Magic syntax allow to specify only part of a value. For example,
> "background-image: $(image,4)=url(foo.png)" to set only the forth layer of
> background.
> Pros: very explicit, little typing, can be used in a variety of contexts
> Cons: new programming-language-like syntax (especially the type part)

Something like "background-image: image-opacity(_, 0.5);" had popped into my
head. To say that I have not thought it through would be an understatement.

This is a really tough problem that touches the fundamentals of CSS. However
I think it'd be better to tackle this problem than to coin lots of new
properties (and be forced to keep on doing so forever into the future).

>  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.
>> One of the problems of using Photoshop for drop-shadowing a border-image
> is that splicing breaks the shadow. Using CSS to generate an image to splice
> is no better.

Ah right. Yes, I wasn't proposing to create an image function that adds drop
shadows. I think 'filter' is much more appropriate for that.

What if I want to set the opacity for all the content (images and text)? Do
> I need to go through "color:rgba(0,0,0,0.5)", "element > img { opacity: 0.5;
> }", "element > .mark { color:rgba(255,0,0,0.5) }"?

OK, I think I see what you mean. I'd use 'filter' for that and add a named
"CSSContent" filter image.

>>> 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.
> 1) Filters cannot be applied simultaneously, they operate on rendered
> content (treating it like a static image) so you need to define an order,
> right?

Right, yes, I meant the CSS rules apply simultaneously, clearly the filters
have to be applied in some order.

> 2) Do you mean having "filter-blend", "filter-color-matrix",
> "filter-component-transfer", "filter-composite", "filter-convolve-matrix",
> "filter-diffuse-lighting", "filter-displacement-map", "filter-flood",
> "filter-gaussian-blur", "filter-morphology", "filter-offset",
> "filter-specular-lighting", "filter-tile", "filter-turbulence" as distinct
> properties, plus additional properties for common effects (like
> "drop-shadow")? They're a lot!

No. What I mean is that you'd like to be able to do something like
.a { filter:add url(effects.svg#blur); }
.b { filter:add url(effects.svg#grayscale); }
and have <div class="a b"> get both filters applied. (Again, I just made up
that syntax five seconds ago and I don't claim it makes any sense.)

"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

Received on Sunday, 18 October 2009 21:03:57 UTC