Open Bug 1301450 Opened 8 years ago Updated 2 years ago

CSS opacity and filter not applied as expected to element area

Categories

(Core :: Layout: Tables, defect)

48 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: oscar, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: testcase)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

Simple HTML test with small TABLE attached as "test1.html" and reproduced here:

<style type="text/css">
  table { border-collapse: collapse; }

  .class1 {
    background: green;
    border-bottom: 1px solid white;
  }

  .class2 { opacity: 0.5; }
</style>

<table>
  <tr>
    <td class="class1">R1C1</td>
	<td class="class1 class2">R1C2</td>
  </tr>
  <tr>
    <td class="class1">R2C1</td>
	<td class="class1 class2">R2C2</td>
  </tr>
</table>



Actual results:

In elements with OPACITY set, the BOTTOM-BORDER seems to be ignored and filled with the element's BACKGROUND color.

Attached results from different browsers:
Chrome (Windows) - correct results
Safari (Mac) - correct results
Safari (iOS) - correct results
Firefox (Windows) - incorrect
Edge (Windows) - incorrect
Internet Explorer (Windows) - incorrect



Expected results:

BOTTOM-BORDER should have maintained set background color/size set by CLASS1 class as seen in Chrome and Safari examples.
OS: Unspecified → Windows 10
Hardware: Unspecified → x86
After a bit of additional testing, found that this is only true when the BORDER color being applied to the element matches the document background color (possibly just the parent element's background color).  

i.e. The issue goes away if you change to BORDER color to not match the background or vice-versa.
Component: CSS Parsing and Computation → Layout: Tables
Keywords: testcase
OS: Windows 10 → All
Hardware: x86 → All
Isn't this a duplicate of bug 940287?  (i.e. the bug is in Chrome)
Flags: needinfo?(oscar)
(In reply to Mats Palmgren (:mats) from comment #3)
> Isn't this a duplicate of bug 940287?  (i.e. the bug is in Chrome)

Yes, it looks like it's the same issue.  Interesting that Chrome (browser) and Safari handle the case correctly, though.  The status of #940287 is "RESOLVED INVALID" - what does that mean?  Sounds like nobody is considering it a bug to be worked on.
I found the page describing the bug statuses. "RESOLVED INVALID" means it's not considered a bug. I'd love to better understand why the devs think Firefox's presentation is correct and Chrome/Safari are wrong.
CC'ing bz, he will probably answer you. :)
Flags: needinfo?(oscar) → needinfo?(bzbarsky)
I suggest using a 20px border width instead of 1px to more clearly see the difference between what different browsers are doing.

It used to be the case that the spec said that the background of a cell went to the middle of the border in the collapsed border model, which is what we implement.  Now CSS 2.1 says:

   CSS 2.1 does not define where the edge of a background on a table element lies. 

and https://drafts.csswg.org/css-tables-3/ is not very clear, at first glance, in terms of how this stuff should work.

So you should probably go talk to the CSS working group about the state of this stuff.

I should note that the combination of "well, the cells don't really paint their borders" in border-collapse mode and how group opacity works makes it hard to tell exactly what should happen, and in particular whether the border should be translucent.  It looks like in Chrome it is _not_ translucent.  It's not translucent in Gecko either.  But in Gecko the cell background seems to be painting on top of the border or something; per spec the borders should be painted after the backgrounds for a table...

Given that last bit, I have a hard time calling our rendering correct given any reasonable interpretation of what the spec says today (which is not the same as what it said when bug 940287 was resolved, note!).
Flags: needinfo?(bzbarsky)
Fwiw, I think it's pretty clear there is a bug in Chrome regardless of what
the extent of the table cell background is since they render it differently
based on opacity.  It seems bug 940287 was never reported to them so I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=645613 now.
Ah.  Your images in that bug report make it pretty clear that Gecko draws the border on top without opacity, but the background on top with opacity, which is the basic problem being reported in this bug.

This is somewhat related to bug 688556; in particular see bug 688556 comment 7.

In terms of the implementation (and spec), opacity (and filter) make the cell a single stacking context.  If the background is part of that stacking context, it ends up over the border.  If it's not, it doesn't get the opacity/filter applied to it, which is the fundamental spec problem dbaron is talking about in bug 688556 comment 7...
Depends on: 688556
It's worth noting that in https://drafts.csswg.org/css2/zindex.html#painting-order , the borders of tables are painted in item (2) or (4) when processing the *table*.  (I'm not sure if this is really what's desired for separated borders, though.)

I wouldn't assume css-tables-3 is particularly stable yet.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: