The default bug view has changed. See this FAQ.

block child of inline element not rendered with parent's opacity

RESOLVED FIXED in mozilla7

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: nickers, Assigned: roc)

Tracking

({testcase})

Trunk
mozilla7
testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: spec issue)

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0.1) Gecko/20110430 Firefox/4.0.1 Iceweasel/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0a1) Gecko/20110530 Firefox/7.0a1

If an inline element with opacity set has a block element child, rendering of the block element ignores parent's opacity.

Reproducible: Always

Steps to Reproduce:
View the attached testcase.

Actual Results:  
'Gamma' displayed black.

Expected Results:  
'Gamma' displayed gray.

http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparency specifies that
descendant elements should be rendered with containing element's opacity:

    "Conceptually, after the element (including its descendants) is rendered into
    an RGBA offscreen image, the opacity setting specifies how to blend the
    offscreen rendering into the current composite rendering."
(Reporter)

Comment 1

6 years ago
Created attachment 536139 [details]
<div> inside <span> with opacity set

Updated

6 years ago
Attachment #536139 - Attachment mime type: text/plain → text/html
Keywords: testcase
Version: unspecified → Trunk
The CSS specs tend to be pretty schizophrenic about whether this sort of thing happens on elements or on boxes.  In particular they have a tendency to use "element" to mean both, but they're not exactly interchangeable.

In this case, the box for the block is NOT inside the box for the inline.  That means that rendering the inline does not actually render the block (per CSS2.1) which violates a basic assumption that the text quoted in comment 0 seems to be making about the drawing model.  In other words, that text can't possibly be correct, since it assumes things that are false about how painting happens in CSS.  The only question is what the text _should_ say instead.

roc, what do you think is the right behavior here?  Tantek, can you please fix the spec to actually make sense, no matter which behavior it's calling for?

Note that our current behavior matches WebKit and Presto.  Trident, in the form of IE9, applies the opacity setting to the block box as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: spec issue
Posted to www-style too: http://lists.w3.org/Archives/Public/www-style/2011May/0710.html
Does CSS actually define parent/child relationships between boxes yet?

We try reasonably hard to ensure that 'opacity' compositing is done on an entire element: elements with multiple boxes get those boxes fused together into a compositing group. My gut feeling is that this bug should be considered valid.
I think the only thing we need to do here is to add 'opacity:inherit' for anonymous block pseudos in ua.css.
Created attachment 536217 [details] [diff] [review]
fix

This works.
Assignee: nobody → roc
Attachment #536217 - Flags: review?(bzbarsky)
I think this behavior is definitely justified on the principle of "least surprise".
> Does CSS actually define parent/child relationships between boxes yet?

CSS 2.1 is working on it, half-heartedly.

> elements with multiple boxes get those boxes fused together into a compositing
> group.

Note that in the case of block-inside-inline you can have content interleaving between parent and its kids, as far as I can tell.  How does the attached patch (which seems like the obvious thing to me too, to get the simple cases working) deal with that.
Created attachment 536225 [details]
Testcase showing such interleaving, albeit without stacking contexts

If the argument is that the inline and its block kids should be a single stacking context, I can buy that (though the spec needs to say so, then; right now it doesn't really as far as I can tell), but the attached patch actually gives us either two or three stacking contexts in the {ib} case, right?  Is the difference not distinguishable through black-box testing?
(In reply to comment #9)
> If the argument is that the inline and its block kids should be a single
> stacking context, I can buy that (though the spec needs to say so, then;
> right now it doesn't really as far as I can tell),

That's right.

> but the attached patch
> actually gives us either two or three stacking contexts in the {ib} case,
> right?  Is the difference not distinguishable through black-box testing?

Here's what our implementation would do in your testcase if the span had opacity:
-- The two inline frames and the anonymous block each generate an nsDisplayOpacity containing their child frame content
-- The nsDisplayOpacitys are placed on the PositionedDescendants list as Appendix E requires
-- We notice that the three nsDisplayOpacitys are all for the same element, and are consecutive in z-order, so we fuse them into a single group and get the right rendering.

We might get into a situation where we fail to fuse nsDisplayOpacitys for the same element because other content is interleaved with it in z-order, even after we've moved the display items to the list corresponding to Appendix E 2.8. However, I think such a situation would mean a bug in the specs or our implementation for allowing such a thing to happen.
> We might get into a situation where we fail to fuse nsDisplayOpacitys for the
> same element because other content is interleaved with it in z-order

That's the case I'm worried about, yes.

> However, I think such a situation would mean a bug in the specs or our
> implementation for allowing such a thing to happen.

Ok, as long as you can't think of ways it can happen right now things are good.
Comment on attachment 536217 [details] [diff] [review]
fix

r=me
Attachment #536217 - Flags: review?(bzbarsky) → review+
Whiteboard: spec issue → spec issue [needs landing]
http://hg.mozilla.org/integration/mozilla-inbound/rev/b58ba54bdcbd
Flags: in-testsuite+
Whiteboard: spec issue [needs landing] → spec issue
Whiteboard: spec issue → spec issue [inbound]
http://hg.mozilla.org/mozilla-central/rev/b58ba54bdcbd
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: spec issue [inbound] → spec issue
Target Milestone: --- → mozilla7
You need to log in before you can comment on or make changes to this bug.