The Good Life... a weblog about life, technology, and the Opera web browser

Two days ago, we announced we had achieved 100/100 on the DOM portion of the Acid3 test. Later that evening, a bug was found in the Acid3 test itself. The bug was fixed and the WebKit team announced that they had achieved 100/100 on the DOM portion of the test and they had pixel-perfect rendering, making them the first to achieve two of the three pass conditions (congrats on that, by the way!).

Today, we'd like to announce the same. We have achieved 100/100 with pixel perfect rendering:

This screenshot is copyright Opera Software ASA and released under the Creative Commons Attribution-ShareAlike 3.0 License.

Windows and Linux users may test this out themselves by downloading the GOGI build available from the Opera Labs. A note about these builds: GOGI, short for Generic Opera Graphics Interface, is a tool our Core team uses internally to develop our cross-platform/cross-project code. It has a very simple UI, which is nothing at all like Opera for Desktop. It is in no way meant to replace Opera for Desktop and we don't expect to duplicate any GOGI features in Opera for Desktop. It also lacks some security features, and thus we recommend that it not be used for regular surfing. Furthermore, please don't file bug reports about problems you find in GOGI.

Now, WebKit and Opera have reached the same point and have the same challenge: optimize enough to run test 26 in 33ms.

At the beginning of March, the Web Standards Project (WaSP) released Acid3, a web standards spot-checking test. As with Acid2, the goal of the test is to improve interoperability between web browsers. The Acid3 test consists of 100 DOM sub-tests, which assess a browser's support for DOM, CSS, SVG, and ECMAscript, as well as some rendering tests. To pass the test, a browser must render the test pixel for pixel identical to the reference rendering, pass all 100 DOM tests, and animate the test smoothly. So far, Opera is the only browser to pass all 100 DOM tests (more on that in a bit). Information about the pass rates for browsers is available in Wikipedia's excellent article about Acid3.

While browser vendors implement the same web standards, their implementations are sometimes incompatible due to bugs, different interpretations of the standards, or missing functionality. Incompatible implementations increase the development time and decrease the innovation of web sites/applications. Thus, the WaSP Acid tests establish a compatibility baseline that web developers can count on during development. That is, once browser vendors pass the tests.

As with the Acid2 test, the Acid3 test should not be viewed as a race. It's all about improving interoperability and making the Web a better place. If only one or two browsers pass the test, the test isn't a success and the Web can't improve. It's important that all major browsers (Firefox, Internet Explorer, Opera, and Safari) pass the test. The Acid2 test was released in April 2005, yet three years later only final releases of Opera and Safari pass it. That means web developers still can't rely on the functionality in Acid2 as a baseline. It'll probably be at least two or three years before the functionality tested it Acid3 can be used as a baseline.

Opera's Progress on Acid3

At Opera, we rely on web standards to allow us to render live web sites correctly. Interoperability allows us to use a different rendering engine, yet render web pages the same as other browsers. That's one of the reasons we've put a lot of focus on the Acid3 test since it was released:

• Opera's latest final public release, 9.26, scores 46/100 on the test and has some significant layout problems
• The initial alpha of Kestrel, released in September 2007, scores 58/100 on the test and has some small layout problems. At that point, we had not done fixes specifically for the test, which is a testament to the rendering engine improvements in Kestrel
• Our latest snapshot release scores 77/100 and has some small layout problems
• Our latest internal build (screenshot below) scores 100/100 and renders the test almost perfectly! We have some work to do still, but we expect to have that taking care of shortly. UPDATE (2007-03-27): a bug was found in the Acid3 test, which may affect our pass rate

This screenshot (and the screenshot it links to) are copyright Opera Software ASA and released under the Creative Commons Attribution-ShareAlike 3.0 License.

This is the first time a screenshot of GOGI, our internal testing platform, has been released publicly. Core developers and testers use GOGI for their development, so they have a platform-independent setup. Also, Core testers do regression testing in GOGI before Core fixes are released to the Desktop Team build. That said, Kestrel may not pass the Acid3 test, even if internal builds do. Some of the internal fixes are experimental and they need regression testing before they can become part of a Desktop release. We hope to have a public test build within the next couple weeks that passes the test.

Update (July 17, 2006 3:00PM): Right, so the day after I wrote about widget auto-discovery, we go and release a new service to make any newsfeed into a widget. Details below. I knew I used version numbers instead of simple integers for a reason.

