44401 - Inline element backgrounds and borders don't obey '-moz-opacity'

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[jmraker]

Using linux 2000063008 nightly build

Testcase:
http://www.mwaccess.net/~john/tc/tc26.html

Actual results:
The opacity of the text(inline) does not render on every box.  They are mostly
solid with linewrapped text showing opacity correctly.

Expected results:
Every box should display with opacity.

Comment 1

[Asa Dotzler [:asa]]

updating component and setting default owner.

Comment 2

[Marc Attinasi]

The problem seems to be with the testcase, not with how opacity is working. 
Allow me to explain what I see:

1) If you remvoe the display:inline from the style sheet so that the DIV's are 
not stacked on top of each other then it works as you probably expect it - 
uniform opacity across the blocks.
2) With the display:inline in the style sheet and the opacity:.3 removed, you 
see that the blocks are all overlapping. 
3) Thus, the overlapping elements with opacity set to .3 will end up with 
additive opacity values and thus a non-uniform appearance. This is actually the 
expected behavior.

So, I believe that this is not a problem with opacity. Also note that the 
opacity is not a CSS2 property, it is currently a Mozilla-proprietary 
property...

Comment 3

[jmraker]

In my testcase if I set opacity to .08 the inline text's font is affected
(barely visable) but the background color and the border are mostly solid. 
(Even the areas not touching another inline box.)

The background of text that does linewrap does show an opacity. But only on it's
new line.  Inline text can have a background both solid and with opacity if it
line wraps.  I don't think that it should do that.  It should have a solid
background with solid text, or opaque background with opaque text. (With the
opacity becoming more solid when it overlaps something darker like it should)

Making inline text opaque but it's background and border solid doesn't seem
normal.

I should have put the emphasis on the background and border.

Comment 4

[jmraker]

http://www.mwaccess.net/~john/tc/tc26b.html
Testcase that shows the difference of opacity (normal vs abnormal)

Please reconsider reopening this bug.  I think that opacity is doing something
abnormal in both testcases.  Unless you can explain why the text font is opaque
but the background is solid.

Comment 5

[Pierre Saslawsky]

Reopening for now. I'll take a look later.

Comment 6

[/\/\arcio Galli]

Note: win98, build 2000072708
Crashed when I resized the window to the right.
Help needed to verify this crash in other OS.

Comment 7

[Hixie (not reading bugmail)]

Attachment: Simple and self explanatory testcase. The two cases should look the same (except for their width).

Comment 8

[Hixie (not reading bugmail)]

I just updated the testcase to use '-moz-opacity' instead of 'opacity'.

Comment 9

[Pierre Saslawsky]

Hixie's testcase shows that problem is not limited to backgrounds.  Changing 
summary to "Inline elements don't obey '-moz-opacity'".

Comment 10

[Hixie (not reading bugmail)]

Good catch, the border is also not obeying the opacity. The colour, however, is.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think that, like z-index in CSS2, -moz-opacity should only apply to positioned
elements.

Adding "position: relative" to <div> in the example makes the opacity problems
go away. There is a layout bug remaining where the text inside <u> is put in the
wrong place ... I don't understand this one but feel free to file it against me
in a separate bug.

If you guys agree that -moz-opacity should only apply to positioned elements,
then we should also file a separate bug to have the style system drop
-moz-opacity on non-positioned elements.

Comment 12

[Hixie (not reading bugmail)]

That's just delaying the fix, since CSS3 will most likely have an 'opacity'
property that applies to everything.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you give me a pointer to something that describes how opacity will probably
work in CSS3?

Comment 14

[Hixie (not reading bugmail)]

SVG, maybe.

I would guess that the property will be not inherited, affecting itself and all
child elements (including positioned content) (just like text-decoration is 
supposed to work in fact).

It will probably affect everything about an element -- borders, background and
text. There is a possibility that at some point it will turn into a shorthand
for border-opacity, background-opacity and color-opacity or some such.

If an element has opacity: 50% and a child has opacity: 50%, then the child will
appear to first be composited (with an alpha channel) with all its children, 
then it will be merged in with its parent, which will itself have an alpha
channel. As I understand it, the child would then appear to be 25% opaque. (Is 
that right?).

Any other questions? :-)

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sounds reasonable.
What about when an element is not the containing block for its child elements?
(e.g., position: fixed)

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Also, what about a situation like this:

<div style="opacity: 100%; z-index: 0; position: absolute">
  <div id="B" style="opacity: 50%; position: absolute">
    <div id="C" style="z-index: 1; position: absolute">...</div>
    <div id="D" style="z-index: 3; position: absolute">...</div>
  </div>
  <div id="A" style="z-index: 2; position: absolute">...</div>
</div>
A slips in between C and D. It's not clear what the visual results should be in
this case. We certainly can't composite B, C and D together and then do anything
sensible with the result. Can you raise this with the standards folks?

We might need to say something like "if opacity is not 1 then z-index: auto is
treated as 0." I believe that SVG does not have "z-index: auto" so this does not
arise in SVG.

Comment 17

[Hixie (not reading bugmail)]

What is the problem and what solution do you see for the position: fixed issue?
Does it also arise with position:absolute? As in:

  <div id="a"> AAA                #a { position: relative; height: 5em; }
   <div id="b"> BBB               #b { opacity: 50%; margin-top: 2em; }    <div
