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

2009/10/18 Robert O'Callahan <robert@ocallahan.org>

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

So what do you propose to address this?

1) Magic properties are cascaded differently than normal. For example,
background-image combines instead of overriding (attaching multiple
background layers).
Pros: no new syntax, more intuitive for the css beginner
Cons: magic processing, definitely not intuitive for the css expert (the one
that is considered in this discussion), requires creative selectors in the
opposite case (if you want overriding)

2) Magic values are cascaded differently than normal. For example,
"image-opacity(number)" uses the cascaded image by default.
Pros: no new syntax, less typing
Cons: magic processing, again not intuitive, requires multiple properties
(and due to the details of cascading, may require multiple blocks, possibly
breaking an invariant)

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)

3) Magic keyword recover things from the previous cascade. For example,
"cascade" gets the value immediately before in cascade order
Pros: no new syntax, explicit and does not break css invariants (not that
much, I think)
Cons: requires full ordering (O(n logn)) instead of just finding the maximum
specificity + position in css + importance (O(n) in the naivest
implementation), requires explicit opt-in from the property because the type
is not given, it must be inferred

 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.


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

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) }"?


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

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?
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!


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

Good

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

Giovanni