Forgot your password?
The Internet IT

Safari Passes the Acid2 Test 430

Posted by Zonk
from the congratulations-its-a-web-browser! dept.
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."
This discussion has been archived. No new comments can be posted.

Safari Passes the Acid2 Test

Comments Filter:
  • Go Apple! (Score:4, Funny)

    by HeaththeGreat (708430) <> on Thursday April 28, 2005 @11:22AM (#12372249)
    Nice to see some big companies care about standards!
    • Re:Go Apple! (Score:3, Insightful)

      by ergo98 (9391)
      Big companies care about standards when they're the underdog and it suits them.
    • by iamthemoog (410374) on Thursday April 28, 2005 @11:23AM (#12372272) Homepage
      unlike slashdot


    • Re:Go Apple! (Score:2, Insightful)

      by polyp2000 (444682)
      I think that the KHTML team ought to get their fair share of the glory since this is on what safari is based.

      Nick ...
      • Re:Go Apple! (Score:5, Informative)

        by Have Blue (616) on Thursday April 28, 2005 @11:48AM (#12372650) Homepage
        Apple (specifically, Dave Hyatt) did all the work related to this specific subtopic of "browser development". KDE can have the glory for writing a world-class web rendering engine from scratch, but within the scope of this article it's all Hyatt.
        • Yes, but... (Score:4, Insightful)

          by CarpetShark (865376) on Thursday April 28, 2005 @01:00PM (#12373619)

          Konqueror still put in place all of the stuff necessary to make this happen. According to his blog, the he's only been working on this since April 12, but Konqueror has been in development for years. That's what we call standing on the shoulders of giants.

          Also, I'll be interested to see when Dave/Apple get around to contributing this back to the KDE team.

          • Re:Yes, but... (Score:5, Informative)

            by gutter (27465) <> on Thursday April 28, 2005 @01:33PM (#12374007) Homepage
            Had you bothered to read the blog, you'd have seen that he already published the patches there:

   _04.html#008042 []
    • Apple doesn't, Dave Hyatt does.
      And you can see (on his blog) the patch that should be applied to the KHTML engine, which means that KHTML users will soon benefit from these (while the release date of these patches in Safari is unknown, since 1.3 and 2.0 just went live with OS 10.4)
    • The nice thing about standards is there are so many to choose from.

      And if that doesn't make you happy, you can always create some new ones.
    • Re:Go Apple! (Score:4, Insightful)

      by AKAImBatman (238306) * <> on Thursday April 28, 2005 @11:43AM (#12372576) Homepage Journal
      Go Apple!

      Indeed. I still use OS X 10.2, but the differences in Safari between 10.2 and 10.3 are just astounding. Especially in the areas of CSS and DHTML support. KHTML was always a nice little widget, but Apple seems to have some of the best minds I've ever seen working on this. Not even Microsoft got their act togther this fast! (And they started with Spyglass, a component that was superior to the KHTML one that Apple started with.)
  • by mwkaufman (859791) on Thursday April 28, 2005 @11:22AM (#12372253)
    If I pass a test, but don't hand it in, should I still get an A?
  • More to the point (Score:5, Interesting)

    by overshoot (39700) on Thursday April 28, 2005 @11:23AM (#12372261)
    It is unknown when the patches will appear in a public version of Safari."

    Will the patches appear in Konqueror (KHTML)?

    • Yes. KHML is a fully GPLed engine, and Safari is based on that for all HTML rendering. It would be a breach of licence for Apple not to release any fixes, not to mention entirely out of character with Apple's good co-operation so far.
      • LGPLed actually, but Apple is usually pretty good about contributing stuff back.
        • LGPL still compels you to distribute the source with binaries if you modified that which was directly under the LGPL, just not whatever you link it with. This would definitely count as falling under the LGPL. I don't think they'll need arm-twisting though, I imagine he'll be eager to release the patches to KHTML asap.

      • by IamTheRealMike (537420) <> on Thursday April 28, 2005 @12:01PM (#12372844) Homepage
        They can (and do) release the changes as patch dumps which are hard/impossible to merge in without spending lots of time doing so.

        IOW there's a big difference between "not breaking the license" and "working well with outside projects".

        The GCC changes they make are the same. Some aren't rolled back in and whilst the tree is available, documentation on what the patches are and where you can get them are not (and it's a CVS branch so you can't just do a "svn log" and see the individual commits).

    • Re:More to the point (Score:5, Informative)

      by twener (603089) on Thursday April 28, 2005 @02:01PM (#12374366)
      > Will the patches appear in Konqueror (KHTML)?

      Zack Rusin just blogged about this [].
      • by MasterVidBoi (267096) on Thursday April 28, 2005 @04:10PM (#12375903)
        I'm not sure Zack Rusin's response is entirely well thought out. Hyatt links directly to the individual patch files for each of the bugs in KHTML. I've scanned through them, and there isn't much OS X specific at all, except in files that are explicitly platform specific.

        Look at [] as an example.

        In one of the other patches, an APPLE_CHANGES ifdef was actually replaced with entirely cross-platform code.

        The KHTML team would understandably like every change in Safari to be packaged up into a nice little independant patch, but it realistically cannot work that way. I'm sure everyone who has tried to contribute to a project maintained by someone else has had to wait before their patch was (or was not) accepted, and Apple really can't wait on the KTML devs. They have a job that needs to get done by a particular deadline (a deadline that doesn't apply to the KHTML devs).

        The patches posted by Hyatt look really well done to me, and not at all representative of what Rusin is accusing them.
        • by klui (457783)
          Looks like the truth is somewhere in the middle (is this a truism?). I haven't even seen KHTML so the following is speculation.

          Zack described Apple using OS X-specific APIs in the KHTML core--which is unfortunate. I also get the feeling that some of Apple's patches does not work well without help from Apple's proprietary libraries. I know I have sometimes rushed something out by making a fix in an area outside a "core" piece so that if I took the core out, it would break in certain situations. Sometimes, i
  • But will they share? (Score:3, Interesting)

    by Anonymous Coward on Thursday April 28, 2005 @11:23AM (#12372262)
    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?
  • KHTML (Score:4, Informative)

    by Mitchell Mebane (594797) on Thursday April 28, 2005 @11:23AM (#12372266) Homepage Journal
    It looks like he's actually fixing the bugs, and not just adding some lame hack to make it show up right - nice!

    I hope these fixes trickle back down to KHTML soon. In time for KDE 3.5 would be great. ;)
  • when the webcore code is put up then hopefully its in a form which would make it easy to reintigrate back into khtml.
    It will be nice to have standards complient rendering on OS X and linux .
  • Hmmm (Score:5, Interesting)

    by gowen (141411) <> on Thursday April 28, 2005 @11:25AM (#12372290) Homepage Journal
    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 (Score:5, Insightful)

      by hrieke (126185) on Thursday April 28, 2005 @11:34AM (#12372409) Homepage
      We have browsers that can't do standard HTML / CSS because no one writes clean HTML / CSS, and we can't have clean HTML / CSS until we have a browser that supports it correctly.

      This is just a small step forward in that fight, and hopefully it will go forward.
      • by parvenu74 (310712) on Thursday April 28, 2005 @12:34PM (#12373266)
        Saying that a browser should not support full standards because people generally don't write standards compliant code is absurd. Make the browser support the standards and then expose the faulty css/html writers for the hacks they are. Just because someone is too stupid or too lazy to follow the standard is no reason to effectively abandon the standard!
        • by plumby (179557)
          Saying that a browser should not support full standards because people generally don't write standards compliant code is absurd.

          Couple of things

          1) I don't think he was saying that they should not, rather that they do not.

          2)Do you think most people care more about their web browser conforming to standards or displaying most web pages properly? Yes, it would be good for browsers to have an option to provide a "full compliance" mode, but if that mode breaks a website, I suspect most people would just turn

    • Re:Hmmm (Score:5, Informative)

      by vidarlo (134906) <> on Thursday April 28, 2005 @11:35AM (#12372440) Homepage
      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.

      There is where the "quirks mode" [] comes in. The browser should (and is) able to detect whenever something is written after the standard, or not. If it is written in a standard compliant manner, it should be rendered the same everywhere. If it is in quirks mode, it should be rendered different, and the page will behave different.

    • Re:Hmmm (Score:5, Informative)

      by typhoonius (611834) on Thursday April 28, 2005 @11:49AM (#12372661) Homepage

      There's a "tour" of the test [] available that explains exactly what each row is meant to test, and it all looks like pretty fundamental stuff, so I wouldn't write it all off as a "corner case."

      If nothing else, it helped Hyatt corner a number of outright glitches and bugs. I hope the Mozilla and IE7 teams follow his lead.

    • Re:Hmmm (Score:3, Interesting)

      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
  • by James_Duncan8181 (588316) on Thursday April 28, 2005 @11:25AM (#12372294) Homepage
    It should also be noted that all of the fixes done on the Safari KHTML codebase will eventually work their way back to Konqueror proper, meaning that GNU/Linux will benefit directly from this. *smiles* Thanks, Apple.
    • by IamTheRealMike (537420) <> on Thursday April 28, 2005 @12:10PM (#12372959) Homepage
      No, they won't. Why don't you read what the KDE developers themselves found [] before assuming that Apple, a publically traded corporation not exactly known for its humility and openness, is working hand in hand with the original authors?
      • by nether (221468) on Thursday April 28, 2005 @12:44PM (#12373387)
        Eh? Maybe you should read the thread that you linked. Yes, there was initial dismay, but then Apple - in their "humility and openness" - helped the team crack open the tar ball.

        This is the exact same thing that happened way back when - when safari was first unveiled. Apple submitted a large tar, and then helped the KHTML team decifer it.

        Being both a Safari *and* Konq user, this makes me happy.

        Suggestion: know what you link ... you might get
        • Not really, they talked about what changes had been made but the conclusion [] is the same as the initial email laid out. Why don't you read the archives for April 2005 - one of the KDE developers asks about the Acid2 patches and explicitly says "I was afraid you had stopped making incremental patches as we haven't seen any for a long time".

          So there is a bit of co-operation there, or was a while ago, but it seems to be more a case of patches appearing when the Safari team feel sorry for the KDE team. Now go

  • I'm glad to see it many browsers today fall in with the wrong crowd. The media is ruinung their minds; it makes them think that doing drugs like acid is okay. I salute David Hyatt for having the care and concern to watch out for these poor directionless browsers...he's their only hope.

    ...sorry, I couldn't resist.
  • by Letter (634816) on Thursday April 28, 2005 @11:27AM (#12372315)
    Dear Safari Acid Test,

    I'm testing the Safari Acid now...

    Look over there! A pink wildebeest mating with a green giraffe! A blue moongoose mounting a purple elephant! Is that a lion under the zebra? Heavenly stripes galore!


  • Which version of Safari are we talking about? The current release version w/ patches or the Tiger rev that's on its way to me as I post this?
    • Neither, and both.

      The patches are actually to WebKit, which is the actual GUI component that renders the HTML. Both browsers (Safari and Safari RSS) actually use the same rendering component IIRC. As does any other of the zillion of apps on the system that embeds the webkit framework to render HTML.

      Of course, the actual changes are in neither version yet. They're still in the development version. We'll have to wait for some apple updates to see the changes.

      Me? I'm more interested as a programm

  • so does opera (Score:2, Interesting)

    by ExKoopaTroopa (671002)
    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)
  • by Anonymous Coward on Thursday April 28, 2005 @11:33AM (#12372398)
    Enough with the lame LSD comments!

    The term "acid test" dates back to the freaking gold rush days when they would use nitric acid to test for gold.

  • IE (Score:2, Funny)

    You know that MS is hard at work readying Internet Explorer 7 to pass this test... heh.
  • by ssj_195 (827847) on Thursday April 28, 2005 @11:34AM (#12372420)
    ... of the patch was discovered earlier, and is presented here:
    if (url == "")
    print("Hello World!");

  • I was playing with JavaScript the other day and found that on Safari you cannot change the table cell text by setting style.color property (because it does not exist) while it works great on Firefox. Another example is the toFixed() method of numbers. These little inconsistencies drive me nuts every time I try to do anything with JS, especially because there is very little authoritative info on the web about it. I find that 97% of my time trying to do something in JS is occupied researching incompatibiliti
  • JIC anybody is interested FF 1.03 fails the test...

    Might need a few more months, probably 1.1 will fix that action up.

  • Plus he posted the patches to KHTML on his blog, so Konqueror should be passing it too pretty soon.
  • by rainman_bc (735332) on Thursday April 28, 2005 @11:37AM (#12372463)
    I thought WASP was "White Anglo Saxxon Protestant" or "We Are Sexual Perverts", but where the hell is the "A" in "Web Standards Project"?????

    First they should learn how to spell IMO

  • From WASP website (Score:5, Informative)

    by karvind (833059) <karvind@gm a i l . c om> on Thursday April 28, 2005 @11:57AM (#12372754) Journal
    The site has more details and has a list of additional features that are tested

    Transparent PNGs -- The eyes are encoded as transparent PNGs.

    The object element -- The eyes of the face are attached to an object element. Being able to use object (which can have alternative content) is one of the oldest requests from web designers.

    Absolute, relative and fixed positioning -- Being able to position elements accurately is important for advanced page layouts.

    Box model -- The original Acid test focused on the CSS box model. Acid2 continues in this fine tradition by testing 'height', 'width', 'max-width', 'min-width', 'max-height' and 'min-height'.

    CSS tables -- There is nothing wrong with table layouts. It is a powerful layout model which makes sense on bigger screens. However, the table markup is troublesome as it ties the content to these screens. Therefore, being able to specify table layouts in CSS is important.

    Margins -- CSS defines accurate algorithms for how margins around elements should be calculated.

    Generated content -- The ability to add decorations and annotations to Web pages without modifying the markup has long been requested by authors.

    CSS parsing -- Acid2 includes a number of illegal CSS statements that should be ignored by a compliant browser.

    Paint order -- We test that overlapping content is painted in the right order. This is not a feature in itself, but a requirement for other features to work correctly.

    Line heights -- The Acid2 test checks a few key parts of the CSS inline box model, upon which any standards-compliant Web page depends.

    Hovering effects -- One of the elements in the face changes color when you hover over it. Which one?

  • IT section? (Score:3, Insightful)

    by dzurn (62738) <daz-slashdot AT zzzurn DOT com> on Thursday April 28, 2005 @01:03PM (#12373659) Homepage
    So how come this isn't in the /. "Apple" section too?

    Seems kinda relevant, what with kudos and all...
  • by rewinn (647614) on Thursday April 28, 2005 @01:05PM (#12373671) Homepage

    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!

  • by KrisCowboy (776288) on Thursday April 28, 2005 @01:45PM (#12374149) Journal
    I always thought Firefox is the best browser when it came to perfect rendering of CSS. But damn, my browser (Firefox 1.0.1) failed the test. Any idea how I can run Safari on GNU/Linux :-)
    • Konqueror (Score:3, Informative)

      by Pfhorrest (545131)
      Konqueror [] uses the KHTML rendered, which is the basis of OSX's WebCore, which is what Safari uses for its renderer. These updates to Safari (or WebCore really) should eventually make their way back to KHTML and thus Konqueror, which will run on your Linux flavor of choice.

Nondeterminism means never having to say you are wrong.