id="c"> CCC              #c { position: absolute; top: 0; height: 3em; }
   </div>
  </div>
z-index: auto does indeed raise some rather interesting results. Mind if I 
forward your comments to the CSS WG list?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

PLEASE forward my comments, I'm counting on it!

You're right, position: fixed is not a special problem here ... Just as long as
we're clear that "opacity" applies to an element and all its contained elements,
NOT its box and all its contained boxes, which are not the same thing if one of
the contained elements is "position: fixed". (not sure if I'm using the right
terminology here, I hope you know what I mean)

Positioned elements that stick out of their parents are not hard to deal with
conceptually. The area of the thing that needs to be eventually composited just
ends up bigger than the area of the parent element, with the areas not covered
by the parent or any children completely transparent. We already handle this (in
most cases).

Comment 19

[Chris Casciano]

I was going to enter this as a separate bug report but noticed Iand had covered
it in <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=44401#c14">c#14</a>.

I'm trying to get a grip on how cascading of the opacity *should work*. The spec
for 'opacity' leads me to believe is a fixed range from 0>1, but unfortunately I
didn't see anything in the current CSS3 draft that covers this in any detail. I
made a test page using -moz-opacity and saw the same behavior as outlined by Ian
above:

<a
href="http://placenamehere.com/Mozilla/opacity.html">http://placenamehere.com/Mozilla/opacity.html</a>

In that test case there's a paragraph set to an opacity of 50% nested inside of
a div that is set to 50%. There is also a paragraph set to 100% inside of that
same div. This test case arose out of wanting to build a document that had
everything but links (A) with some form of opacity. As I was building the
document, armed with my knowledge of CSS2 and how the cascade generally works
with colors* I had expected any inline element set to an opacity of 100% to be
fully opaque. Instead, mozilla seems to be compounding opacities.

Besides the fact that mozilla's behavior didn't fit my (sometimes flawed) mental
picture of what should have happened I find two things wrong here:

1) It is very difficult for me as a designer of a document to conceptualize the
compounding of percentages. There's no easy translation from my other tools
(Photoshop Layer Opacity), and I'm really bad at math. "75% of 35% is too light,
but how to I change it? How to i make it 35% overall like it is in my comp?"

2) If opacitity worked more like relative font sizes then a fixed range from 0>1
then I should be able to go in the reverse direction to accomplish my initial
goal of making an element less transparent then its surroundings. As you can see
from my test case I did try using -moz-opacity:200% (200% of 50% is 100%) but
that did not achieve the desired results either (don't know if that's due to a
conceptual error or a browser bug). 



(... is this a better topic for the w3 css list? a bug of its own?)

* opacity is currently defined in the <a
href="http://www.w3.org/TR/2001/WD-css3-color-20010305#transparency">CSS3 color
module</a>

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think the CSS3 draft is quite clear, and in accord with the SVG recommendation:

> Conceptually, after the element is rendered into an RGBA offscreen image, the
> opacity setting specifies how to blend the offscreen rendering into the
> current composite rendering.
...
> If the element is a container element, then the effect is as if the contents
> of the element were blended against the current rendering composite using a
> mask where the value of each pixel of the mask is <alphavalue>.

The alpha value is applied to the entire element, including the children. There
is therefore no way to have opaque children of a translucent element. You may
not like it this way, but that's something you'll have to take up with the CSS
WG. We'll do whatever they say :-).

The fact that, in your example, the third line is at 25% opacity is not directly
an effect of the CSS rules (at least not the same way font-size is computed).
What is happening (in theory, according to the CSS draft) is that the line is
being blended at 50% opacity when it's drawn into its container. The resulting
RGBA pixmap for your DIV is blended at 50% opacity onto the canvas. The net
effect is, in this case, that the line is blended at 25% opacity onto the
canvas, but much more complicated things can happen when the DIV has many
children which overlap.

At the moment Mozilla doesn't implement the model correctly, and won't until
after Mozilla 1.0. What we currently do is multiply the opacities together and
render each element seperately. Sometimes, as in your example, this gives
results identical to what you'd get with a correct implementation. However, as
soon as you have a partially-opaque container with overlapping children, the
approximation breaks down and Mozilla will give you an incorrect rendering.

As you guessed, this is really a W3C CSS WG issue and you should take it up with
them. Be assured that we WILL change our opacity behavior to match whatever they
decide for CSS3. And don't assume that what you currently get with Mozilla
matches any past, present or future specification :-).

Comment 21

[Hixie (not reading bugmail)]

roc: The WG just discussed this and our solution is as follows:

   "If z-index has the value auto, and opacity has a value that is not 1.0,
    then z-index computes to the value 0."

This problem doesn't occur with rgba() values, since they only affect one element.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Excellent, thanks!

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Moving -moz-opacity rework to 1.2alpha.

Comment 24

[Chris Casciano]

(just cycling through some old bugs)

We're now past 1.3a and the testcase still fails.... any updates?

Comment 25

[Chris Casciano]

oops... my fault... I have an older Chimera build open at the moment... running
the testcase with 1.3b/osx the testcase appears to work properly... I still have
questions on my example... but my heads not in it at the moment

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The testcases in this bug all work now, probably due to a checkin to
nsCSSFrameConstructor I made a while ago. I'm closing this bug. More work on
-moz-opacity will continue in other bugs.

Comment 27

[Madhur Bhatia]

verified with testcase attachment 34376 [details]
checked on winXP and linux