The problem is though, that these browser never actually "go", they
simply evolve a little which doesn't always make the hack redundant,
just altered slightly. Therefore, for me, having the "hacked" styles
alongside the valid css styles makes things infinitely easier to see
what is actually happening.
There certainly isn't a right answer here, but consistency is key.
@imports and conditional comments etc can be useful in terms of absolute
validation, but present problems (especially for very large, complex
projects) where you always have 2+ versions of a style sheet to
maintain, and in real world web projects, there is rarely enough
"thinking" time to fully plan css changes, let alone work out the
nuances of different browsers separately. Hacks are very useful, but
only if the context of the hack is obvious (putting a */_ hack 50 lines
away from the original declaration is of no use to anyone). Its very
easy to maintain, with experience, the targets of the hack are very
obvious, and i find it does a much better job at highlighting the
actually differences between the browsers than separate style sheets
would ever provide. Validation is often a problem, yes, but then no 2
browsers actually obey the CSS2.1 spec in the same way (if at all), so
personally i find trying to obey a spec which isn't adhered to in the
first place is pretty fruitless.
Cheers,
David.
Thierry Koblentz wrote:
I agree on the amount of hacks that should be needed, if you need to serve a
5Kb styles sheet to fix IE then you have a problem...
But don't you think that once these browsers (the ones that rely on these
hacks) are gone, it'll be easier to remove an "@import" directive or a
"link" element than to go through CSS files hunting for "*", "_", ",",
"voice-family", ">", "/*\*//*/", etc.?
Also, regarding maintenance (other authors working on your styles sheets), I
think it'll be easier for many people to maintain browser specific
*hack-free* styles sheets rather than having to learn about CSS "filters" to
be able to maintain those files.
---
Regards,
Thierry | www.TJKDesign.com
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
