Surfin' Safari

Front Page  -  Technorati

I have decided to permanently disable comments in my Safari blog. Despite my repeated insistent attempts to explain that my blog is not a bug database, people still come here complaining about every random Web site that doesn't work. When I blog about a topic like "Standards Charts" instead of getting relevant feedback, I get more bug reports. In the real world this would be clearly impolite, somewhat akin to interrupting someone in the middle of a conversation in order to babble about a completely different subject, so what makes you think it's any less rude to do it in my blog comments?

Since most of the useful bug reports I receive are through Trackbacks anyway (and those people usually provide reductions and test cases as well), I'm going to leave them enabled, and I encourage people to report interesting WebCore bugs/problems to me that way.

Finally, I'd like to make yet another plea for my readers to stop bombarding me with email asking why some random Web site doesn't work flawlessly in 1.0. If you actually thought all 10 million Web sites would render flawlessly in 1.0, then you simply had unrealistic expectations.

About the best we can do from release to release is demonstrate forward progress, and I think it's clear that we have accomplished this. Go look at how many bugs have been fixed on diveintomark's Safari list from 74 to 85 for example, or take note of the fact that we've built an entire embedding framework (WebKit) for you to use in your Cocoa applications. Are we moving forward at an insanely fast clip? I think so.

Browsers take years to mature, and I know you'd like it all to be perfect right this instant, but that's simply an impossibility. Have patience. Safari will continue to improve, and it's likely that your particular issue will be addressed somewhere down the line. Also have faith that we know what we're doing. Do we know about the issue where popups sometimes set the default new window size? Of course. Do we know about the multiple animated GIFs pointing to the same URL issue? Yes. Do we know we could have better TITLE support? Yes. Do we know that we need to implement more accessibility features and options? Absolutely.

Can we magically implement all of the thousands of features and requests that we're being bombarded with in a single release? No. Of course not.

Another common question I'm seeing is, "Why is the Safari download bigger than previous betas?" The simple answer is that the WebFoundation framework code merged into the Foundation framework. That means that the 1.0 installer actually has to give you a new version of Foundation.

