Opera 9.0 Fully Passes ACID2 Test
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!"."
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.
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?
I don't know, but Konqueror does indeed appear to pass the Acid2 test. The only problem I can see is this odd scrolling bug, but that probably isn't supposed to be able to scroll anyhow.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Safari's DOM API is very incomplete. Probably only about 60-70% of what Firefox implements. Oprah's worse, maybe only 30-40%
I think both these 'minor league' browsers over emphasize CSS support (like ACID) because it gets them headlines at wankerfests like Slashdot. As Internet Explorer has shown, having a solid JS DOM is much more important than supporting every CSS corner case.
Hi,
No its not. Where can I download the source?
Oh wait I can't. Not an OSS project. I can get the khtml part -- which I've already got because we real open source people made it. khtml is _L_gpl, so it can be linked to closed source code -- like safari. Safari is a closed source app that uses lgpl khtml. Good on them for using khtml, bad on you for lying about safari being OSS.
You CANNOT build safari with the webkit and other bits of source they give you. I'm getting tired of people claiming Apple is a lot more friendly toward OSS then it is. Its just using OSS for a free ride.
"Computers will never truly be free until the last windows user is strangled with the entrails of the last mac user."
I wrote off Opera the when they came out with v8 and decided to tell the user every time that they visited a site not using a 256bit key that the site cert was defective. I wasted countless hours trying to assure our clients that their users contacting them was nothing to worry about. The opera folks trumped the firefox arrogance and assumed that since Verisign had just started selling 256bit certs, then all sites should immediately upgrad their cert regardless of cost or validity of their current cert. Maybe they were receiving checks from Verisign?
Karma means nothing to me, so suck it...
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. 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 was recently created, to either fix Safari compatibility problems or to encourage sites to fix their markup.
Can opera handle third party cookies properly yet? A little more important than styles rendering in my opinion.
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). Or is Konqueror for Cygwin/X considered stable yet?
Firefox comes pretty close to passing the test, but not quite. Its performance falls somewhere between Opera 7.5 and 8.0, but sadly I haven't the means to post my own screenshot. However, curious users can go ahead and take the test themselves right here: http://webstandards.org/act/acid2/test.html
Also, It would appear that Opera 9 has just one thing wrong - the nose. It's not supposed to be blue, it's supposed to be black, as per the sample rendering here: http://webstandards.org/act/acid2/reference.html
we just need all browsers to get there.
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.
Animated gif illustrating the rollover effect.
Only in the corporate world [does the dollar matter above all].
For one thing, browser developers need to eat.
More importantly, the corporate world pulls the strings of the government in too many highly developed countries. If Microsoft gets to a certain level of power over the United States government, then Microsoft could make a new "security" (that is, anti-fair-use) feature attractive to publishers in the next version of IE, make the feature exclusive using patent law, anti-circumvention law, or something else, and then con Congress into requiring that feature in web browsers distributed to the public. Remember the proposed CBDTPA and Microsoft's application for a patent on operating system support for the "trusted" computing that would have been required under the CBDTPA?
Presumably that means that other WebKit based software should also pass - the latest build of Shira looks like it does.
Not tested any others but I'm sure Xylescope, TextMate and OmniBrowser all use WebKit too.
'Capitalists of the world, unite! Oh
I'm not a programmer by any means, and I hardly know anything about html, which is why i'm asking this question I guess. Why is it so hard to make a browser that is compliant to standards? And is there an advantage to making a browser that doesn't comply? I've always wondered this.
ACID2 has nothing to do with w3c standards. ACID2 is a test of "proper behavior" when the CSS is completely invalid. It's "important" since most web lackeys can't write correct code... so browsers need a way to display improper code in a "proper" way -- that's what ACID2 is about.
Personally, I think the correct rendering of the ACID2 test is a blank page, or maybe an error message that says something like, "This is not a web page."
My other car is first.
In network programming, the "best practice" is "be strict in what you send and tolerant in what you receive". In any kind of programming, I think one should strive to fail as gracefully as possible.
Then why in hell do you expect it out of a rendering engine???
Several reasons.
First of all, it's very hard to write a language that's powerful enough to be useful for interesting real-world problems, but still strict enough to make 'well formed' versus 'badly formed' a simple binary decision. Second, and more important, a language spec not only contains a syntax definition -- the rules that say how statements should be written -- it also defines the semantics of the language: the rules that say what a given statement means.
Take C's famous:
x = 3;
x = x++ * x--;
for instance. It's well-formed code, but the semantics are undefined. Officially, x can contain any value after that snippet executes, and it can legally contain a different value every time the snippet executes. BNF (the language used to write syntax defnitions) isn't powerful enough to define that as a syntax error while leaving "x = y++ * z--;" alone, because BNF doesn't have any way to identify specific variables. OTOH, mandating a specific result in the semantic definition imposes all sorts of subtle order-of-execution constraints, which create all sorts of problems for any programmer who wants to write a compiler.
In the world of HTML semantics, there was the big "is a paragraph a container, or just something that sits between blocks of text (like a break)?" debate back in the mid-90s. Choosing the 'container' option made CSS possible, but it broke the (then) standard rule that <P> was semantically equal to <BR><BR>.
On top of that, HTML is a structural language, not a layout language. There's no universal 'standard' that says the bullet points in a list have to be indented, or that paragraphs should have a blank line between them. Those are formatting conventions that graphical rendering engines have more or less agreed upon, but which aural web browsers (for instance) can't render at all.
Bottom line, an HTML document is not and was never intended to be handcuffed to one specific page rendering. There are an infinite number of equally valid renderings for any HTML document, so declaring one 'right' and another 'wrong' is a tricky business indeed. Plus, there are about ten different, legal, W3C-approved versions of HTML, based on at least three different syntactic and/or semantic models. <P>text</P> is valid HTML-3.2, for instance, but invalid XHTML-anything, because in XHTML, all tag identifiers MUST be lowercase.
Under those conditions, a browser that chokes on pages that don't conform to one specific set of syntax rules, one specific semantic model, and one specific set of rendering conventions would be roughly useless.
I am sorry but opera does have broken javascript.
u gs/ Look at bug 17 for the example.
getElementById confuses name and id. If you have an item with a name that is the same as the id you are looking for if the name was defined first then opera will return that. That is flat out broken behavior and it was copied from IE and it is still broken in Opera 9. http://www.gtalbot.org/BrowserBugsSection/Opera9B
That is the reason why neither opera or IE are supported for our more advanced editing interfaces. It just takes too much money to code around the bugs in those browers compared to the customers just downloading firefox, safari, konqueror etc. We have even given them a choice and they preferred to just download firefox.
Computer modeling for biotech drug manufacturing is HARD!
On the contrary. In HTML, error handling is not defined at all. So different browsers do different things when you, say, forget to close your opened H1 elements or forget to put a TR element around you table cells. As such code will get written, and is put on the web when it looks OK in the current market leader, all other browsers have to reverse engineer the error handling in the dominant browsers of all possible errors.
If instead the HTML spec would have clearly explained what should happen when elements appear in places where they shouldn't appear, this problem would hardly exist. This lesson was learned by the CSS spec writers (they tell exactly how to parse the CSS file, whatever you put in it) and the XML spec writers (they tell to show a big honking error message whenever something is wrong with the file).
If you don't like having choices made for you, you should start making your own. - Neal Stephenson