- From: Pascal Germroth <pascal@germroth.name>
- Date: Mon, 30 Apr 2007 19:18:14 +0200
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: Raul Dias <raul@dias.com.br>, www-style@w3.org
Hello,
>> Just to confirm:
>> body { opacity: .5; }
>> and
>> #photo { opacity: .5; }
>>
>> will result in a opacity of 0.5 and not 0.25, right?
>> Meaning the values are absolute not relative.
>
> No, and that would be rather surprising. Under this model, if you want
> to modify the opacity of a whole sub-tree uniformly, you would have to
> modify the opacity property of each and every element in it, and you'd
> expect that you can decrease the opacity of a child element relative
> to its parent, whereas this thread is about not being able to do that.
So, would it work if opacity values were not restricted to [0;1]?
Now I properly slept about it I think, you would have to render
everything into several bitmaps first and then blend it all together in
the final step, because if the document would look like this:
<a opacity="0.5">A
<b opacity="0.5">B
<c opacity="4.0">C</c>
</b>
</a>
"A" should be displayed with an effective opacity of 0.5, "B" with 0.25
and "C" with 1.0
But if the tree is rendered recursively, C would be blended into B and
that composite then be blended into A which is finally blended into the
background. So when rendering <b> "locally" it would look like "B" had
an opacity of 1.0 and "C" one of 4.0 which causes a problem...
So some algorithm would be needed that allows opacity >1 but makes sure
that the "effective" opacity of no pixel will be out of [0;1]...
Maybe it is a bit of an overkill to implement this only for some little
effect nearly nobody uses (there are more pressing problems, really).
--
pascal
Received on Monday, 30 April 2007 17:19:18 UTC