Safari 1.0 has set the default font to Times 16. For those of you upgrading, this is why text now looks bigger. The old default used to be Lucida Grande 14 (in case you're one of those people who is interested in switching back).

You can read this earlier blog entry for the reasoning behind this decision.

Previous betas of Safari also instituted a minimum font size pref, never allowing fonts to shrink below 9 pixels in size. It turns out that this caused sites to misrender, since sites commonly use small font size spans as spacers. These sites would misrender (quite badly) in Safari, and so the minimum font size restriction was lifted. You can still set this as a hidden preference however.

All of these behaviors (the lack of a minimum font size and the default size/face of 16/Times) now match other browsers (Mac IE, Camino, and Mozilla).

Safari 1.0

Ian Hickson makes a really good point about why percentages should not be used to report results. The connotation "100%" is just as harmful as "Yes" in a way, since it also carries with it the implication that the browser fully supports the feature in question (when all you really know is that it passed all the tests used to evaluate the feature).

A far better solution is what Ian proposes, to simply use some sort of point scoring system. I also like penalizing the score for bugs (as opposed to just missing the implementation all together). This system would be somewhat analogous to standardized tests like the SAT, where you don't get any points off for leaving a question blank, but if you guess wrong, you actually lose points from your overall score. :)

I like it!

I thought I'd put my money where my mouth is and produce an example of the kind of standards reporting I'd like to see. Let's take Ian Hickson's margin collapsing tests as an example.

http://www.hixie.ch/tests/adhoc/css/box/block/margin-collapse/

We have 48 tests here just testing one feature. This is fantastic. Here's an example of a feature that frequently doesn't even show up in standards charts but is essential to proper vertical layout of blocks.

These tests are all extremely well-constructed, in that it's very obvious whether a browser passes or fails a given test. So what we can do is award a browser 1 point for each PASS and no points for failures, and then compute the browser's overall score as a percentage.

Safari's performance on these tests is as follows: 1-6 (PASS), 7-9 (FAIL), 10-45 (PASS), 46 (FAIL), 47-48 (PASS). (Test 36 is discarded, since it is testing an as-yet-unclarified part of the specification.)

So out of 47 possible tests, Safari scores a 43/47, or ~91%.

A developer who sees this score now knows that Safari has excellent margin collapsing support and probably needn't worry about using even complex margin collapsing rules on his site.

This is the kind of reporting I'd love to see, but it involves having a bunch of tests for every feature, and that's the hard part. That's where IMO the W3C working groups (with the aid of browser developers) need to come through for Web site designers.

One final note: I hope I did not offend anyone with my own personal opinion about standards charts. They're about as good as one could reasonably expect them to be without the intervention of the browser developers or W3C working group members, and so it was not my intent to take potshots at anyone in particular. As an interim measure, the charts are obviously providing a useful service.

In my previous blog, I talked about how much I disliked inaccurate standards charts. I would be remiss if I didn't point out the primary reason why people construct these standards charts: that the developers of the various browsers do not typically provide this detailed information themselves.

This leaves Web designers in the unenviable position of having to construct these charts themselves out of tests they write, and it's probably too much for me to expect them to have time to write thousands of CSS and DOM tests. :)

It should be the obligation of the browser developers to provide Web designers with detailed accurate information regarding the capabilities of their engine. That you frequently don't have this information is a failure on our part, not yours.

So what can we, the developers, do to fix this problem? Developers could write their own test suites and then openly publish the results along with detailed notes, but then you just end up with different test suites being created by various browser makers, and of course those test suites would probably show off one particular browser's capabilities. :)

I think the solution is that the W3C needs to take an active role in producing test suites and - most importantly - provide guidelines for proper reporting of results. It bothers me that drafts in the W3C get all the way to recommendation status without concrete test suites that can be used to gauge whether you have two or more interoperable implementations.

(It is worth noting that CSS3 Selectors has a wonderful test suite, and so it is possible to test this one particular area of CSS fairly well. CSS1 had a test suite, but it does not cover all the new features introduced in CSS2. Here's hoping that with CSS2.1 we get a detailed test suite that covers every last feature of the specification.)

Standards charts really really bug me. I won't link to any, since I'm not terribly interested in picking on anyone in particular, but let's take CSS as an example. A typical chart will have entries like so:

                             Browser A       Browser B         Browser C
text-decoration              Yes             No                Buggy

Features are usually listed as rows in the chart. Browsers are listed as columns, so you can find out if browser X supports feature Y by looking at column X and row Y.

What really bothers me about these charts is the range of values they usually allow. Typical values are usually "Yes", "No", "Partial", and "Buggy." These do very little to convey the actual level of browser support.

"Yes" simply means, "Well, in the 3 test cases I happened to try, the browser passed all of them. Therefore it must work flawlessly!"

"No" is about the only value that you can reliably assume is correct. In all probability, a "No" in the chart really does mean the value is not supported at all.

"Partial" means "Well, in the 3 test cases I tried it passed 2 and failed 1."

"Buggy" is often conflated with "partial" and just means something like "Well, in the 3 test cases I tried it passed 1 and failed 2 in some way that really bothered me."

What irritates me about these charts is how inaccurate they frequently end up being. They are inherently biased towards feature breadth and not feature depth, and in the real world feature depth is so much more important.

With these charts, a vendor is even encouraged to do a hack job implementing every CSS property, since the browser engine will then end up looking like it's the best out there. "Haha! I support 59 properties, and you only support 56! I win!" (All vendors are guilty of this too. I'm not singling anyone out here.)

There are plenty of features, for example, where some browsers have absolutely spectacular depth, but this isn't tested at all. All you get from the chart is a "Yes" or a check. We all know that Mozilla's support for the float property (and hundreds of other features) is vastly superior to WinIE's, so why do we persist in applying such sloppy evaluations to browsers? Why do both browsers just get a "Yes"?

It's depth (not breadth) that is going to reveal whether or not a Web design will blow up in your face when you try to use a particular feature. A check in some standards chart just tells you that someone bothered to begin implementing the feature. It doesn't mean that the feature is finished or that it will work when you actually try to build a Web site around it.

In a fit of honesty, I'll even give an example from Safari. Many standards charts have asserted that Safari supports min-width and max-width. How wrong you are. Safari only supports these properties on non-positioned non-replaced elements, but I fooled you, didn't I? I managed to implement just enough to pass the common test cases, because the feature wasn't deeply tested by those of you building your charts. Mozilla's support for this feature is superior to Safari's, but the two browsers have been ending up with the same "score" for min/max-width support.

I would assert that standards charts are meaningless unless they do the following:
(1) Have a minimum of 20 tests per feature that test a variety of settings and (especially for enumerated properties) test the range of values for the property.
(2) Represent support as a percentage, e.g., if the browser passes 10 tests out of 20, it gets a score of 50%.
(3) Make the tests available. It is extremely inconsiderate for chart makers to assert that a browser is buggy at a particular feature without linking to the test in question. In many cases, authors write bad tests, or make invalid assumptions based off the result in a particular browser. Without making the tests available, and specifically explaining in detail why the browser was given a "Partial" or "Buggy", posting the results is unfair.

Web developers deserve accurate results. Only if they're armed with details on each feature will they really know what they can and can't do in a cross-browser setting.

Regarding Safari builds: the public recognized builds are: 48, 51, 60, 73, and 74. Please do not post to my blog telling me information about other builds, or I'll just dump the comments section. While your feedback is much appreciated and more than welcome if you're using one of the public builds, it is not welcome and is really unwanted if you're using some other build.

So... nothing much new to report other than many many bug fixes. Hence the complete lack of updates for a while. :)