Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Opera 9.0 Fully Passes ACID2 Test

Posted by CmdrTaco on Sun Mar 12, 2006 10:06 AM
from the both-users-celebrate dept.
Rytis writes "Opera has just become the second browser after Safari to be able to pass completely the famous ACID2 test. Mark Wilton-Jones is running a little article on the history of the Opera and ACID tests. Of course, it includes a screenshot of Opera 9 showing the nice happy face saying "Hello world!"."
+ -
story

Related Stories

[+] First Look At the ACID3 Browser Test 133 comments
ddanier writes "Now that all major browsers have mastered the ACID2 test (at least in some preview versions), work on ACID3 has begun. The new test will focus on ECMAScript, DOM Level 3, Media Queries, and data: URLs. 100 tests will be put into functions each returning either true or false depending on the result of the test. The current preview of ACID3 is still missing 16 tests."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Konqueror passed 2nd (Score:4, Informative)

    by GraZZ (9716) <jackNO@SPAMjackmaninov.ca> on Sunday March 12 2006, @10:09AM (#14902344) Homepage Journal
    Actually, Konqueror passed second. Some might say this is less of an achievment since the fixes that allowed Safari to pass could be more easily ported into the Konqueror codebase, but I still think the OSS project that passed Acid2 first should probably get more respect on /. ;)

    Info here [kdedevelopers.org].
    • by Derek Pomery (2028) on Sunday March 12 2006, @10:12AM (#14902356)
      RTFA and you'll see this.
      "Opera 9 (get the weekly build) now passes the Acid 2 test, making it the second browser to do so. And yes, I can count. Safari passed first, and Opera is second. Konqueror and iCab almost pass (and claim to pass), but they both fail to apply one of the styles required by the test..."
      • by jZnat (793348) * on Sunday March 12 2006, @10:32AM (#14902428) Homepage Journal
        I don't know, but Konqueror does indeed appear to pass the Acid2 test [imageshack.us]. The only problem I can see is this odd scrolling bug [imageshack.us], but that probably isn't supposed to be able to scroll anyhow.
        • by Derek Pomery (2028) on Sunday March 12 2006, @10:37AM (#14902445)
          I was merely pointing out what the article said. And since the Opera guy points out the page *isn't* supposed to scroll, I imagine a scrolling bug would indeed qualify as incorrect rendering, so the artifacts in your screenshot would merely support Opera's point.
            • by horacerumpole (877156) on Sunday March 12 2006, @06:17PM (#14904142)
              Actually they care a lot about it - see Bug #289480 [mozilla.org]

              It's just such a complex problem to tuckle that it seems to me (as a sideline spectactor) to be stupid to block the entire Firefox train just for it. They are working on it.

              • by badboy_tw2002 (524611) on Sunday March 12 2006, @08:20PM (#14904531)
                I'm not much of a MS fan myself, but can you really say "paraphrased without bias" and not be trolling?

                From your link:
                "I want to be clear that our intent is to build a platform that fully complies with the appropriate web standards, in particular CSS 2 ( 2.1, once it's been Recommended)."

                Its not really paraphrasing when you make up ideas. That's called "reading between the lines", and you didn't even do that.
        • by onedotzero (926558) on Sunday March 12 2006, @10:39AM (#14902453) Homepage
          It's not supposed to have a scrollbar at all. The parent div (or html or body - I haven't checked the source for a while) is given a property of overflow: hidden.

          --
          onedotzero
          thedigitalfeed.co.uk [thedigitalfeed.co.uk]
        • by Bogtha (906264) on Sunday March 12 2006, @10:52AM (#14902496)

          That's not a bug, that's exactly what is supposed to happen when you scroll the page. From the technical guide [webstandards.org]:

          In the markup, the row is represented by a p element which is fixed to the window rather than the scrollable canvas. If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll.

            • by Krach42 (227798) on Sunday March 12 2006, @01:44PM (#14903054) Homepage Journal
              Safari hides the scrollbar, so I don't know what you're talking about.

              From what I've read here, Konquerer still shows the scroll bar, and Opera doesn't have the scalp come off when you scroll.

              So, Safari passes, everything else still got some work?

              At least they all pass a hundred times better than IE...
    • by babbling (952366) on Sunday March 12 2006, @10:17AM (#14902371)
      I don't think this should be judged based on how much of an achievement it is. The important part is that the browser passes the ACID2 test. How hard it was for each individual browser to get there is not important.

      Who got there first also isn't important, we just need all browsers to get there.
        • by Anonymous Coward on Sunday March 12 2006, @12:47PM (#14902871)
          > I'm all for web standards, but isn't ACID2 a purely academic excercise? It's nice that a browser passes it,
          > of course, but in the real world practically nobody is going to be using CSS in that way.

          It's not purely academic, it's eminently practical - as the site explains, all of the features are unlikely to be used on the same page, but designers rely on each one of them to work correctly at some point, and have been requesting proper support for years so their pages look consistently good on all browsers.
    • by Momomoto (118483) on Sunday March 12 2006, @10:19AM (#14902377) Homepage
      FTA:

      "Konqueror and iCab almost pass (and claim to pass), but they both fail to apply one of the styles required by the test, and as a result they display a scrollbar even though they shouldn't (the Acid 2 guide neglects to mention this style, but see the source code for the test itself):

      html { ... overflow: hidden; /* hides scrollbars on viewport, see 11.1.1:3 */ ... }"
    • by Bralkein (685733) <jack DOT holling ... ntlworld DOT com> on Sunday March 12 2006, @10:30AM (#14902424)
      Well, since KHTML and KJS (I think?) were ported over to Mac OS in the first place in order to create Safari, which then allowed the Apple devs to create the patches that allowed it to pass Acid2, patches which could not then be easily applied back to KHTML and KJS because the code sometimes didn't meet KDE's standards or because the patches were sometimes not supplied in a format that they could easily work with, maybe the KDE devs put in more effort overall :-P

      But seriously, who gives a shit who came first, second or whatever; I think the important thing is that browser developers are obviously making an effort to ensure stricter standards compliance. I assume someone must be working on this for Firefox, so does anybody know when we can expect to see Firefox pass Acid2 as well?
  • by toomanyhandles (809578) * on Sunday March 12 2006, @10:10AM (#14902346)
    Great that they pass the ACID test, but the real-world is just not perfect or by-the-book. They need to be able to handle what really happens, too. Example, my workplace Exchange web interface- Safari misses parts of the page, FireFox renders it fine. ACID test or no, I like the one that works in all situations.
    • by Anonymous Coward on Sunday March 12 2006, @10:24AM (#14902393)
      Could you be a little more vague? It's not unexpected for browsers with different rendering engines to render things differently, especially for web interfaces, very especially if it comes from Microsoft.

      Moreover, it's a fallacy to expect a browser to "work in all situations". I'm sure there are plenty of real-world situations where Firefox fails as well, and where Safari were to succeed in it's place. It's tests like ACID2 that determine a browsers capability to handle all situations.

      The problem Safari is having with Exchange is very likely due to poor coding. Considering it's from Microsoft (you said Exchange web interface, right?), I'm sure Microsoft implemented a slew of hacks to have Firefox compliance (Microsoft is well known for improper web developing practices, to put it lightly).
        • by Bogtha (906264) on Sunday March 12 2006, @11:04AM (#14902528)

          Safari's DOM API is very incomplete. Probably only about 60-70% of what Firefox implements. Oprah's worse, maybe only 30-40%

          I haven't found that. Firefox is ahead on some things and behind on others. For example, Safari supports DOM 2 mutation events, but Firefox doesn't.

          As Internet Explorer has shown, having a solid JS DOM is much more important than supporting every CSS corner case.

          You're joking, right? Internet Explorer's DOM support is prone to memory leaks and doesn't support basic things like event handling. I'd rephrase your statement as:

          "As Internet Explorer has shown, having the largest market share is much more important than supporting most of the CSS or DOM specifications, because that way the web developers work for you, not the other way around."

          I think that a lot of people have blind spots, where they are completely unaware of many parts of the specifications, because they don't work in Internet Explorer or Firefox.

          • by Anonymous Coward on Sunday March 12 2006, @11:12AM (#14902547)
            • by Bogtha (906264) on Sunday March 12 2006, @12:05PM (#14902731)

              IE does support event handling, it just doesn't work the official way.

              It doesn't support event handling as defined by the DOM specifications. My comment is perfectly clear when you don't cut the quote off prematurely.

              Referring to Internet Explorer's proprietary DHTML interface as a "DOM", while technically accurate, is misleading as in common use, the term "DOM" refers to the W3C specifications.

              boohoo.

              How about a little maturity?

              As for memory leaks, FF DOM has the same kinds of issues.

              a) No it doesn't, many Internet Explorer memory leaks [microsoft.com] are an artifact of the JScript engine being unable to refcount properly.

              b) You implied that Internet Explorer had a "solid" DOM. That is not true regardless of the quality of Firefox's DOM. Internet Explorer's DOM doesn't get more "solid" if you distract people by talking about other browsers.

    • by Kjella (173770) on Sunday March 12 2006, @10:43AM (#14902467) Homepage
      ACID test or no, I like the one that works in all situations.

      First off that one hasn't been built, as I've seen IE manage to screw up royally too on sites claiming to work with IE, sometimes only with IE. The trouble with trying to match IE bug for bug is that you can't succeed as you can never duplicate the implementation exactly, you need to render pages wrong according to the standard, and worst of all it is never predictable. I really hate "trial-and-error" programming, and IE is the worst of the bunch.

      In your case, you're trying to use MS generated HTML. I'm sure the fact that Firefox can render it is completely accidental and will be fixed in the next Exchange service pack. You can't expect a company that has a vested business interest in not playing nice, to play nice. The ACID2 test is an assurance that if I code to the standard, I will see none (or at least very few) rendering issues on any browser (except IE). That is very reassuring to people who think "OMG supporting five browsers, do I have to make 5x the number of hacks?" No, you don't. In fact, you'll code to one standard and fix hacks for one browser. Which is actually better than to code to zero standards and fix hacks for one browser...
    • by kherr (602366) <kevin.puppethead@com> on Sunday March 12 2006, @11:17AM (#14902566) Homepage
      Example, my workplace Exchange web interface- Safari misses parts of the page, FireFox renders it fine. ACID test or no, I like the one that works in all situations.

      There are a lot of crappy pages out there. If a page doesn't make it through the HTML validator why should anyone expect a browser to render it? Are your pages at work valid? What's the point of standards-compliant rendering engines if they all allow exceptions to the standard to be rendered?

      A lot of times Safari won't render big chunks of web pages because of malformed markup [mozillazine.org]. Dave Hyatt (rightly, I believe) doesn't want to spend lots of coding effort dealing with error recovery when parsing sloppy web pages. Browsers like MSIE and Netscape (pre-Mozilla) are too permissive and have allowed people to get away with downright bad HTML.

      That said, the Safari Compatibility Hit List [opendarwin.org] was recently created, to either fix Safari compatibility problems or to encourage sites to fix their markup.
      • by Anonymous Coward on Sunday March 12 2006, @10:52AM (#14902497)
        I agree with you on that. It can pass all the certifications it wants, but until Opera supports some of the more basic javscript methods IE and FF have no problem with, it will never be my browser of choice.

        The problems with Opera's JS arise in three situations:

        1) The site specifically blocks out Opera due to scripts 5-6 years old, but happily copypasted throughout the web project by brainless "web designers". Or server-side sniffing, like Yahoo did and still does, AFAIK.

        See here for example, one that I found just a few minutes ago when informing myself of the latest and greatest Bollywood hit: http://www.rangdebasanti.net/ [rangdebasanti.net]

        Their JS code contains this:
        var dom=document.getElementById&&navigator.userAgent.i ndexOf("Opera")==-1 ...
        if (ie||dom) ...
        Use Proxomitron or Opera's cloaking techniques to get rid of the "Opera" part in UA string, and what do you know, the site works perfectly!

        2) The site doesn't block Opera per se, but exhibits "if IE or Netscape" behaviour. Of course Firefox deals with those, as it descends from Netscape. Opera doesn't, and Opera is not IE, either, so it end up in no man's land...

        3) The site has JS errors, and Opera is pretty strict when parsing JS, more so than Firefox or IE.

        Honestly, Opera does not have any JS issues. None whatsoever. It's brainless webmonkeys who have issues with their JavaScript.
  • Tweaked (Score:5, Interesting)

    by Stellian (673475) on Sunday March 12 2006, @10:12AM (#14902354)
    What's more interesting, will it pass ACID3? It's easy to tweak the engine untill it passes a single known test. Historicaly, Opera had (and still has?) problems with both JavaScript and CSS. I must admit though, that the rendering in Opera 8 (pre ACID2) is much better than Mozilla's.
      • Re:Tweaked (Score:4, Interesting)

        by FyRE666 (263011) on Sunday March 12 2006, @01:24PM (#14902987) Homepage
        Opera 9 still displays visual artifacts when using DHTML/DOM Scripting/(whatever people are calling it this week). I recently coded up a quick demo for a bigger project - the demo allowed an image to be uploaded, resized and moved about using Javascript, then "stamped out" by using js+php. I only tested Opera out of interest as It's always been pretty flaky with Javascript/CSS. Moving images with the mouse was fine, but resizing (in the app, this was done by grabbing a corner and moving it) resulted in pixel trails which looked kind of cool, but were not supposed to be there. The "fix", was to continually change the z-index of the image as it was being resized, causing Opera to refresh the canvas.

        The reason Opera is "victimised" by older scripts is due to the ridiculous decision of that company to add code stubs for functions it did not actually support (I remember when it had document.getElementById(), which always returned null - that's why many scripts look for the Opera string, and block it).
  • Good news (Score:4, Insightful)

    by BertieBaggio (944287) * on Sunday March 12 2006, @10:26AM (#14902404) Homepage

    A big well done to the Opera team. Safari passed the test in November last year, and hopefully Firefox will pass soon as well. Increased standards compliace is a Good Thing(tm) for users and webmasters alike. If the minority browsers continue to push standards (which the tech-savvy webmasters follow) it will push IE into improving its own rendering engine. Although even their unreleased version seems to be a bit behind the times...

    From TFA: It is somewhat worrying that IE 6 renders Acid 2 very similarly to Opera 3.6, and the hyped IE 7 renders it very similarly to Opera 4.

    'Somewhat worrying' indeed. I know people (of the pretty-damn-computer-literate variety) that won't switch from IE6 because it "works fine for them". I'm sure they know about the vulnerabilities [now that Symantec says so, it must be official!], the rendering issues and speed*, but they are sticking to their guns. So the only way people like this will have their experience enhanced is by teams like Mozilla and Opera pushing the browser envelope and hoping IE take interest. Either that or some X factor that makes the alternative browser a 'killer app', rather than IE, which is an app killer. (I couldn't resist, sorry!)

    Well done again to Opera. Webmasters everywhere are silently saying a big 'thank you'.

    *Note: I am aware that some will say that IE 6 loads quicker/renders quicker than FF. I have found the two of comparable speed for light pages, and FF slightly faster for 'heavier' pages. Opera is faster than both of them. Draw your own conclusions, and install all three (or two if your run a non-Windows OS). I found an old demo disc with IE 3 recently, and will be trying that out.

  • I like how... (Score:5, Insightful)

    by katterjohn (726348) <katterjohn@gmail.com> on Sunday March 12 2006, @10:27AM (#14902408)
    ... they show IE screenshots, but don't show how close/far away Netscape and Mozilla and Firefox are from passing.
  • by eebra82 (907996) on Sunday March 12 2006, @10:33AM (#14902431) Homepage
    I am happy to see that Internet Explorer 7 passes the ACID2 test somewhat better now. It is actually possible to see the resemblance of a happy face now. Good job, Microsoft!
  • by gEvil (beta) (945888) on Sunday March 12 2006, @10:38AM (#14902449)
    Opera has just become the second browser after Safari...

    Second browser after Safari? Which was the first after Safari to do it? Oh, you mean the second browser, after Safari...It's amazing what commas can do. Learn to use them.
  • by G3ckoG33k (647276) on Sunday March 12 2006, @10:48AM (#14902483)
    Is that a coincidence?
  • by fugas (619989) on Sunday March 12 2006, @10:52AM (#14902495) Homepage
    Take the ACID2 [webstandards.org] test...
  • Yeah, but... (Score:5, Interesting)

    by Anonymous Coward on Sunday March 12 2006, @11:18AM (#14902568)
    Can opera handle third party cookies properly yet? A little more important than styles rendering in my opinion.
    • Re:Yeah, but... (Score:5, Interesting)

      by Jugalator (259273) on Sunday March 12 2006, @01:41PM (#14903040) Journal
      Can you be more specific what's not handled correctly? I can block third party cookies, I can manually delete third party cookies, and I can allow them, and the cookie settings seem to reflect they're not added when they should, and respected when they're allowed. If you're talking about a specific bug here, you must be much more clear about what you're talking about.
  • by Jugalator (259273) on Sunday March 12 2006, @11:23AM (#14902592) Journal
    Mark Wilton-Jones is running a little article on the history of the Opera and ACID test

    There's a more useful history about it here [timaltman.com] (in reverse chronological order), describing what exactly the standard compliance problems were, and how they fixed them, starting with Opera 8.00.

    And go to the Opera Desktop Team blog [opera.com] to download the actual build that works with this. However, note that this build should be treated like a Firefox nightly, and there may be some pretty serious rendering regressions, doing currently more damage to the layout engine than good from following the Acid2 test. ;-)
    • Re:Cool (Score:5, Insightful)

      by Uber Banker (655221) * on Sunday March 12 2006, @10:28AM (#14902411)
      Firefox is good. The plugins extend the browser hugely.

      But I'm happy with Opera, be it for the faster responce I get on the same machine as I have Firefox installed on, the ability not to search for plug ins for whatever feature I need, 'it just works'

      I just find Opera is faster at implementing standards, is more reliable with IE geared sites (don't like the fact, but I have to be pragmatic and deal with it as promoting interoperability is not what pays my bills), is more innovative (has important new features first and has them 'out of the box') and makes a good testing ground for my projects, and is all together very nice. And now it's free (as in beer).

      Firefox is good. Opera is good too. Different priorities for different users, I don't have access to source code or the ability to contribute in the same way, but for me I'm fine with that. Both are far superior to IE's features, security and map for an interoperable internet in the future. Nuff said.
      • According to WaSP (the people who wrote the Acid2 test), [Browser not for Microsoft Windows] passed first, followed by [a second browser not for Microsoft Windows] and [a third browser not for Microsoft Windows]. [...] That makes Opera the 4th browser to render Acid2 correctly.

        It also makes Opera the first publicly available web browser that renders the Acid2 page correctly under the Microsoft Windows operating system. This is important if you don't want to have to re-buy your PC (in switching to Mac OS X, which runs only on Apple hardware) or your peripherals (in switching to Linux, where SANE still doesn't support my flatbed scanner [sane-project.org]). Or is Konqueror for Cygwin/X considered stable yet?

    • by vidarh (309115) <vidar@hokstad.com> on Sunday March 12 2006, @01:04PM (#14902938) Homepage Journal
      The point is that the CSS spec specifies exactly the behavior a browser should use to handle invalid CSS: It should ignore the declaration, but continue to parse the file. A browser that accepts invalid CSS declarations, or fails to recover and continue parsing is not conformant.

      So the test is verifying conformance not only with treatment of valid CSS, but also correct treatment of invalid CSS, which is very important given that a significant part of compatibility problems between current web-browsers is caused by different behavior in the face of errors - whether they ignore it, stop parsing, try to render it anyway etc.

                • Re:Ah opera... (Score:5, Insightful)

                  by TrekkieGod (627867) on Sunday March 12 2006, @01:09PM (#14902952) Homepage Journal
                  I've barely been making websites a year, and even I've learned that on the web, markup standards are only a guideline.

                  Then maybe you should stop making websites, because people like you are the problem.

                  They're "only a guideline" in that the FBI won't knock on your door if you don't follow the standards. And oh yeah, a lot of browsers will accept your sloppy coding and "render it fine." However, if you want a world where all browsers render all content in the same way, that can't be accomplished by the developing team of any browser. That can only be accomplished by developing and following standards. So, you blame the browser when they don't follow them, and you blame the web developer when he doesn't follow them.

                  I'm fine with browsers who want to go the extra mile and have non-standard code render correctly, as long as they don't sacrifice proper rendering of the standard code to do it. That doesn't excuse you coding incorrectly, though.

                    • Re:Ah opera... (Score:5, Informative)

                      by TrekkieGod (627867) on Sunday March 12 2006, @05:06PM (#14903860) Homepage Journal
                      I really d I really don't see how I can be considered part of the problem.

                      Well, it's great that you do all that work to consider your visitors. What I was referring to was your comment that following standards isn't really that important, it's just a guideline. That train of thought is part of the problem.

                      Think of a world where every browser renders everything in the standard correctly. Suddenly, your job is easier. In order to make sure that your web page renders correctly for the visitors using IE, Firefox, Safari, Opera, Konqueror, whatever, you don't need to actually test it with each one of those browsers. You just need to make sure your site follows the standards, and the rest "just works". If you skip out on things because "they're dumb," well, you may think you're right, but why do you expect browser developers to share your opinion?

                      You'll see 12 ridiculous errors

                      Depends on your definition of ridiculous. You wouldn't expect c code that doesn't have syntax exactly right to compile, so why do you expect html syntax that isn't exactly right to render correctly?

                      from things like > characters whose position it disagrees with

                      I didn't find that. I found error #3. It's not complaining about the position of the character, it's complaining that you placed that tag inside your unordered list, but not within a list item tag. I checked the source code and you have:

                      <ul id="utabs">
                      <a href="?page1"><<</a>

                      If it's part of the unordered list, it should be inside a <li> tag. If you don't want for that to appear the same as the other list items, you should give it a class attribute and handle it in your css (there are other correct ways of handling it too, if you don't like that for some reason).

                      That and a childish remark about my html tag which was funny for the 1.3 seconds I spent writing the top line...

                      It wasn't your remark that it complained about. It complained about your type. That's not how you specify 4.01. From a W3C page, there's this example, using SGML to do what you want (for strict 4.01).:

                      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
                      <html>

                      Heck...you should be fine just skipping that altogether. Close your html tag, and don't put the type thing.

                      errors that don't tell me anything useful or constructive at all

                      The validator doesn't tell you how to fix it, just that it found something wrong. However,

                      a wikipedia url I pasted, which the validator decided to parse and rate

                      For that error, the validator told you exactly what was wrong...in bold. "The most common cause of this error is unencoded ampersands in URLs". I've actually noticed that in other places in your html code for that page, stuff that I expected the validator to complain about, but it didn't.

                      In html, if you want to have a "<" or ">" that is not part of a tag, you use a code. you type in "&lt;" for < and "&gt;" for >. If you want to type "&", you type "&amp;" Replace the & in that url, and it'll pass. You should replace the <'s I mentioned in error #3 with the correct codes too, even if the validator doesn't complain about it.

                      I'm not trying to be a bastard about it. I hope my comments help you understand the validator better, and see that it's not so useless as you've come to believe. It's great that you've been putting effort to make sure your visitors get the best experience they can on your site, and I hope you'll keep doing so.