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

2009/10/16 Brad Kemper <brad.kemper@gmail.com>

>
> On Oct 16, 2009, at 4:59 AM, Giovanni Campagna wrote:
>
> opacity:0.5;
>
> apply-effect:opacity, background-image + background-color;
>
>
> And you're right; I didn't originally account for multiple backgrounds. I
>
> like the way you have it, and would say
>
> that background-image and background-image(0) would be equivelent. So,
>
> without my messed up notation on using this as a property, it would
> actually
>
> look like this:
>
>
> opacity:0.5;
>
> apply-effect:opacity, background-image(1,2,4) + background-color;
>
>
>
>
> and would these properties be able to be animated?
>
>
>
> 'opacity' would be, but 'apply-effect' or 'visibility' would not be. It
>
> would just continue to be the same throughout. So, if the effect
>
> (opacity) only applied to the background, then you would be animating the
>
> opacity of the background, and leaving the borders opacity, etc. alone.
>
>
> 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.

> 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.

> (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.


> 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


> Or what if we go the IE / Mozilla way, by extending filter, adding
> commas, functional notations for common filters and apply-to()
> filter: opacity(0.5) apply-to(background), drop-shadow(10px,10px)
> apply-to(border-image), "../filters/multicolorblur.xml"
> apply-to(box-shadow),
>
> url("progid:DXImageTransform.Microsoft.AlphaImageLoader(src=../images/shared/lvlogo.png,
> sizingMethod='scale')") apply-to(all);
>
> (this would make opacity obsolete, deprecated or syntactic sugar for
> filter: opacity() apply-to(all));
>
>
> Hmmm. So you basically would then be putting the current possible values of
> 'opacity', etc. into functions within the filter value? I'm not sure it is
> worth it just to be able to have more than 2 used values per element. I
> think it would be enough to just have just the initial value and one
> specified value apply. You could still have something like this:
>
> filter("../filters/multicolorblur.xml"); /* or whatever the 'filter' syntax
> normally is */
> apply-effect: filter, border + background-color;
>
>
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)
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);
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);

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

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*.
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)
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)

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).

Giovanni

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