> Alan Gresley wrote: > >> My point is that you do not outline what risk. To say "when there is a >> much less riskier solution available" is repeating a mantra that appears >> in many places. It not based on reality but is more a warning to >> beginners that sending alternative styles to a particular browser is >> risker than sending the same style to all browsers. >
Well, it depends on the "hack." If it's something that would still validate (and though it feels unusual, the * html / *+html "hacks" fit in the "valid" category, as far as I can tell), it's probably not a big deal, unless other browsers that don't need the associated style information start understanding those selectors. As I recall, the * html "hack" was the center of some concern when the IE7 release was imminent, since it initially was going to recognize styles from that selector (even though it didn't necessarily need them). I would say that the more common "risky" hacks include the property-underscore hack for IE6 (e.g. _position: relative;) and any non-standard CSS selectors (such as zoom and filter). And they're risky because they don't validate and thus make it harder to use a validator to help spot actual mistakes in your CSS. Those kinds of "risky hacks" are practices I prefer to avoid at all costs because of the added level of uncertainty they bring to my coding efforts. My weapon of choice is the conditional comment, as it is treated as a regular HTML comment in non-IE browsers, and you can specify (and therefore more easily identify) which versions of IE you want to target. That said, my usual CSS development approach is as follows: 1. Write CSS that's not targeted to any specific browser (aside from -namespaced- properties). 2. Use conditional comments to solve any IE-specific problems. 3. Incorporate what I can back into the "universal" CSS to see if it breaks any other browsers. 4. If the IE stuff breaks any other browsers, put the culprits back in a conditional comment. 5. If I'm short on time and/or have run into something that seems impossible to fix, use a javascript library like Dean Edwards' IE7.js or IE8.js (which you can get at <dean.edwards.name>). 6. If that doesn't work, try to approach the layout from a different direction. 7. Go back to step 1, and following. This process isn't as cumbersome as it sounds, but it's still time-consuming. At some point you may need to follow the path of least resistance, whatever that may be. I choose not to use CSS hacks mostly because it doesn't fit into my workflow. I also have some philosophical issues with the "hack" approach, but nothing I've written is explicitly intended to convince you not to use CSS hacks. (Though I think it's easier not to use them.) Erik Vorhes (*not* Eric Meyer, if that would ever be an issue!) ______________________________________________________________________ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
