Last month I babbled about Acid2, created a test. Today, it’s here! (Thanks Henrik.)
It seems the people at WaSP have not realized it themselves as it has not been published on their weblog. However, the test looks pretty cool. They have also written a detailed guide on how it exactly is supposed to work. (They assume support for CSS2.1 as well by the way.)
I haven’t taken the time to debug it all. It seems to be fairly complex and purely theoretical. I wonder which browser will render it correctly as first. I also wonder if the test case is without any mistakes. It might just happen that someone has drawn incorrect conclusions out of some phrase in the specification and the expected rendering should be different.
For example, if you view source you see they applied overflow:hidden to the HTML element and expect that to hide the scrollbars from the viewport. However, although CSS2.1 states that user agents may apply that to the viewport (for HTML documents at the moment), they are not required to do so. And that is just the first line ;-)
Heh, better get some Firefox geniuses at work now. One dream: work in all browsers, be it in one year, be it in two.
Some of us blogged about this a few days ago ;-) Anyway - screenshots for just about everything but IE/Mac can be found on between my blog (Konquerer 3.4, Safari 1.2), David Naylor's (IE6, Opera 7.54, Opera 8 beta, Firefox 1.02, Firefox 1.0+, Netscape 6.1) and on The SeBlog (Linx/Lynx, IE5.01, IE5.5 + some of those on mine and David's sites)
It'll be interesting how the IE team react to the test...
Doug, thanks for the screen shots and sorry for not reading your weblog.
I wonder: is there one browser yet that can display this test correctly TODAY?? Not one of mine here...
I wonder: is there one browser yet that can display this test correctly TODAY?? Not one of mine here...
As far as I know, no UAs have successfully managed to render the test.
I'm not completely satisfied with the test. For one, I don't see why it has to rely on URL data schemes. When do we really use them in practice?
I also thought the test would be much more comprehensive.
But I guess it isn't a bad thing that todays UAs fail to render it -- it just shows that there are still some glitches in their CSS2.1-implentation.
I'm not completely satisfied with the test. For one, I don't see why it has to rely on URL data schemes. When do we really use them in practice?
Well, in the guide for the test they give an example: for small (custom) bullet images.
Well, in the guide for the test they give an example: for small (custom) bullet images.
Applying a background-image to an element is a much better way to display a custom bullet than using URL data schemes, don't you agree?
Applying a background-image to an element is a much better way to display a custom bullet than using URL data schemes, don't you agree?
Well, that's pretty much what they're doing. They're taking data encoded as text withing the CSS and feeding it directly to background-image, except that they're using the background shorthand.
To be honest, this strikes me as questionable. Does anyone actually encode image data directly into their CSS? This strikes me as something with no practical use in the real world. Off the top of my head, for instance, I'd have no idea how to encode a PNG into text and put it in my CSS file. I suppose I could figure it out if you gave me enough time, but WHY?!!
Note about Firefox: Apparently, the <address> inside the <blockquote> (for Row 2 of the test)is floating right with respect to some parent of <blockquote> rather than <blockquote> itself. Is there a bug filed on this?
Mathew: there is a tracking bug: bug 289480. That one problem is already filed.
That use of data url for that background image is a bit over the top. On the other side, interesting use of the <object> tag. I haven't seen yet what the upcoming Safari 2.0 does, but based on reports, it fails like everybody; not much, but fails. Should I bet on Safari 2.01 being the first one to... ?
To be honest, this strikes me as questionable. Does anyone actually encode image data directly into their CSS?
Well, maybe no-one is using it because it doesn't have full support in the main browsers? I would probably use it if it worked properly. Seems like a nifty idea to me.
Data URL is actually very nice. It saves your a few (or a dozen) of roundtrips if you use many small image files in the CSS. There is a website to convert file to data URL, so you don't have to know how to encode the files.
More screenshots here.
Should the test really use CSS Candidate Recommendation values as the testing yardstick though? I know it's supposed to cover the features that web designers have been requesting though some of the values aren't set in stone yet so its highly likely things like color: orange is flaky.
Robert - CSS2.1(CR) is equal in status to CSS2.0(REC). As Hixie puts it:
(Note that CSS2.1 and CSS2 are at the same state in the W3C process — they are both at the "call for implementations" stage. The difference is that the name of that stage changed between 1998 and 2004. What used to be called "REC" or "Recommendation" is now called "CR" or "Candidate Recommendation". The new stage currently called "Recommendation", which indicates that the specification has reached a very high level of implementation maturity, didn't exist back in 1998.)
Yes, I probably just needed that clarifying though it does lead to some interesting scenarios.
This is great news!
Dave Hyatt is already working on making Safari pass. I sure would like Gecko to take the crown, but I bet KHTML will be the first to render Acid2 correctly.
Even though I have a couple gripes, I am unhappy about the SGML comments and I agree the data URLs were uncalled for, it is good to have a high-profile test for functionality that is too rarely tested. Most CSS tests focus on features and very few focus on interoperability.
I wonder if anyone sees the same thing a me on this Opera 7.54u2 screenshot.
This is what I see at home (Opera 7.54u2 [registered] on Windows XP Pro SP2 French) but on several other sites I have seen screenshots labelled Opera 7.54 where the eyes aren't present.
Ain't that weird? What am I missing?
ghola: The eyes aren't there initially (at least on my system). They only appear when you move the cursor around.
David: You're right, thanks.
The behaviour is however very sensitive. Actually the loading holds at 270 bytes (at what point the eyes aren't displayed), until I move the mouse, which triggers not only the loading of the rest of the file, but causes the eyes to appear.
Also, once the test has been (fully) loaded, I don't have to wait anymore, and the test is displayed in its final form without any mouse move. That's why I wonder how those screen captures were taken. I had to keep totally still and use only the keyboard to capture the same eyeless screenshot.
I wish people could see the eyes because I haven't seen them displayed in any other browser. Maybe the same thing happens in Safari or others in Mac. Firefox 1.0.2 on my machine never displays the eyes.
Does anyone have an explanation as to why mouse movement might have an effect on the rendering?
…
I'd have no idea how to encode a PNG into text and put it in my CSS file. I suppose I could figure it out if you gave me enough time, but WHY?!!
You could use background images on links without the privacy concerns. Maybe.
