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 */
/* 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..