Slashdot Mirror
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!"."
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.
Remember that http://my.opera.com/desktopteam/blog/show.dml/1723 75the weekly which passes Acid2 has been released publicly :)
FTA:
... overflow: hidden; /* hides scrollbars on viewport, see 11.1.1:3 */ ... }"
"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 {
"Max, come over here. French-Canadian bean soup. I want to pay. Let them leave me alone." - Dutch Schultz
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).
If you have RTA, you would know that Konqueror claims to pass, however it fails to aply a final style-sheet.
No, that's wrong. Even if it isn't that important who did it first, but that it gets done at all, the facts should be right.
Safari did it first, then iCab, then Konqueror, and now Opera. See http://dean.edwards.name/weblog/2005/04/acid2-sp/ . This order is not the "release" order, but when an alpha/beta/nightly passed the test, and the developer(s) told us.
If we consider released versions, I'm not sure what order we get, but I believe only Safari and Konqueror have released the compliant versions yet.
For example? Please keep in mind the article is referring to Opera 9.0 Preview 2 (latest snapshop, according to here), which Opera notifies against the use of previews.
preview- of an experimental nature
- distributed to a limited audience, i.e. forums, newsgroups, and IRC
- should never be installed over a final release
- not to be used as a substitute for a final release
beta- available for all users, but recommended only for advanced users
- thoroughly tested, though known to contain bugs
- usually feature-complete
- data backup is highly recommended before use
finalAccording to WaSP (the people who wrote the Acid2 test), Safari passed first, followed by iCab and Konqueror. and Safari was the first browser to have a public release that rendered it.
That makes Opera the 4th browser to render Acid2 correctly.
This page has a bit of info on it, http://dean.edwards.name/weblog/2005/04/acid2-sp/
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..."
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...
Live today, because you never know what tomorrow brings
What would be really really nice is if the target browser for real world applications could even get close to passing a standard test. For many years now we've been forced to put the cart before the horse to support IE due to it's dominance on the desktop. Personally I've spent an additional 40 hours in just the last two months hacking around IEs lack of CSS2 support for web projects I've worked on.
Seriously these layouts worked perfectly in Safari, Firefox, Opera the first time around... just based on standards... then I started looking at IE and realized, oh crap! I had to jump through hoop after hoop and ended up having to compromise the design mulitple times which irked my Creative directory to no end (as I'd said "no problem, this design can be done in html + css).
A fool throws a stone into a well and a thousand sages can not remove it.
Provide a link to the image, or people here won't understand your subtle sarcasm. :)
Take the ACID2 test...
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/
Their JS code contains this:
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.
Happy to help! Firefox 1.5 is nearer to Opera 8 than Opera 7.5: the background is yellow (good), the eyes aren't quite right (bad, comparable to Opera 8) and the mouth has turned into a cigar (bad, Opera 8 does this better).
Sorry, best I can do without getting off my backside and doing something useful with screenshots. And I'm not going to get off my backside on a Sunday.
This is where the serious fun begins.
http://www.webdevout.net/browser_support_dom.php#s upport-domevents-mutationevent
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 (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 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.
Beware: In C++, your friends can see your privates!
It's supposed to be blue when the mouse pointer is hovered over it. We don't know the location of the mouse pointer in the Opera screenshot.
It's the :hover event. If you hover the nose with the mouse, the nose turns blue.
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.
How about a little maturity?
a) No it doesn't, many Internet Explorer memory leaks 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.
Bogtha Bogtha Bogtha
DOM Level 1 Core states that "The DOM presents documents as a hierarchy of Node objects". As IE/Win is capable of creating a node with two parents and creating a node whose parent is the child of one of its siblings - that is, a non-hierarchical structure - it can hardly be claimed that it has anything to teach anybody in this area.
(I'm aware that these effects are caused by invalid markup, and that other browsers also have problems agreeing on what to do; but the simple fact is that the DOM is defined as a tree, and IE/Win internally uses a data structure which is not a tree. So it's difficult to see how its DOM implementation can ever work properly.)
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
The nose changes color when you mouseover it. Even in the mess that is Firefox's rendering of the page hovering your mouse over the face causes the nose to change colour from black to blue.
I guess that's something they really should specify in the reference diagram, but it's still a pass for Opera 9.
Since you don't know how to google, you can download the source like this:n k WebKit
svn checkout svn://anonsvn.opensource.apple.com/svn/webkit/tru
you can also grab the latest nightly build of Safari here: http://nightly.webkit.org/
(look at the icon and download it if you don't believe me)
http://webkit.opendarwin.org/ has more info.
The war with islam is a war on the beast
The war on terror is a war for peace
30-40%? Hahahaha, yeah ok buddy.
_ engines_(DOM)
http://en.wikipedia.org/wiki/Comparison_of_layout
Had... yes.. back before 7.x.
Now it's javascript and CSS support are superb. Opera and FF are about equal in those departments.
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).
That would certainly explain it, if it's true - it's all very well testing whether the browser supports the feature rather than what browser it is, but that breaks down if web browsers pretend to support things they don't.
It depends on the standard. I'm not an expert at CSS, but from what I understand it's particularly difficult to implement because it specifies not just what the UA should do for valid CSS but also exactly how it should handle certain classes of invalid CSS as well. So even if your browser were able to correctly render every correct web site, it would still fail the ACID2 test if it didn't handle certain /incorrect/ sites "correctly" as well.
/anything/ about behavior on failure. As a result, every browser does something slightly different when it encounters a web site that breaks the rules. And the problem is that so many sites do in fact break the rules. Not only that, but quite a few sites rely on a browser rendering certain rule-breakings a certain way! So, for example with IE, MSFT has a huge incentive not just to make the browser more compliant but also to make sure that it is behavior-compatible (sometimes even bug-compatible) with previous versions of IE. And THAT is a tall order!
The HTML spec is a different beast, though. It pretty much has the opposite problem: It doesn't specify
It's always a long day... 86400 doesn't fit into a short.
But it is: The mouse cursor is on top of the container with the hover pseudo-class (start the test yourself to see that it triggers the hover effect on the whole "box" not just the nose).
> It has absolutely nothing to do with testing broken css rendering at all.
h ttp%3A%2F%2Fwww.webstandards.org%2Fact%2Facid2%2Ft est.html%23top&usermedium=all
From the ACID2 site: "Note: some 827 people (rough estimate, contents may have settled during shipping) have written to point out that the CSS used in the test is invalid. This is deliberate, as a means of exposing the ability of user agents to handle invalid CSS properly."
Sorry, handling broken CSS properly is not using the stylesheet. Anything else is gravy.
Anyway, try the CSS validator yourself. ACID2 ain't valid CSS:
http://jigsaw.w3.org/css-validator/validator?uri=
My other car is first.
I just came form the CeBit, where dozens of proud Microsoft representants were showing Windwows Vista, Office 2007 and of course the IE 7 ("We've got these 'tabs' now!" - yes, they said that).
I convinced one of them to open the ACID2 test in the IE7 (Google was blocked and he told me to use MSN Search, but I fired up Seekport). It was the worst rendering of the ACID2 I've ever seen. The entire screen was red, except for a few lines and dots here and there, and scrollbar in the nothing way over to the right.
Of course, the Microsoftie was quick to say, it's all only beta...
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 errorsDepends 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 "<" for < and ">" for >. If you want to type "&", you type "&" 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.
Warning: Opinions known to be heavily biased.
Once we include the fact that the CSS standard explicitly includes specs for handling invalid CSS we're on to something... Yes the CSS is invalid, but the w3c states how to handle it in those cases, displaying anything else is not according to spec.
http://www.w3.org/TR/CSS21/syndata.html#parsing-er rors
Since a lot of people point to the fact that the Acid2 test contains invalid CSS I thought I'd point out that this was in fact intentional.
The reason why is described in the above link, CSS defines how a browser is supposed to behave when it finds invalid CSS.
Testing whether a piece of software behaves correctly when presented valid data is only half of bug-testing.
The other half is testing whether a piece of software behaves correctly when presented invalid data.
Acid2 covers both halves.
CSS is supposed to fail more gracefully than XML and XHTML and ignore only those parts that are incorrect.
On OSX 10.4.5, other than the scrollbars, iCab 3.0.2(Beta382) looks identical to Safari. I much prefer iCab showing the scrollbars rather than letting the webpage hide part of itself. I suppose iCab could make itself technically ACID2 compliant by having a "don't allow scrollbar hiding" checkbox in the preferences, which I could then leave checked.
Doesn't look like Safari has the ability tho show the scrollbar if you want it, but you can scroll it by clicking on the page and dragging up or down.
I don't like it when web pages can hide stuff.
Anybody have a screenshot of IE on Acid2?
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.
Apple maintains their own fork of webkit. Code is often contributed back to the KDE team, but is often not directly usable by them, as the Apple fork is significantly different in places. At least that was the situation a couple months back.
They don't maintain their own fork of WebKit, WebKit *IS* the fork. KDE doesn't use WebKit, they use KHTML and KJS, from which WebKit was derived.
fuck you.