User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Avant Browser; Avant Browser; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.1) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060703 Minefield/3.0a1 - Build ID: 0000000000 (Custom build based on REFLOW_20060603_BRANCH code.) Also happens in Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:220.127.116.11) Gecko/20060508 Firefox/18.104.22.168 - Build ID: 2006050817 (official 22.214.171.124 release), and the latest trunk. The layout engine paints borders in the wrong order (left-top-bottom-right instead of bottom-left-right-top). This results in an issue with the Acid2 test where the nose gets pushed up and left by 1 pixel. This is hard to notice without zooming in on the Acid2 render, but the test requires to-the-pixel indistinguishability to pass. I'm sure that it is easy to fix this without any regressions. (Opera also had a similar issue before version 9, but that was fixed. Read more at http://weblog.timaltman.com/node/802 .) Reproducible: Always Steps to Reproduce: 1. Access the attached URL. 2. Zoom in on the render to sww the bug more easily. Actual Results: The top-right and bottom-right corners are orange, the top-left and bottom-left ones are blue. Expected Results: The top-left and top-right corners are blue, the bottom-left and bottom-right ones are orange. (Opera 9 and IE 6 draws it correctly.)
What is the "CSS Border Slants" specification? I don't know of any specification that requires particular behavior here, and I'm not sure why Opera changed their behavior, unless it was for compatibility with other browsers (if so, which browsers?).
This one isn't clearly defined in any specification, but Hixie (one of the creators of Acid2) interpreted it this way (so that the borders must be drawn in the order bottom-left-top-right). As a result, to really pass Acid2 (remember, the render should be indistinguishable to-the-pixel from reference.png!), we'll need to reorder te border painting.
This WFM in builds without cairo. After Bug 328241 is fixed, this bug will be irrelevant, because the border-eges will be antialiased and a mix of both joining colors. Then it will not look exactly like the reference rendering, but I think, antialiased borders are much better than a few half pixels in the acid2 testcase. (sorry for my bad english)
It looks like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060705 BonEcho/2.0a3 ID:2006070514 renders this exactly as you desire. It appears pretty much as you desire although it doesn't look as clean as IE6. ~B
Confirmed that this one only occurs in Cairo builds. The border drawing order is not clearly defined in the CSS2 specification, so the WaSP chose the most-used drawing order as the "standard". However, this is really really meaningless (as pointed out by Jonathan Haas), when we want such borders to be antialiased. I'm just wondering whether this is an INVALID (because it's pointless to talk about drawing order on Cairo builds) or WORKSFORME (because it works in non-Cairo builds.)
> but the test requires to-the-pixel indistinguishability to pass It doesn't require to-the-pixel indistinguishability on the nose pixels. CSS doesn't specify things that closely. Safari doesn't do the nose to-the-pixel the same, and they're perfectly compliant here. > Opera I told them repeatedly that they were being silly. Their old rendering of the nose was fine; their change was a waste of their time. > Hixie (one of the creators of Acid2) interpreted it this way (so that the borders must be drawn > in the order bottom-left-top-right) Actually I just took a screenshot of Mozilla when creating the reference rendering, which is why it was like Mozilla before. I could just as easily have taken a screenshot of Opera and then we'd be having the opposite discussion. The best rendering is to anti-alias this so you can't tell the difference. This bug is INVALID. We may want to maintain the earlier rendering specifics in non-antialiased mode to handle inset/outset borders better, but that is unrelated to Acid2.
Summary and others changed to move away from Acid2. This is a cairo problem.
-> INVALID as per hixie; seams fixed by patch for bug 368247.