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 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.
>
>
But it only addresses half use case, leaving the other half for the next
version (therefore requiring some sort of extensibility /
forward-compatibility)


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

Even if implementable, it would create a mess on the author side (nothing
else in CSS works like that, shorthand properties reset everything to
initial). Definitely better to add an apply-to() functional notation at the
end of those properties (commas aside), or at least use an at-rule inside
the declaration block (strange, but at least recognizable as different from
normal CSS).

In addition, consider that most of the properties you listed take part on
the layout, while graphic effects are applied later when the element is
drawn. So you could restrict it to "opacity", "drop-shadow" and maybe
"visibility".
Not sure about "clip", which would make sense, but we already have a
"background-clip" property, plus clipping will be probably discussed more
when defining "clip-mask" for CSS.


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

Comma inside apply-to: shadow applying to multiple elements. Comma in the
property: multiple shadows (each with its own apply-to, and offset, blur,
spread, color...)


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

No, I meant extending to multiple values, instead of specified vs initial.


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

apply-filter:background; or @apply-effect: filter, background; are not worse
than filter:url() apply-to(background);

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

Not only different layers, but also just different filters in sequence on
the same image (or rendered 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);
>
>
> 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;
>

filter: drop-shadow(); or drop-shadow: ; are conceptually the same, except
that "filter" already exists as an (horribly implemented) property. Plus it
would combine with features 1 / 2 (in particular defining an explicit
sequence of effects processing, like not making the shadow sepia even if I
said black)


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

Point taken.


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

Not only UAs parse stylesheets and authors like better consistent
processing.

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

What colon? You mean in apply-to()? It is conceptually different, because
apply-to() is part of the property value, it is not detached.

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

We could go with the "drop-shadow"-like properties, but that would mess with
already existing filters (in particular about order of processing), plus it
would have more syntax problems when it comes to commas and apply-to().

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

Except that box-shadow lives in Background&Borders 4 (was 3 until little
ago), opacity / clip in Absolute Positioning 3 (IIRC), filter in SVG 11.
A Graphic Effects 4 module redefining such properties (not even their
syntax, just their processing when apply-effect is not all) would break the
modularization.

(but anyway, this is just editorial)


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

Great!


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