Dave Hyatt, one of the developers of Apple’s new Safari web browser, is publicly responding to bug reports, including some of my Safari test cases. This is wonderful. Apple is making lots of friends in the design community by promptly and publicly responding to these early issues.
Problems reportedly resolved in internal builds: now using 96dpi instead of 72dpi, low frame rates in Flash are fixed, and object type="text/html" is now supported. As far as I know, the only site which uses object type="text/html" is the W3C, but they’re important, because they host the CSS Test Suite. I actually already found a workaround and have been browsing through the CSS Test Suite with Safari and found several additional issues. These are all documented on my Safari test cases page.
One issue which Dave Hyatt brought to my attention privately, and which deserves public discussion, is the issue of CSS hiding tricks. There are many known CSS hacks which web designers use to hide CSS from various browsers. This is an evil but widely used (and in my opinion necessary) practice, since all browsers have different sets of features and bugs. (The alternatives are to have HTML-based hacks, which you would need to reproduce on every page, or to use server-side scripting to serve different stylesheets to different browsers, which adds load to the server and is just as complex to maintain.)
You can hide CSS from the public beta of Safari with any of the following hacks:
The problem is that all of these hacks affect other browsers as well; there are no known hacks that only affect Safari. The Inline High Pass Filter hides CSS from IE 5/Win and possibly others. The Simplified Box Model Hack hides CSS from IE 5/Win, Opera 5 on all platforms, Opera 6/Mac, and OmniWeb 4. Fabrice’s Inversion hides CSS from all browsers except Netscape 4.
Dave Hyatt has suggested fixing these bugs
, so that Safari would not be susceptible to any known CSS hiding tricks. I pleaded with him not to do this, and told him the story of OmniWeb, which for years had horrendous CSS support but had no bugs that web designers could exploit to hide CSS from that browser. (The community has since found a way to hide CSS from OmniWeb.) Last I heard, Dave was still on the fence about this; he views them as bugs (which they are), and wants to fix them. The problem is that fixing them may do more harm than good in the long run, by reducing options for web designers and forcing us back to the days of maintaining multiple browser-specific stylesheets.
I am wondering if we shouldn’t go to the opposite extreme. What if the Safari developers developed a way for web designers to hide CSS only from Safari: a specific valid but rare syntax that it intentionally did not understand. Or a way to hide CSS from every browser except Safari: a specific invalid CSS syntax that it did understand. I am aware that this is inherently evil, but consider the situation: Safari will presumably become the default browser on Mac OS X at some indeterminate point in the future, so lots of people will use it. And it is already known to have a different set of bugs and features than any other browser. Even if all known bugs are resolved in this current beta testing period, others will inevitably be found. CSS hiding hacks are evil, but the alternatives are worse.
If the community decided this was a good idea, and we could convince the Safari team to implement it, what would such a hack look like?
Suggestions so far:
Scott Reynen suggests using fake selectors like onlysafari body {display: none;}.
Adrian Holovaty suggests a comment hack, like /* begin_safari_hide 1.0 */ body {display: none;} /* end_safari_hide 1.0 */.
Aaron Swartz thinks Safari should define its own media type (like khtmlhack) so designers could define styles (or entire stylesheets) with Safari-specific overrides.
Chris Adams suggests using Java-style references for namespaces with a requires-fix element. Now that’s out there.
Anyone think it’s just a wretched idea in any form?
codepoetry thinks it’s just a wretched idea in any form. So does Daniel Berlinger. And Scott Hanson.
Alastair Campbell thinks Safari should pick a browser and try to match it bug-for-bug.
Dave Hyatt is open to the idea, if a suitable solution can be found. Later: he has proposed a solution.
Kevin Smith has an analysis of the solutions suggested so far.
Update: In the last few hours, I’ve discovered at least a dozen parsing bugs that cause Safari to improperly apply (or improperly ignore) CSS. No word yet on which other browsers are also susceptible to these bugs. But at least we have choices.
