Safari Passes the Acid2 Test

TigerX writes "The Mac web browser Safari has become the first browser to pass the Acid2 test. Acid2 is a CSS/HTML test suite put out by the Web Standards Project (WASP). Developer David Hyatt had been working on the project for the past few weeks. Details can be found at his blog. The patched Safari is not yet avaliable for public consumption. It is unknown when the patches will appear in a public version of Safari."

Comments

More to the point

[overshoot]

It is unknown when the patches will appear in a public version of Safari."

Will the patches appear in Konqueror (KHTML)?

Re:More to the point

[jonwil]

Its not Objective-C, its Objective-C++ that isnt yet in the trunk.
And the reason its not there is that (like a bunch of other stuff in the apple branch of the GCC tree) is because those patches have a negative impact on something (e.g. a non-apple target, compile time, compile size etc) that apple doesnt care about but that the GCC core (and the GCC community at large) does care about.

But will they share?

[Anonymous Coward]

So, uh, Safari doesn't actually pass the Acid2 test yet, but it might at some point in the future after they've finished making sure that the proposed fixes don't break anything else?

Well, anyway, good for the dev in question. Will he be contributing his code back to the KHTML project, or are Apple going to try and keep this proprietary?

Hmmm

[gowen]

The patched Safari is not yet avaliable for public consumption. It is unknown when the patches will appear in a public version of Safari.

Hypothetical : Which might mean that fixing the browser to display Acid2 broke something else (related to the browser making reasonable attempts to display broken code, perhaps).

Which does point out the problem with tests like Acid2, which really don't resemble any code in the wild that anyone has ever used. What you end up with is browsers that are brilliant at rendering completely pathological corner cases, but only at the cost of changing some other well-thought-out-but-not-standardised. behaviour.

Now, I admit that this is purely hypothetical, but surely a better guide to browser usability is how well it renders the morass of dodgy XML/HTML that gets sent to it every single day.

Optimise for corner cases, and it possible that all you'll get are really well rendered corner cases.

Re:Hmmm

[Philosinfinity]

I'm not sure I follow your reasoning. Don't get me wrong. I think that pragmatically you are right, but that doesn't mean that it is normatively right.
Basically, I take issue with the idea that instead of building browsers that rigidly conform to standards, thus forcing the coders to code to standard, we allow sloppy code. It is in fact when browsers are built to try and figure out what you are trying to do that coders are given the ability to write sloppy code.
Why then even create standards? Look at SMTP, specifically standards in how emails are formatted. Imagine what would happen if mail servers did not verify things like CR/LF. Imagine if someone coded a program to hit an SMTP server and expected the server to understand HELLO instead of HELO. Imagine having SMTP servers trying to guess at what you were trying to do instead of forcing you to conform to standards. Chaos would ensue.
I understand the example I gave was very simplified and prolly partially inaccurate because of simplification, but the point is there. I am not saying that a browser's ability to understand real world code is not important, but rather that their prima facie obligation should be to conform to standards.
One of the additional questions that is important to ask is, why are so many web designers are coding improperly? Sadly, I think it is the nature of IT. So many people have historically been "home schooled" in web design and computers and that population has leaked into the tech sector in businesses also. There's a big difference between playing around with HTML and fixing mistakes until your page views the way you want it to and understanding HTML. Companies that write browsers need to take significant steps to ensure that the standards are upheld.

so does opera

[ExKoopaTroopa]

I tried this in Opera 8 beta, and it seems to render correctly (FF on the other hand makes a pile of cr*p out of it)

BrowserCam to test pages

[Anonymous Coward]

BrowserCam does a pretty nice job of showing how funky this page can be rendered by several browsers. I had 20 screenshots for different versions of IE, Opera, Firefox, Mozilla, and Konqueror in a relatively short period of time.

Acid test 2 failed on IE version 6.0.2900.2180 sp2

[digitaldc]

Says hello world! and a error on the page.

However, it does have pretty colours and looks a bit psychadelic, so maybe it did pass the acid test after all?

FYI, the original acid test with the Grateful Dead and Ken Kesey

The Fillmore Acid Test Fillmore Auditorium, San Francisco, CA January 8, 1966
1. Stage Chaos/More Power Rap 2. King Bee 3. I'm A Hog For You Baby 4. Caution: Do Not Step On Tracks > 5. Death Don't Have No Mercy 6. Star Spangled Banner / closing remarks

The Sound City Acid Test 363 6th Street, San Francisco, CA January 29, 1966
7. Ken Kesey interviewed by Frank Fey 8. Ken Babbs and harmonica 9. Take Two: Ken Kesey 10. Bull 11. Peggy The Pistol 12. One-way Ticket 13. Bells And Fairies 14. Levitation 15. Trip X 16. The End

Re:Go Apple!

[PHP Addict]

Know what's really funny? The Acid2 test doesn't pass the W3C's CSS validator.

Acid2's Smiley = Excellent Visual Explanation!

[rewinn]

Quite apart from the merits of the Acid2 test, its use of rendering a smiley face both (a) to be the test itself and (b) to show the quality of the test result ... is clever!

Most tests create an abstract "score" such as "85% compliant" which can be rendered by a graphic, such as a pie chart, but which is fundamentally different from the test itself. This abstraction process is extra work both for the researcher and for the reader. There is also the danger that it can be misleading. Edward Tufte has written on this at length in "Visual Explanations" and other books.

To put the test & the results together in a meaningful, intuitive package, as Acid2 seems to have done, is just great!

Shocked and disappointed

[LionMage]

Yeah, I went through the comments on Dave Hyatt's blog and found this link in the comments section (the same link you give above), and I was pretty shocked. Like most folks, I thought that KHTML was benefiting from Apple's contributions. However, after reading the critique by Zack Rusin (one of the KHTML developers), I took a closer look at some of the patches that Dave Hyatt posted links to on his blog.

While many of the patches were simple logic changes, a few of them had OS X specific code in them which makes them non portable. Hyatt's follow-up comments indicate that he tried to hide many of the Mac-isms behind an abstraction layer so that they could port cleanly to other platforms, but a cursory glance at the patches shows that he didn't hide everything.

So while this is a great win for Apple and for Mac OS X, it's not the boon to KHTML that many thought it would be.

Personally, I'm disappointed that the Safari team would put Mac-specific code into the KHTML engine, making some of their patches impossible to incorporate back into the KHTML baseline. This is the kind of thing I would expect from a novice programmer who's only ever coded for, say, Windows.

(Just a side note to the poster I'm responding to: Most folks who read your comment probably didn't realize the significance of it because they didn't follow the link. A brief summary of what the link is pointing to would have been really useful.)