Rick,
The key thing to consider is this:
• Invalid *ML will force browsers into defective behaviour. If your
markup isn't written according to the very clear spec, the browser has
to make assumptions. Different browsers make different assumptions at
different times – you are leaving yourself open to all sorts of trouble.
Don't do it!
• Invalid CSS is written because *perfectly valid CSS*, especially in
ambitious designs, *will cause different browsers to behave in different
ways*. In complete opposite to invalid markup, invalid CSS often has to
be used to secure consistent behaviour accross circumstances.
I regularly use MS proprietary CSS (off-spec and therefore invalid:
zoom, filter, etc.), the comma hack (',' at the end of selectors, feeds
the rules to IE* only, and is considered bad syntax), and various
comment hacks (break rules up with comments to render them as simply bad
syntax to all modern browsers) – to ensure a standardised experience for
as many users as possible.
Of course such effects must be understood before they are used – but in
all likelihood you are only using them because you've seen that things
screw up if you don't. The worst that can happen is an unforseen display
problem, or you getting confused in hindsight as to how everything's
holding together through non-spec CSS. Aside from that and the withering
glare of unemployed standardista mullahs, you have nothing to worry about.
Regards,
Barney
PS: I just read your post regarding the danger of hacks getting fixed.
My answer to this is simple: Whenever a major browser comes out, I have
to recheck all my designs and see what behaviour it exhibits – and deal
with it. Whether I use hacks or not, I'm still going to check and quite
possibly (remember when IE7 hit the streets?) have to fine-tune for it
anyway. In this circumstance hacks are just more code to go through –
although with a fair bit of luck we will work out which hacks apply and
safely be able to ignore the rest. It's not as if any new Microsoft
release leaves puritan non-hackers laughing.
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
