The Natmaster - Natmaster.com
August 2, 2006In Opera's latest release (9.01), they fixed several spacing bugs with their zoom feature. One of these bugs caused improper verticle spacing on Mr. Smiley's head when zoomed out. Now all they need to fix (with regard to zoom) is the anti-aliasing bug.
July 20, 2006An Opera developer has now explained why Opera's rendering bugs do not make Opera fail the test. Apparently, Opera developers know more about WaSP's test than WaSP does. To quote, "Ian Hickson has provided WaSP with the following clarifications about the Acid2 test and how things should behave."
It seems as though there is some disagreement as to what passing the Acid 2 test actually entails. Because of this, I encourage you to read the official guide by WaSP. Specifically with regard to the scrolling issues, "If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll." As the guide only explains visible regions, my more thorough investigation of the CSS has be included below; although I encourage WaSP to make a more concise statement regarding this issue, for further confirmation.
The Discovery
So Opera 9 is released, and the world rejoiced - another browser passing the Acid 2 Test. It was a testament to the growing acceptance of W3C's standards. Truly a great day.
Or was it? Was "passing" really just a marketing ploy by Opera to try to steal some of the fire ('fire' in a good way) Firefox received because of it's superior standards support (compared to other leading browsers)? They certainly appear to be focusing on the Acid 2 test for marketing reasons. (I say this because of their apparent dismissal of high-profile rendering bugs in favor of the last of the minor Acid 2 glitches - fixes that most likely will rarely, if ever, see the light of a real web page.)
I had seen some of these Acid 2 bugs when testing Opera 9 myself, but WaSP's embracing of Opera filled me with doubt. However, after stumbling on a message at WaSP's site, I received an apparent confirmation of my sanity. To quote, "We’ve received some reports here at WaSP that Opera 9 is not passing Acid2 under certain unique scenarios. We’d like to hear from you in comments if this is the case."
The Experiment
All tests were performed on a Windows XP SP2 machine, with Opera 9 (build 8501 - the final release).
Loading up the Acid 2 test, I found the page to be scrollable. (Although there was no visible scrollbar, using the mouse-wheel to scroll worked.) So I scrolled. When I did this, two bars stayed in place while everything else moved - including most of Mr. Face. Interestingly enough, when Konqueror (and most likely Safari, by extension) was put to the test, the scroll-wheel was disabled - which certainly makes sense (at least to me). Unfortunately, this contradicts Opera's interpretation of 'passing' the test. Because of this inconsistency, one of these browsers is not really passing the test as well as they claim. From the CSS of the Acid 2:
Upon examining the CSS markups, I came across some "undocumented" (in the sense that the official guide only mentions the visible elements) sections that explained the 'persistent bars.'
.picture p { position: fixed; margin: 0; padding: 0; border: 0; top: 9em; left: 11em; width: 140%; max-width: 4em; height: 8px; min-height: 1em; max-height: 2mm; /* min-height overrides max-height, see 10.7 */ background: black; border-bottom: 0.5em yellow solid; }
/* bits that shouldn't be part of the top line (and shouldn't be visible at all): HTML parsing, "+" combinator, stacking order */
.picture p.bad { border-bottom: red solid; /* shouldn't matter, because the "p + table + p" rule below should match it too, thus hiding it */ }
Because of the position:fixed property applied to every p element within .picture, both the first p (with tables inside) and the p with 'bad' class were positioned in a fixed manner. From W3C's guidelines, "The box's position is calculated according to the 'absolute' model, but in addition, the box is fixed with respect to some reference." And in explanation of the 'absolute' model, "This means they have no impact on the layout of later siblings."
It seems as though, in this case, Konqueror was the browser at fault.
For a throughout investigation, I had to test all claims. When using the "full page zoom" feature, pages begin to render with artifacts. At this point, one can assume that some Opera fan boys will start claiming bug irrelevance, since Firefox does not even support the feature (note the lack of reference to Internet Explorer, which does sport this feature). However, Mozilla does not claim Firefox supports this feature, but Opera does. To claim support for two features that do not 'play nice' together can be misleading for users. On the other hand, given the complexity of disproportionate zoom calculations, it is understandable that perfect rendering is not achieved.
The Conclusion
It is nice to witness progress with regard to increasing standards acceptance - among browser vendors, and web designers. However, in the case of Opera - that is all that has been achieved. No one has reached the Holy Grail of standards-compliance; it is an ongoing process. And as more standards documents are finalized, more work must be done. I look forward to dissecting "Acid 3."
References
* Grayed sections indicate opinion
