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

On Oct 16, 2009, at 8:21 AM, Giovanni Campagna wrote:

>> Does that mean that an element gets multiple "opacity" properties? Or
>> that you cannot set opacity different than auto for everything  
>> outside
>> the apply-effect selected portions?
>
> The element would have only one computed 'opacity' property value,  
> as before, but if the value of 'apply-effect' was 'opacity,  
> [something other than 'all']'', then visually you would see part of  
> the element (such as background images) with the opacity value you  
> set, and the rest (borders, content, etc.) looking like it had the  
> initial value (opacity:1).
>
> If I remembered correctly, part of this suggestion was having  
> different opacity for different parts of the element (or different  
> background-layers, originally), not just != 1.0 for something and  
> 1.0 for the rest.

Well, in the original request,[1] it was just " the ability to specify  
opacity for background images." He did go on to say "particularly when  
layering multiple backgrounds, or when wanting to change background  
opacity depending on user interaction or similar", so I suppose that  
could mean different opacity for different background layers.

My proposal regarding 'apply-effect' does not go quite that far, in  
the interest of simplicity.


>> And what about multiple effects? Do you use a syntax separator?
>> And how that composes with cascade, like if I want to set an opacity
>> effect for background somewhere and a drop shadow for the border  
>> image
>> in another selector?
>> Are "creative selectors" always needed?
>
> Well, yes, that is more or less how I was imagining it. So 'apply- 
> effect: opacity, background-image' would override 'apply-effect:  
> opacity, [anything else, such as 'border' or 'all']', but would not  
> override 'apply-effect: drop-shadow, [anything]'
>
> Cascading doesn't work like that. You always cascade full properties  
> in CSS, completely overriding previously set properties.

I was envisioning it as a more of a kind of shorthand. So, cascading  
would work that way if they were all separate properties, like these:

apply-opacity
apply-drop-shadow
apply-clip
apply-visibility
apply-display
apply-left
apply-right
apply-top
apply-bottom
apply-z-index
apply-overflow

But instead of having individual properties, there could be just one  
'apply-effect' property:

apply-effect: opacity, [...];
apply-effect: drop-shadow, [...];
apply-effect: clip, [...];
apply-effect: visibility, [...];
apply-effect: display, [...];
apply-effect: left, [...];
apply-effect: right, [...];
apply-effect: top, [...];
apply-effect: bottom, [...];
apply-effect: z-index, [...];
apply-effect: overflow, [...];

This would allow the 'apply-effect' property to be easily extended by  
adding new properties to the list of what effects it would work with.  
Just substitute the property name as the first argument of the 'apply- 
effect' value.

>> (It seems an use case for the "cascade" keyword, but I know that this
>> is not much enjoyed by implementers)
>>
>> Moreover, what about making it a part of affected properties, like:
>> opacity: 1.0 apply-to(background), 0.7 apply-to(content);
>
> If it was within the property itself (as I had in my first 'drop- 
> shadow' proposal), then I think that would be a lot harder, because  
> some properties already have complex syntax that wouldn't really  
> allow for a comma-separated list like that. How would you add  
> multiple drop-shadow values, for instance?
>
> As seen in your previously indicated page, drop-shadow hasn't got  
> any commas yet.

Hmm. It would have multiple shadows separated by commas (like box- 
shadow), but I suppose that would be handled by an array notation in  
'apply-to'. Still, I'd hate to limit this idea to just properties  
without commas.

> I think that having the specified value (of opacity, drop-shadow, or  
> whatever) applied to particular layers of an element (border,  
> background-image, etc.) and the initial values applied to the rest  
> of the layers would be plenty without over-complicating things too  
> drastically.
>
> Mmmm.... I'm not sure about this. Besides, using apply-effect your  
> way would make it more difficult to extend the feature in CSS5

How do you mean? You'd be able to extend it to new properties by  
adding them as the first keyword. Whereas if we only used it as a  
function within existing or new properties, then we'd have to create a  
new version of every property we wan't to be able to apply selectively  
like this.

> Well, the proposal was actually three parts:
> 1) extend filter to have an apply-to() function
> filter: url("http://myfilterlibrary.example.com/dropshadow.xml")  
> apply-to(border-image);
> (there was something about this in a different thread, but proposal  
> was to tweak the SVG filter syntax, not the property)

OK. Not strictly necessary if you have an 'apply-effect' property...

> 2) extend filter for multiple filters
> filter: url("http://myfilterlibrary.example.com/dropshadow.xml?coords=10px,10px&blur=10px&color=red 
> ") apply-to(border-image), url("../filters/alpha.xml?opacity=0.7")  
> apply-to(content);

Understood. Assuming it is important to be able to apply more than one  
filter to different layers of an element, instead of just filter or no  
filter on those layers. This seems questionable to me, and not worth  
the extra complexity. But I understand your disagreement on that point.

> 3) add syntactic sugar for creating filters without resorting to  
> reference external SVG files or ActiveX components
> filter: drop-shadow(10px,10px,10px,red) apply-to(border-image),  
> opacity(0.7) apply-to(content);

I don't understand this point. How are SVG files or ActiveX companants  
needed for those examples, if you could just write them like this:

drop-shadow: 10px,10px,10px,red;
apply-effect: drop-shadow, border-image;
opacity: 0.7;
apply-effect: opacity, content;

> (The fact that the opacity filter is currently covered by its own  
> property is tangential)

Except to show that it doesn't really need syntactic sugar.

> Advantages
> For 1): all advantages of "apply-effect" in general, without  
> splitting a concept around multiple property values, and most  
> important without messing with the cascade.

I don't think my proposal messes with the cascade that much. We  
already have shorthand properties. If the UA internalized 'apply- 
effect: opacity, [...]' as actually being 'apply-opacity: [...]' soon  
after tokenization, but without requiring (or allowing) anyone to  
write it as one of many individual properties, then the internal logic  
is still maintained.

> For 2): the possiblity to reuse library filters instead of  
> cumulating them in a dedicated file (with the addition that not all  
> filters are SVG actually)

But from your examples, this is only an advantage when you are using a  
syntax that resembles the syntax already in use, but now with  
parentheses instead of a colon. I don't see that as an advantage, when  
the same thing can just be written as a normal "property:value".

> For 3): all advantages of having a "drop-shadow" property instead of  
> "filter: url(dropshadow.xml)": animatable, easier to learn and type,  
> doesn't require a network request (or filling the stylesheet with  
> data: URIs)

This does not seem to be an advantage to the way I proposed 'apply- 
effect'. It sounds more like you want to create new simple properties  
instead of loading external files (which I am in general agreement  
with), but using functional notation instead of property:value  
notation and then putting it inside the filter property (which I don't  
see as an advantage).

> Advantages of this vs a dedicated property approach, plus the  
> general filter (that you still need for complex things like moire,  
> color changing, gaussian blur etc.):
> You don't need to spread the apply-to syntax and effects processing  
> around a lot of different properties (and CSS modules as well).

I'd prefer not to bring the apply-to to the CSS modules. I want to  
bring some of the CSS properties into a single 'apply-effect' module.

> Giovanni
>
> PS: didn't the WG have a public-fx list exactly for this stuff?

I don't know.

[1] http://lists.w3.org/Archives/Public/www-style/2009Oct/0068.html