Mark Pilgrim has asked: Should Apple's new Safari browser have an intentional CSS-parsing bug that Web developers can exploit to hide specific styles from that browser? My answer: I don't know. But, just for fun, here's what that could look like.
/* Begin Safari v1.0 hide */
styles_to_be_hidden {
...
}
/* End Safari v1.0 hide */
It's that simple. Safari would ignore anything between those two comments. As an advocate of Web standards, I don't necessarily approve of such a technique. But here are a few devil's-advocate thoughts on why this should happen:
- A need for this feature is inevitable. As Mark says,
"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...CSS hiding hacks are evil, but the alternatives are worse."
- It's easy to read. Any Web developer would be able to discern the purpose of this code by glancing at the comments.
- It doesn't use any ridiculous combinations of slashes, asterisks and God-knows-what-else. Other CSS hacks, most notably the Box Model Hack, do.
- It validates properly. The style-sheet validator ignores anything within comment marks.
- It should be easy to implement in Safari. It's as easy as trimming anything between those comments.
- It's future-proof. As the Safari developers release new versions, they could upgrade the hack. Hence, something hidden with
/* Begin Safari v1.0 hide */would always be hidden from version 1.0 Safari browsers (obviously) -- but in, say, version 1.2, after the Safari developers have fixed the bugs that encouraged Web developers to use the v1.0 hack in the first place, the new browser would not ignore the 1.0 hack anymore. Instead, it would provide a means for designers to hide code from the new version:/* Begin Safari v1.2 hide */. And so on, and so forth, until all browser bugs have been eliminated..
Comments
Posted by Devon on January 10, 2003, at 6:29 a.m.:
I read Mark's whole spill on the subject and I'm still not understanding one detail. Maybe it slipped by me when I read it... but isn't Safari still just a beta? It seems they're planning to give it good CSS support by market time. So if they fix enough CSS bugs, then who'd want to hide CSS from it? Or, why would anyone want to hide CSS from it? It seems everyone's assuming they won't fix much, while it's still only in testing.
Posted by pete on January 10, 2003, at 1:40 p.m.:
devon: glad to see i'm not the only one wondering the same thing. the way i see it any improvements and fixes apple make to the konqueror engine (khtml ?) will trickle down to konqueror itself. so we get a 2 for 1 deal out of it rather than a browser specific fudge.
adrian: i like the 'dropdown' comments. nice work. javascript and css isn't it?
Posted by Jack on January 10, 2003, at 6:36 p.m.:
Maybe you realized this already, but you didn't mention it specifically in point 6: it also seems fully reasonable that you could nest different versions of the Safari-hiding comments, so if Apple fixes 75% of the bugs in version 1.2 but 25% still exist, the still-existing bugs can be wrapped in a new set of hiding-comments inside the old set, and both versions of Safari should see just what they can handle.
Posted by Jay Small on January 10, 2003, at 9:20 p.m.:
So far, I haven't found a decent standards-compliant page that doesn't paint itself beautifully in Safari, even as a beta. Personally, I'd rather see more reliable CSS hacks to hide things (or provide exclusive alternatives) for Internet Explorer 5 for Mac. That browser has several huge positioning bugs that have swiftly become the bane of my design existence. :-)
I have observed one problem with Safari beta that I can't resolve -- you can't use it to log into a Hotmail account because the Hotmail site seems to sense that Safari is running without Javascript support, though Javascript works on every other site I've tried. So it's either a problem with Safari, or more likely, a problem with some client-detection scheme at Hotmail.
Posted by Brian Hamilton on January 11, 2003, at 3:27 a.m.:
"...until all browser bugs have been eliminated." Ha! I can't wait.
Posted by David Dorward on January 11, 2003, at 1:39 p.m.:
I've been playing around with a new site design and KHTML is my biggest problem at the moment, its got to the stage where I'm considering server side user agent sniffing to provide a different style sheet to Konqueror - despite the problems with that approach. The browser has some problems with background-repeat under certain conditions. I assume that Safari will have the same problems with it.
A screenshot demonstrates the problem, the failure of background-repeat to work causes the links using it to become unreadable.
If anybody knows of a work around, I'd love to hear about it.
Posted by David Dorward on January 15, 2003, at 11:51 a.m.:
Sorted
http://diveintomark.org/safari/csshacks/safari-spacer-hack.html
Posted by Melanie on June 9, 2004, at 6:56 p.m.:
I don't approve of such a technique either but I like what Mark says very much - "CSS hiding hacks are evil, but the alternatives are worse." Great conclusion. We definitely have to analyse the issue from different points of view and to choose the lesser evil.
Posted by anonymous on January 3, 2006, at 7:49 p.m.:
but the alternatives are worse." Great conclusion. We definitely have to analyse the issue from different points of view and to choose the lesser evil.
Post a comment:
Comments have been turned off for this page.