Slashdot Mirror
Konqueror Passes the Acid2 Test Too
An anonymous reader writes "A month after Safari , and after a lot of controversy, Allan Sandfeld Jensen announced today that Konqueror passes the Acid2 test too. Half of the patches could be merged from Apple's Webcore, the rest needed to be rewritten from scratch."
http://www.webstandards.org/act/acid2/
basically it's a rigorous test that ensures that a browser has all the goodies that web developers have been lusting after forever.
This has been featured on Slashdot before. The Acid 2 test is a web browser standards compliancy test, and it applies to all web browsers not just Konqueror and Safari. These are just the first two that can pass the test. The others will hopefully follow later.
Take the Acid 2 Test.
I'll probably be modded down for this...
Acid2 is a test page, written to help browser vendors ensure proper support for web standards in their products.
Recently, one of the Safari developers announced that Safari (the HTML parsing part of which is Webcore, which is derived from KDE's KHTML component) now passed the Acid 2 test. This led to a lot of comment, on Slashdot and elsewhere, asking when Konqueror (KDE's web browser) would pass Acid 2. This led to a post by a KDE developer saying that Webcore and KHTML had diverged significantly, and this is turn led to a lot of badly informed comment (mostly on Slashdot), slagging of KDE, Apple, or both.
Happily KDE and Apple seem to be working relatively well together, and this current announcement indicates that the KHTML developers have worked through all Apple's Webcore patches related to Acid 2, using the ones they can, and rewriting the ones they can't. Konqueror now becomes the second mainstream browser to pass the Acid 2 test.
-- Help Digitise the Public Domain at DP.
As Hyatt's blog post noted, the Acid2 code is not yet in a released version of Safari. You can either (a) patch and recompile WebKit/WebCore yourself or (b) wait for the next update of Safari, which Apple and Hyatt have said will be Real Soon Now.
So, then I presume you can point out each and every aspect of Acid2 that violates CSS 2.1.
We'll also expect you to hold your breath doing this excercise on a live webcam, so we can see you turn blue in the face.
The acid2 test consists of perfectly valid CSS2.1, HTML 4.01, SGML, RFC 2396 and RFC 2397. It tests some basic, and some not-so-basic aspects of these specs.
http://virtuelvis.com/
Actually, rather than testin gfor full CSS compatibality, the ACID test makes sure that when broken CSS is put into a CSS document, it breaks correctly.
Downmix - The Artscene News Source!
Gecko (the engine used in Firefox and Mozilla) probably won't be passing it too soon. See Robert O'Callahan's blog entry here. This means Firefox 1.1 won't pass Acid2.
My server
The HTML validates, sure.
But the CSS doesn't.
Self-referential sigs do not a humourous poster make.
This is incorrect.
The W3C implemented a change in procedure between the times CSS 2.0 and CSS 2.1 were published. What used to be called recommendations are now only candidate recommendations until they are widely implemented.
Ian Hickson, who is on the CSS working group and employed by Opera, says this:
It does both. I've seen this misconception stated a few times now, it's just wrong.
The Acid test is not just a test for error handling. Error handling is something that is defined by the CSS 2.1 specification (and earlier specifications). In order to test full CSS compliance, they need to include errors as part of the test. This does not mean that all the test does is error handling, merely that it is one of the things the test does.
LOL. The test is supposed to be broken. It's checking that renderers fall back correctly.
In a word, yes. The version of Webcore that renders Acid2 correctly, is not in the released versions of Safari yet. It'll probably come as an update sometime in the next year or so.
"Your effort to remain what you are is what limits you."
The developer in question was not mad at Apple per say, they were doing what was required. He was mad at people thinking Apple was doing something useful for KDE/khtml. Apple was not making things useful for KDE, but they were fullfilling all their obligations.
Once he spoke against those non-Apple, non-KDE people, those people tried to deflect the blame to Apple. Apple to their credit realized how the publicity was hurting them and changed their ways.
Once again, the KDE devs were not mad at Apple. They were disgusted because of being unable to get something useful, but not mad. They were mad at people who thought without checking that Apple was doing something useful.
When Konqueror doesn't follow Safari's new feature within 4 hours, don't blame us. When Konqueror finally follows Safari's feature list, don't automatically praise Apple, either.
It's not like Apple is giving out some drop-in patch, but that's OK. That's their right. Sometimes we take their patch, but sometimes we write things from scratch. When we'll use Apple's code, we'll be slow because of the way they produce their patch, not because we're lazy.
Apple is OK for me, but please stop bashing our laziness while praising opensource-friendliness of Apple. That hurts.
All this stuff about "Apple did this and the khtml guys did that" is utterly irrelavent to the point I and the khtml devs were trying to make.
The khtml devs beef is with fanbois who think that khtml should have new Webcore features an hour or two after Webcore gets them. When the khtml people try to explain why matters are bit more difficult than that then the fanbois throw around terms like "lazy", "unresponsive", and "kick in the pants".
Apple's behaivor has zero to do with the point I was trying to make.
That's not apparent at all. You're simply showing that you don't read the kde dev's blogs and hope people reading this won't bother either and just take your word for it.
What? How do you know how hard these people have been working over the last two months? You really sound like a manager type to me. These people mostly do this work in their spare time. They have real jobs too. They don't work on this 9-5. Saying "it only took a team of x y months to do it" is completely meaningless.
Hahaha.
Read that sentence again and tell me it's not the absolute definition of an apologist talking.
And nobody has ever said that it does. Only people like you trying to craft strawman attacks have ever brought this up. The grandparent doesn't say this, the KDE devs don't say this.
First of all: hahaha
Second of all: if they are getting kicked in the teeth, it's not the kde devs doing the kicking. The original blog post was aimed at clueless fanboy posters posting things.. not unlike what you've just posted. NOT at Apple. This one blog post was then blown out of all proportion by slashdot and people making strawman statements to try and spread their propoganda.
Ironic, no?
Malike Bamiyi wanted my assistance.
Quite a bit of the comments in Webcore say things like "This change addresses issue xqb967." or some such. Basically, Apple's changes to khtml don't make much sense outside of Apple's source control system. You cannot simply drop such into another project. By the time you reason out whatever xqb967 is, you may as well have redeveloped the code yourself.
None of this is utterly terrible. Webcore can be used in isolation. khtml can be used in isolation. Adding beneficial features from Webcore isn't trivial. A good bit of the time, it is actually simpler to redevelop the features. The khtml devs aren't complaining (much) about this.
They ARE complaining about being hammered by clueless fanbois whenever Webcore has a feature that khtml lacks. Webcore is a two year old fork of khtml that isn't well documented outside of it's parent source control system. This is what is meant by "bare minimum". This "bare minimum" situation is tolerable. Take it as read I repeated the previous sentence 10,000 times in addition to the other emphasis. This has far more to do bad end-user behavior than Apple. This bad end-user behavior is caused by a perception of co-operation that never existed.
It is the behavior of a vocal contingent of end-users that is intolerable. Apple's behavior merely rankles slightly compared to that of the fanbois. Sometimes the khtml guys can make limited use of Webcore code. As time passes this will be even less possible than the current breakthrough.
The khtml devs do not deserve abuse for feature disparity vis-a-vis Webcore. This is the point I'm making. Apple's behavior is nearly irrelavent and only constitutes cause for irritation at most.