Back in March, Opera Software launched a monthly newsletter called Opera Bits. Some times I run across bits of information that don't quite make a full blog post, but certainly deserve a mention. So, I'll be running my own semi-monthly Opera Bits. And it's time for the first issue:

1. First, if you haven't already heard about Greased Lightbox, you should check it out. It's a user script "designed to enhance browsing on websites that link to images such as Google Image Search, Flickr, Wikipedia, Facebook, MySpace, and deviantART." After it's installed, you just click on an image and the full-sized version loads on screen. Press ESC or click the page and you'll get back to the original page.

   Here's how to get it working:

   Note: You'll need Opera 8.0 or later.

   1. Create a folder on your hard drive where you'll save the script. I usually have lots of Opera installs, so I have an "Opera" folder ("C:\Program Files\Opera\" on Windows and "/Applications/Opera/" on Mac) and I place a "User JS" folder inside that folder. This is simple way to collect all your Opera-related stuff in a single place.
   2. Go to Tools > Preferences > Advanced > Contents > JavaScript options in Opera and set "User JavaScript files" to the folder you created in the previous step.
   3. Download/save the script to that folder.
   4. Now, go back to the Greased Lightbox page (it may be necessary to reload the page) and click on one of the example images at the bottom.

   Neat, huh? For more user scripts, check out userjs.org. The only other one I'm currently using is Stop form focus.

2. Web-based e-mail accounts are all the rage these days; everyone seems to be using Gmail, Yahoo! Mail, SquirrelMail, etc. Unfortunately, it's not clear how get to your webmail account when you click on a "mailto" link on the Web in Opera. Rijk has put together a guide you can use to get your favorite webmail account working with Opera. Further instructions are on Rijk's page.

3. Since Opera 9.0 passed the Acid2 test back in March, there's been a sprinkling of reports from users that their version of Opera didn't pass. This has been widely publicized recently by The WaSP, as well as various blogs.

   After analyzing the problem reports, we've found no reason to believe that our claim was incorrect. Mark Wilton-Jones (a Technical Writer at Opera Software) has put together a comprehensive guide to the Acid2 test, which includes detailed information refutting the problem reports. In all reported cases we've analyzed, the observed failures were related to non-default preferences—which invalidate the test—or misconceptions about the way the test works.

   While not (currently) specifically stated in the Acid2 guide, the Acid2 test is meant to be tested using a browser's default settings. The following preferences are the most common causes of apparent failure:

   • View > Fit to width. This is an advanced rendering mode that purposefully breaks standards to allow Web pages to remain usable at various screen widths. This includes ignoring or changing some styles defined for a page, which invalidates the test.
   • View > Small screen. As with "Fit to width", this is an advanced rendering mode that purposefully breaks standards to make Web pages work better on small screens. This includes ignoring or changing some styles defined for a page, which invalidates the test.
   • View > Full screen. Opera's full screen mode uses styles written for "projection" media types (such as slide shows) by default, though it does fall back to styles written for "screen" media types (such as Desktop computers) if no "projection" media types are found. While this does not seem to adversely affect the Acid2 test, the test is meant for user agents that support the "screen" media type.
   • View > Images > Cached images or View > Images > No images. The Acid2 test uses images to represent the eyes, thus if they are disabled, the test is invalid. Opera has a bug that is visible in the test when re-enabling images or showing only cached images, but that in no way means Opera does not pass the test. Remember, the test is only valid when used with a browser's default preferences.
   • View > Zoom. Zooming a Web page changes the way that text and images interact. When the Acid2 test is zoomed in Opera, some red artifacts may appear around the eyes. This is a bug in the way that Opera handles rounding of values while zooming, but it in no way means that Opera does not pass the test. Again, changing the zoom preference to anything other than 100% invalidates the test as it changes the browser's default parameters.
   • Preferences > Advanced > Fonts > Minimum font size. The Acid2 test specifies certain elements using pixel units. If the minimum font size is raised from its default, the pixel-unit elements are too large compared to other elements, making the test distorted and invalid. Default preferences....
   • View > Style. Using any setting other than "Author mode" or applying your fonts, colors, styles, etc. in "Author mode" changes the style cascade used in the test, thus invalidating the test.

   Other reported problems with the Acid2 test in Opera have to do with misconceptions about how the test works:

   • Some people believe that the Acid2 test shouldn't scroll when you use a mouse scroll wheel, keyboard arrows, or other scrolling mechanisms because the test doesn't have a scroll bar. If the test is scrolled, parts of the face fall apart. Mark Wilton-Jones has already done all the necessary research about this and published it in his comprehensive Acid2 guide. The gist is that the test should not show a scroll bar, but whether the test should scroll when using one of the above methods is not defined in the W3C CSS specification and is not part of the test.
   • Some people believe that changing the browser screen width should not change the test. When you make your screen smaller after the test is rendered, two pieces of the face detach (the same pieces that detach when scrolling). This behavior is not defined in any W3C specification. Changing the screen width changes the width of certain elements, which can cause the page to scroll, leading to the same problem mentioned above.

