Slashdot Mirror
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."
Nice to see some big companies care about standards!
If I pass a test, but don't hand it in, should I still get an A?
Will the patches appear in Konqueror (KHTML)?
Lacking <sarcasm> tags,
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?
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.
The roots of education are bitter, but the fruit is sweet.
--Aristotle
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.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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.
"To any truly impartial person, it would be obvious that I am right."
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!
Trippy,
Letter
No, the test was designed to use code that many developers would use and many would use incorrectly. There are details on how a browser should handle bad code - and most fall short of the standards. That's one of the reasons why you have browser "hacks" and why many developers end up with bad habits.
In other words, don't be so forgiving with bad code. It hurts the world of web development when bad code becomes a de facto "standard."
Since Safari has nothing to do with Firefox, Mozilla, or the Gecko HTML engine, being instead based upon the KHTML engine from KDE, I would say "When can we expect the code to flow out and make Firefox/Mozilla pass the Acid2 test? Never."
www.eFax.com are spammers
From the Acid2 site:
Acid2 is a test page for web browsers published by The Web Standards Project (WaSP). It has been written to help browser vendors make sure their products correctly support features that web designers would like to use. These features are part of existing standards but haven't been interoperably supported by major browsers. Acid2 tries to change this by challenging browsers to render Acid2 correctly before shipping.
Acid2 is a complex web page. It uses features that are not in common use yet, because of lack of support, and it crams many tests into one page. The aim has been to make it simple for developers and users to check if a browser passes the test. If it does, the smiley face on the left will appear. If something is wrong, the face will be distorted and/or shown partly in red.
The purpose of this document is to explain how Acid2 works. The markup behind Acid2 is peculiar in that it attempts, on one single page, to test many different features. We do not envision or recommend that normal Web pages should be written this way, but it is appropriate for a test page. At first sight, the source code is hard to understand, but the guided tour offered in this document will explain it in some detail. The guide assumes a technical understanding of HTML, CSS and PNG.
The test was designed to check the browser implementations of the newer CSS standards. ,all-be-it and extremly complex example of which made to test the browsers and how well they implement the standard. ,khtml being the thing on which webcore is based)
Basicaly the point being not in obscure code , but in rendering normal code properly
Web designers/developers will use the code when it is avaliable in their arsenal.
As of now , the newest version of webcore is the only rendering engine that can do it so congratulations to apple(and ofcourse the khtml team
The only things certain in war are Propaganda and Death. You can never be sure which is which though
Now if only it would play a CD without forcing me to enter a contractual relationship with iTunes (which I am not interested in doing) I'd be less disappointed in it.
You're aware you had to enter into a similar contract to like...boot the Mac? Remember that thing you clicked through right before it asked for your name? You know, with the bouncing blue thing?
The term "acid test" dates back to the freaking gold rush days when they would use nitric acid to test for gold.
" So... the test was designed to see if a browser can use some weird code that most web designers would never use, and could (in this case) easily be done with an image tag? I don't see the point."
The problem is that you might want to use them, but you can't, since only 3/5 major browsers support the option. Also, it's easy to say you are up to the standars, another thing to actually be.
I'm a user of CSS, but I still have to check all kinds of browsers to see if it does what I want, which is taking time and time is money.
To just solve this example with including an image would of course be suitable, but how about a whole site? Text is so much more practical, just by being able to copy it. The webpage would eat up much more memory dealing with images too.
We have the same problem with javascript, only that is 10 times more disturbing because if javascript was actually the same all other the place web surfing could be enhanced so much. The only reason people don't like javascript is because the popups, and that's not everything in javascript.
Acid2 is a friggin good one, perhaps people will get up their eyes for it and see for themselfs, I just hope the same goes on for javascript and html too...
Albert "thec" Sandberg
Change the entry "when you insert a music CD open iTunes" to your favourite app. Bob's your uncle.
Good luck finding something better than itunes by the way.
Mother is the best bet and don't let Satan draw you too fast.
Just do it. Everyone else is.
It'll make you feel better.
I don't know which Opera you use but mine doesn't render the test correctly: http://www.hli.be/media/acid2opera8.PNG
General misuses and abuses of JS is, and in this general abuses are:
- Popups, of course
- Stupid effects (shitty animated gifs following cursors anyone?)
- Messing with browsers (resizing, changing parts of the global UI, alert boxes)
- Code design so bad that browsers grind to a halt (oh, i so love seing my CPU usage skyrocket to 100% and stay there because i opened a bugged page)
- Slowing the browsing
- Disabling the browsing altogether because of non standard or stupid scripts (mmm, yummy Javascript links, I mean anchor tags are certainly not hip enough for a damn link are they?)
- Probably many other i can't think of right now
"Modern" javascript and the usage of DOM scripting allow wonderful flexibility, and applying the priciples of graceful degradation and progressive enhancement while fully decoupling Javascript from HTML/CSS (by putting JS in a separate file and associating it via the Event Handlers, layering a behavioural javascript on top of an existing fully functionnal JS-less website) allows improving every JS-enabled's navigation while not degrading at all JS-disabled's navigation.As Douglas Crockford put it, Javascript is the most misunderstood programming language, and I'd add that it's the one with the most extensive yet qualitatively (sp, more than likely) worst documentation ever.
And yet, finding good javascript tutorials and stunning Javascript reference websites is possible. People just don't bother looking for them...
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Yes, part of Acid2 is about testing whether browsers handle invalid CSS according to the standards.
What a fool believes, he sees, no wise man has the power to reason away.
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?
This page states that:
"Acid2 includes a number of illegal CSS statements that should be ignored by a compliant browser."
It won't, Mozilla devs are far behind schedule and have quite a lot of important bugs to fix with Gecko 1.8 (rendering engine for Firefox 1.1).
Sadly, Acid2 won't be high priority before Gecko 1.9, which means that firefox won't be fully CSS2 compliant before at least version 1.2.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
A lot of their changes make no sense to merge. They do lots of things to ahve the compiler fit with their development and library model, which is quite a bit different from how everyone else does things.
And some Apple patches, especially with regards to Objective-C, have made their way into GCC. Maybe they could be doing more, but they're allready doing more than many corperations of their stature.
Slashdot. It's Not For Common Sense
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!
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.
So what, "Here's our source tree" is obfuscation? That's a pretty extreme position to take.
I suspect it's more of a cultural clash. To someone being paid, being told to take the patches from the source tree is a minor irritant at best. For a volunteer, any extra effort streches allready scarce donated time.
Slashdot. It's Not For Common Sense
So how come this isn't in the /. "Apple" section too?
Seems kinda relevant, what with kudos and all...
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!
--- Attorneys Assisting Citizen-Soldiers & Families -
Except this is a patch to WebCore, which you CAN build, which Safari will then use.
I don't know what kind of crack I was on, but I suspect it was decaf.
From his latest blog entry:
"Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn't have any history? That's the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL."
Go read the whole post. Very informative, and kind of sad.
The roots of education are bitter, but the fruit is sweet.
--Aristotle
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.)