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."
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
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
because Safari uses KHTML internally as its rendering engine.
The term "acid test" dates back to the freaking gold rush days when they would use nitric acid to test for gold.
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.
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.
Assembling etherkillers for fun an profit
The "schmoe" in question just happens to be an Apple employee and Safari's lead developer. What a coincidence!
Apple employee David Hyatt fixed Safari to display the Acid2 test as part of his job at Apple as Safari developer. It wasn't "just some schmoe".
What a fool believes, he sees, no wise man has the power to reason away.
It was just some schmoe who put together a patch for Safari.
Yes, the same "schmoe" who happens to be the development lead for the Safari project. Seeing as how he works for Apple, it would most certainly be Apple who did this.
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
Turn off the iTunes actions for audio CD insertion events in System Preferences, load up your favourite Mac audio player and listen to your hearts content. Not exactly rocket science.
Shame they don't stick to it:
g
http://validator.w3.org/check?uri=www.slashdot.or
No Norm, those are your safety glasses; I'll wear my own thanks...
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 programmer in getting the documentation for the cool new features in the latest version of WekKit that's just been released (and described further down in the blog.)
-- Sorry, I can't think of anything funny to say here.
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.
I am no longer wasting my time with slashdot
Not true. I tested this using FF 1.03, Opera 8 beta, and IE (6? don't know it's on my old NT machine). FF and Opera looked about the same, no where close to correct but not complete shit. IE was complete and utter shit. About expected.
I don't get what all the fuss is about -- doesn't everyone with sufficient interest in this issue to read the story know that Apple has been sharing patches (and KDE has been using them) for two years?
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.
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.
I don't know which Opera you use but mine doesn't render the test correctly: http://www.hli.be/media/acid2opera8.PNG
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 is to test browser CSS forward-compatible error parsing rules. If a browser fails to skip these lines it fails the test.
This page states that:
"Acid2 includes a number of illegal CSS statements that should be ignored by a compliant browser."
Please do read the Acid2 page, there are lots of invalid/incorrect codes in the text that shouldn't be parsed by the browsers.
Acid2 page is not supposed to validate because it tests both compliance with how things should be rendered and with what shouldn't be rendered at all.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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
I mean, how did he test the test?
In-Brain Parser. In other words they didn't. In fact there was a bug in the test that Dave Hyatt found by implementing a compliant browser! The ACID2 Test is now at version 1.1 to reflect that bug fix!
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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?
But since you can't build your own version of Safari it's not avaible in Safari.
It's avaible to Konqueror users though, of course, if they can go through applying the patch to the KHTML engine's source and recompile (or they'll just wait for the next Konqueror version that'll implement these patches)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
This code is in the WebCore which is one of Apple's Open Source projects.
Check it out here.
So if the KHTML team wants to put this code in the main khtml tree they can. Since Apple's Open Source License is GPL compatable
Er... Correction WebCore is LGPL so that part about the Apple Open Source license is redundant
Someone else already responded to this critique. The site explicitly says they added bad CSS that a compliant browser should ignore.
-dave
http://millionnumbers.com/ - own the number of your dreams
Acid2 isn't meant to be valid.
CSS parsers are designed to degrade when they come across things they don't recognise; that's what it's testing.
"Elmo knows where you live!" - The Simpsons
Someone else already responded to this critique. The site explicitly says they added bad CSS that a compliant browser should ignore.
-dave
http://millionnumbers.com/ - own the number of your dreams
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.
... you might get goatse.cx
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
Nope, not quite. You can't compile Safari, but you can compile WebKit, which is Safari's rendering engine. Drop in the new WebKit, and Safari has those changes. :)
- oZ
// i am here.
Apple feeds their improvements back to KHTML after the Safari version they appear in is public.
I have a website. It's about Macs.
The patches are in TFA. They apply to kthml, the KDE html engine.
Uh.. if you look at David's most recent post, where he declares success, he posts all the code changes he made. So there you go.
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.
Had you bothered to read the blog, you'd have seen that he already published the patches there:
5 _04.html#008042
http://weblogs.mozillazine.org/hyatt/archives/200
Check out DRM-free movies at http://www.bside.com
Apple feeds their improvements back to KHTML after the Safari version they appear in is public.
Although it doesn't seem to be very useful.
> Will the patches appear in Konqueror (KHTML)?
Zack Rusin just blogged about this.
Also, that thread was from almost a year ago - when Hyatt and the khtml devs where still relatively new to this whole "working together" thing. It's interesting that you didn't have a newer email to link to.
How about a blog from today?
LGPLed actually, but Apple is usually pretty good about contributing stuff back.
Umm, not quite. Pointing towards a link made by someone ealier here:
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.
And you know what? That's their right. They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist. Maybe for Apple - at the very least for their marketing people. Clear?
Don't believe everything Steve Jobs tells you, so to speak.
I remember sigs. Oh, a simpler time!
Apple's Open Source License is not GPL compatible. WebCore is under the LGPL however.
Analogies don't equal equalities, they are merely somewhat analogous.
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
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.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
Yes, exactly. Just like Microsoft hilariously bitched and moaned when AOL stopped letting them into their IM network - Microsoft was the small guy in the IM world, so suddenly IM "standards" were super important. On the flip side when Netscape was dominant, they did whatever they wanted. Hello BLINK.
Apple droids are far worse than even Linux droids - I see that my completely factual, sober post was marked a "troll" by one wanker, in the same way that a bunch of Apple apologists stormed the prior discussion about Apple strong-arming a book publisher. What a sad, sad bunch.