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

VERIFIED FIXED in mozilla1.2alpha



CSS Parsing and Computation
18 years ago
15 years ago


(Reporter: jmraker, Assigned: roc)


({css-moz, testcase})

css-moz, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Hixie-P4] WG, URL)


(1 attachment)



18 years ago
Using linux 2000063008 nightly build


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

18 years ago
updating component and setting default owner.
Assignee: asa → pierre
Component: Browser-General → Style System
QA Contact: doronr → ckritzer

Comment 2

18 years ago
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 
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 3

18 years ago
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

I should have put the emphasis on the background and border.
Summary: css2, Opacity problem with inline text → Opacity problem with inline text

Comment 4

18 years ago
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

18 years ago
Reopening for now. I'll take a look later.
Resolution: INVALID → ---

Comment 6

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


18 years ago
Ever confirmed: true
Keywords: qawanted
QA Contact: ckritzer → ian
Created attachment 34376 [details]
Simple and self explanatory testcase. The two cases should look the same (except for their width).
I just updated the testcase to use '-moz-opacity' instead of 'opacity'.
Assignee: pierre → roc+moz
Keywords: qawanted → css-moz, mozilla1.0, testcase
OS: Linux → All
Hardware: PC → All
Summary: Opacity problem with inline text → Inline element backgrounds don't obey '-moz-opacity'
Whiteboard: [Hixie-P4]

Comment 9

17 years ago
Hixie's testcase shows that problem is not limited to backgrounds.  Changing 
summary to "Inline elements don't obey '-moz-opacity'".
Summary: Inline element backgrounds don't obey '-moz-opacity' → Inline elements don't obey '-moz-opacity'
Good catch, the border is also not obeying the opacity. The colour, however, is.
Summary: Inline elements don't obey '-moz-opacity' → Inline element backgrounds and borders don't obey '-moz-opacity'
I think that, like z-index in CSS2, -moz-opacity should only apply to positioned

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.
That's just delaying the fix, since CSS3 will most likely have an 'opacity'
property that applies to everything.
Can you give me a pointer to something that describes how opacity will probably
work in CSS3?
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? :-)
Sounds reasonable.
What about when an element is not the containing block for its child elements?
(e.g., position: fixed)
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 id="A" style="z-index: 2; position: absolute">...</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.
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; }
z-index: auto does indeed raise some rather interesting results. Mind if I 
forward your comments to the CSS WG list?
Whiteboard: [Hixie-P4] → [Hixie-P4] WG
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

16 years ago
I was going to enter this as a separate bug report but noticed Iand had covered
it in <a href="">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


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="">CSS3 color
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 :-).
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.
Excellent, thanks!
Target Milestone: --- → mozilla1.1
Moving -moz-opacity rework to 1.2alpha.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha

Comment 24

15 years ago
(just cycling through some old bugs)

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

Comment 25

15 years ago
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
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.
Last Resolved: 18 years ago15 years ago
Resolution: --- → FIXED

Comment 27

15 years ago
verified with testcase attachment 34376 [details]
checked on winXP and linux 
You need to log in before you can comment on or make changes to this bug.