Another Acid2 fix came in build 7966. This issue wasn't even a bug, per se, as no specification defines how to handle it. The fix was made more to be compatible with Acid2 and other browsers than because it caused problems on actual sites. It's also the most trivial issue in Opera's rendering of the Acid2 test. Despite all that, it's my pet Acid2 issue. Without further ado, I give you, the Four Corners "bug".
The diamond nose in the Acid2 test is created using concepts from CSS Border Slants. The nose is actually made from the borders of two elements placed next to each other. This may be easier to understand using some screenshots. The following image (based on this test) shows a 2em by 2em DIV with 1em borders, blue on top and bottom, orange on left and right:
If two such squares are put next to each other and the outer borders are changed to blue, the nose starts to form from the remaining orange borders (based on this test):
When the white squares are removed, the nose takes shape (based on this test):
Drop the blue borders and only a perfect diamond nose remains (based on this test):
Without anti-aliasing, only one color can be used for each screen pixel. Thus, the rendering engine has to choose which side of a border to give priority to for each border intersection. In 8.5, Opera draws single borders around an element in the following order: top, left, right, and bottom. This means that the bottom border will extend all the way across a figure, the left and right borders will extend all the way to the top, and the top border won't touch either corner at the top of the figure, like so (based on the first test above zoomed to 300%):
Other browsers appear to draw the top border last, extending it to both corners at the top of the figure. What does this mean for the Acid2 test? It means the nose is one pixel higher in Opera than in other browsers. This is easily seen using the third test above zoomed to 300%. In 8.5, there's a row of blue pixels across the bottom of the test:
The only reason I noticed this discrepancy is because I opened the Acid2 test in one page and the reference rendering in another page and went back and forth between them. Lo and behold, the nose looked like it was bouncing up and down. And we can't have that. So, we changed the drawing order for borders. Now, Opera draws single borders in the following order: bottom, left, right, and top, like so:
This change made the rendering of the rows 7 and 8 compatible with the Acid2 reference rendering. Check these test cases to see how your browser handles border intersection: one, two, three, four, and five.
Here's the updated rendering with this fix:
To see the difference between the above screenshot and the Acid2 reference rendering, just open these three images in separate pages and move back and forth between them (using 1 and 2): our previous rendering, our current rendering, and the reference rendering.
More information about CSS Borders Slants and shapes can be found at the following pages:
Note: Comments with a light blue background were made by the site owner.
Not sure
I'm note sure you've done a right thing. While the CSS spec doesn't say in what order to render these borders, there is a default border order in CSS, and it's top, right, bottom, left. Like,
border: 1px 2px 3px 4px;
So I believe it would make at least SOME sence to render borders in this order, but not bottom, left, right, and top, even if other browsers do so...
But I personally would prefer anti-aliasing :-)
By the way, thanks for making a great product!
That's not what I'm talking
That's not what I'm talking about. There has been no change to the way the border property itself works. I'm only talking about rendering order. CSS 2.1 Section 17.6.2.1 rule 4 says, "If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. It is undefined which color is used when two elements of the same type disagree." We're only talking about color differences on intersecting borders here.
Misunderstanding?
I think you misunderstood him. The way I see it, his suggestion is to use the same order (top, right, bottom, left) for rendering that the properties are specified in, since that order is, in a way, "implied".
On the other hand I've always had my own code draw left and top on top :-)
Why is there a testcase for this?
Why is there a testcase for this in Acid2? Why do they say that browsers should do it one way and not the other while there is no spec about it? Every part of Acid2 is, I thought before, perfectly explainable with specs, but this one has surprised me.
I'd say it's inadvertent
I'd say it's inadvertent that this part of the Acid2 test caused problems is any browser. The author picked a way to draw the nose and didn't consider this issue.
Anti-aliasing?
Well, the nose would look just fine regardless of the order in which the borders are rendered. And even if anti-aliasing is introduced later, the nose would still have the diamond shape. So I think it's not a bug (and not a failed Acid2 testcase) to render the borders in whatever order.
True. As I wrote, we did it
True. As I wrote, we did it more to be compatible with the reference rendering and other browsers than because we thought it was a bug. FWIW, browsers supporting anti-aliasing won't be an exact match for the reference rendering either.
AA nose
Actually Hyatt has removed anti-aliasing from Safari to match Acid2. AA was causing red ring around nose.
I'm pretty sure that was a
I'm pretty sure that was a bug in Safari's anti-aliasing.
Rendering Engine
This is beautiful, and we can understand why the changes aren't being applied immediately.
Any speculations, around the office, on what the new rendering engine will be code-named? :)
OperaX powered by the Spiffy® rendering engine.
This isn't actually a new
This isn't actually a new rendering engine, but a major upgrade to Presto. :)
Dotted borders
While we're on topic of borders - why not make dotted and dashed borders behave more like in other browsers?
Opera makes spacing of dots/dashes vary greatly depending on edge length.
When there are several objects near, like table cells, this looks very odd and buggy.
I like idea of varying spacing, but it shouldn't be between 2 and 4 pixels but more like between 1.5 and 2.5. And you could have some special-case rendering for entire table rows.
Tim, thanks for your
Tim, thanks for your explanations, but I _did_ understand the topic. Please read my first comment attentively:
"While the CSS spec doesn't say in what order to render these borders, there is a default border order in CSS, and it's top, right, bottom, left"
What I said was, even if they don't say it what order to render borders with different colors, there is a side order accepted in CSS, at all. It's used in border:, margin:, padding: and maybe some other properties. I understand that these are different things, but my idea was to be maybe a bit more consistent by usign a single side order in all situations.
Ahh. Well, as you pointed
Ahh. Well, as you pointed out, that's just a convention used for those properties and says nothing about the order in which the rendering engine should actually render the borders.
Anti-aliasing
Anti-aliasing would definitely be a plus. On many elements it doesn't make sense, but for 45 degree border intersections, it would.
No, antialiasing would not
No, antialiasing would not be a plus for 45 degree angles. Along with horizontals and verticals, 45° angles look crappier when rendered with AA than they do aliased.