4. The last two Opera 9.01 weekly builds have included a bunch of nice IMAP fixes that weren't fully described in the changelogs. First, we did some major optimizations when changing the flags (Read, Deleted, etc.) of multiple messages. Previously, we would send two commands to the server for every message we wanted to mark as read, unread, deleted, or undeleted. Now, we send one command for all messages. So, if you were changing 200 messages before, we'd send 400 commands to the server. Now, we send just 1.

   Additionally, we fixed some bugs related to randomly redownloading groups of messages, made it possible to permanently delete single messages from the Trash view (previously they'd reappear) rather than forcing users to permanently delete all messages, and fixed some problems with messages not being removed from a view when they were moved or deleted. Overall, the IMAP experience with the current 9.01 weekly build is much better than with Opera 9.0 final.

5. Arve recently wrote about using widget auto-discovery, which makes Opera 9.0+ show a widget icon in the address bar when viewing your site. This feature should only be used for widgets that display an RSS/Atom feed of your site. Hot on the heels of Arve's article, the Opera Community now allows blog authors to automatically create a widget of their blog and advertise it via auto-discovery. Spiffy.

   Update: And hot on the heels of the Opera Community announcement, we've released Widgetize!, a service to generate widgets for just about any newsfeed. Simply go through the wizard and it'll give you a URL to your very own widget. Spiffy × 2.

   I've Widgetized! Have you?

I hope you've enjoyed this (updated) issue of Tim's Opera Bits. See you next time.

Smile, Opera passes the Acid2 test! The above screenshot is from build 8249 (compare to the reference rendering), where we fixed a problem with the stacking order of floated and inline elements. According to the Elaborate description of Stacking Contexts in the CSS2.1 spec., floated elements are supposed to be under inline elements, though Opera painted them on top. This caused two problems in rows 4 and 5: the eyes were dimmed and there was a red bar to the right of the eyes. Check this test case to see how your browser handles it.

This last change had caused some regressions in the rendering engine, but they should all be cleared up by now. Also, since Opera 9 is still under development, there's a possibility that there could be further regressions in the rendering engine that could cause a weekly build not to pass the test. We don't expect this to be the case, though.

For an overview of the fixes we've done to get Acid2 working in Opera, have a look at http://weblog.timaltman.com/category/opera/acid2/. You can also compare screenshots by visiting http://timaltman.com/acid2/. If you're using Opera, simply press Space repeatedly to view each screenshot after navigating to that directory.

Want to test Acid2 in Opera yourself? Download the latest weekly build from the Opera Desktop Team blog!

Update: This post was originally made on February 10, 2006. However, we found that we needed to do some additional information verification the next day and took the post down. Verification now complete, the original post is back:

Two more Acid2 fixes came in build 7981. These changes make no visible difference in the rendering of the test. Instead, they remove the scrollbar on the page in which the test is displayed. As with several other items, this part of the test is not mentioned in the Acid2 guide. Personally, I didn't even notice the problem until a colleague pointed it out. Now, on to the bugs.

In the Acid2 test, the HTML element is set to overflow: hidden, which should hide the scrollbar on the page, regardless of the page's length. However, in Opera, if the CSS overflow property was set on the root element of a document, the property would not be propagated to the viewport. For HTML documents, that meant setting overflow on the HTML element would not change the overflow property on the BODY element. This bug is now fixed and the scrollbar no longer appears on the Acid2 test page. Check this test to see how your browser handles it.

Unfortunately, Opera had another bug which would break Acid2 after the above fix. In particular, if a link went to an anchor in an element set to overflow: hidden, Opera wouldn't scroll to that anchor. Check this test to see how your browser handles it. Though the URL for the Acid2 test is http://webstandards.org/act/acid2/test.html, the visual portion of the test is at http://webstandards.org/act/acid2/test.html#top. Thus, without fixing this bug, there would be no way to scroll to the visual portion of the test. Thankfully, these two bugs were fixed simultaneously.

There is no updated rendering screenshot, as the rendering itself didn't change, just the existence of the scrollbar for the page. Load the Acid2 test in Opera 8.51 and Opera 9.0 Preview 2 to see the difference.

The most frequent criticism I've seen about the Acid2 test is the inclusion of SGML comments. Thankfully, the test author has taken the criticism to heart and removed the SGML comment requirement from the Acid2 test in favor of the Web Apps 1.0 comment spec.. If you take a look at the test source now, the old SGML comment test has been changed to:

<div class="parser"><!-- ->ERROR<!- --></div></div> <!-- two dashes is what delimits a comment, so the text "->ERROR<!-" earlier on this line is actually part of a comment -->

We were wary of fixing our SGML comment parsing problems in the first place, so this is a positive change in the test. It looks like we have just one more bug to fix before we pass the Acid2 test, though there's still one more update to do about changes already visible in Opera 9.0 Preview 1, so stay tuned for further updates.

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:

• Eric Meyer's Slantastic Demo (linked above)
• Lasse Reichstein Nielsen's Information on Border Slants
• Mark Wilton-Jones' Shapes with borders tutorial
• Mark Schenk's Basic Tangram Set
• Tantek Çelik's A Study of Regular Polygons

One more Acid2 fix came in build 7841: if a :before or :after pseudo-element existed in a page's stylesheet that didn't match anything in the document, it would cause odd things to happen. I sincerely doubt any other browser has this problem, but if you really want to check, use this test case. The eyes now render, though there are still other problems in rows 4 and 5.

Here's the updated rendering with this fix:

We're now finally up-to-date with the internal build screenshot posted at the beginning of August. Here on out is uncharted territory.

Our next update comes from Merlin build 7830, which includes three fixes for problems seen in the Acid2 test. First, we fixed a problem with anonymous table creation. More specifically, if a table existed within an anonymous table row, then the table row was terminated after that table. This partially fixed the problems in row 14 and beyond. Check this test case to see how your browser handles it.

Second, we fixed a problem drawing backgrounds on tables without rows, but with both width and height specified. This change fixed the rest of the problems seen in row 14 and beyond. Check this test case to see how your browser handles it.

Third, we now correctly parse SGML comments in Standards mode. I posted about this previously because at the time we weren't sure we would fix this issue. We decided to give it a go, but we're already seeing problems on several pages. We'll gather additional feedback during alpha and beta releases of Merlin and make a decision whether or not to keep this change before the final release.

Here's the updated rendering with these three fixes:

As I reported previously, fixing some of the Acid2 bugs requires major code rewrites. In order to stop regressions, we try to avoid major code rewrites once we've had a Final release for a given version of the rendering engine[1]. The current version of the rendering engine (code-named Presto) is as close to passing Acid2 as it's going to get. Until we release a new version of Presto (and it'll be quite obvious when we do), it is highly unlikely that there will be any more changes in Opera's rendering of the Acid2 test.

But don't fret! As you've seen, we've already progressed very far on the next rendering engine update. The first screenshot[2] from the new version of Presto comes from a build including three Acid2 fixes. First, the gap between rows 9 and 10 was fixed by a rewrite of our margin collapsing code. The problem shown in the Acid2 test was related to floats followed by elements with the clear property set. Check this test case to see how your browser handles it. There's also a large number of margin collapsing tests in Ian's ad hoc test suite.

As discussed previously, Opera didn't recognize the :hover pseudo-class if it wasn't used in combination with other selectors. Our second fix in this build was to change this behavior so Opera is now spec. compliant when using a Standards mode DOCTYPE. The behavior when Quirks mode is triggered is unchanged. Check this test case to see if your browser styles the :hover pseudo-class. Though it's not visible in the screenshot below, the nose now turns blue when hovered instead of turning red.

The third fix was a proper fix for rows 10 and 11, which had been fixed previously, though the change was later reverted due to regressions. See the previous post for details about this bug and fix.

Here's the updated rendering with these three fixes:

And here's the updated rendering with the nose hovered:

Unfortunately, major code rewrites introduce bugs and this build also has two visible regressions: the eyes are not visible anymore and row 14 has gotten worse. No worries, though: they'll be fixed soon.

[1] And for what it's worth, this is usually why rendering engine bugs go unfixed for several releases.

[2] Note that this screenshot is from a build previous to our current internal build screenshot, as I'm trying to show how we got to the screenshot in the current internal build.

NOTE: I left out the third fix previously, so I've included that information now. -- Tim, 2005-08-29.

NOTE 2: I added a screenshot with the nose hovered for the non-believers. -- Tim, 2005-10-19.