Opera 9, Acid2 and Web Forms 2.0
It seems the latest preview release of Opera comes pretty close to passing the Acid2 test. Apparently there is only one bug left to fix.
After the initial announcement of the second acid test, a race began to become the first browser to pass it. Safari won by a streak and was followed by iCab* and Konquerer. However, these were internal builds only and since then there has been no officially released browser that passes the test.
Also included in this release of Opera is support for some of the Web Forms 2.0 extensions. I’m sorry to report that this is one ugly implementation. Worse than that, the new controls (date pickers etc) are completely inaccessible unusable by keyboard. I assume that this will be sorted out by the time this release is final.
*Now in public beta.
Comments (17)
Leave a comment
Comment: #1
You make me curious, what did you test against? Also, it depends on which keys you use (which is indeed not that accessible, but not inaccessible). I can control most controls using tab, the space bar and directional buttons. Some more constructive criticism from a WaSP and WHATWG member would have been nice.
Comment: #2
Anne – the version I used was all but totally inaccessible using the keyboard. Particularly the date picker popup. The arrow keys made the page scroll and the number keys had weird effects like causing the content to zoom. I’m assuming that these anomalies will be ironed out before the product is finalised. As far as constructive criticism is concerned, Derek Featherstone (an accessibility expert) is looking at this release, particularly the Web Forms 2.0 extensions. I can get him to forward his findings to you or another Opera employee if you like. As a WHATWG member I have a vested interest in the Web Forms extensions working well. This is an alpha release so there is plenty of time to fix the problems.
Comment: #3
“was all but totally inaccessible” this puzzles me. Anyway, sorry for mentioning directional buttons, just use tab and the space bar. Anyway, please forward your findings. I will make sure they get to the right people. Thanks.
Comment: #4
I probably overreacted with the “all but totally inaccessible” comment. It seemed inaccessible to me because I am used to using the arrow keys to navigate popups and spinners on a Windows platform. Having spoken to Derek I am assured that the controls are indeed accessible. However, there are definitely some issues with keyboard navigation. Andrew Gregory has begun to summarise them here:
http://my.opera.com/community/forums/topic.dml?id=108761
Comment: #5
The canvas implementation is incredible slow as Erik Arvidsson pointed out in his blog http://undefined.org/js/canvas0000.html
Comment: #6
The canvas implementation is no slower than Safari or Firefox’s. The problem lies with the specific test case who fails to clear the path after each operation. This means that Opera will draw first 1, then 2, ad nauseaum arcs.
If you want to verify that canvas performs decently, check out my canvas mandelbrot plotter
Comment: #7
wow, that’s face is looking quite good now. Opera 9 you say, I’m having troubling keeping up.
Comment: #8
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.
Comment: #9
We had similar problems with :hover rules on some Web sites. Many authors didn’t specify classes, IDs, and/or elements along with the :hover pseudo-class in selectors (thus triggering the universal selector). Internet Explorer only supports the :hover pseudo-class for A elements, so most page authors didn’t know that a problem existed. Again, after unsuccessfully attempting to get the pages fixed, we decided to break the spec. and prevent the :hover pseudo-class from working with the universal selector. This causes the nose in rows 6 to 9 to turn red when hovered rather than blue.
Comment: #10
os x tiger 10.4.3 was just released, which claims that safari now passes the acid2 test. when i checked the output from the test to the reference rendering, the nose was different. everything else was the same.
Comment: #11
Tim Altman has a nice explanation of the nose issue. (The short story: If a browser renders the nose one pixel too high, it’s strictly not a bug, but keeping compatible is still nice)
Comment: #12
I have been running Tiger 10.4.3 and Safari is passing without any nose issue on this Mac. The nose does change colour to blue on mouse over, black when not on mouse over. Maybe there is something else at issue, installed plugins? haxies or enhancers? But at lease we have a shipping, non-develpment, non-beta browser that passes Acid2.
Comment: #13
[…] Opera應也沒問題! http://team.eyou.com/?q=node/379 […]
Comment: #14
I tried that “acid” test thing for FF 1.5. Didn’t look so good…
Comment: #15
ACID2 compliant version of Konqueror was released on November 29th 2005. Guess this would be the first officially released browser to pass the test?
Comment: #16
[…] s until the browsers ship with native XForms support and I can’t wait for Firefox to support it. February 22 […]
Comment: #17
once IE, Opera *and* FF come with native XForms support, ..then we’re rocking :p
Comments are closed.