What are those "intentional" exceptions anyway?

This is a follow up to my blog entry. You can read the logic behind my intentional deviation from some standards in more detail there.

I don't say that I write bogus code with inline css, font tags, deprecated elements and attribute and spread tables all over for pixel perfect positioning.

I just say "Don't let a machine do a man's job".

I mean of course go validate your markup. It is the first step in creating a coherent and accessible web site.

However, don't build a blind faith upon the Validator:
Don't simply validate your markup to show off the badge of honor(s) at the bottom of your page. That's simply because, the W3C Validator cannot decide, it cannot judge between apropriate and inapropriate.

To take it another way; if you know what you are doing and why you are doing so; if you can provide a sound argument to your decision then there is nothing wrong in a markup that is left intentionally invalid.

It's because, in that case, you have a complete control over your code. However you should be really really careful. Because often there exists a point where the control turns into chaos. So when you deviate be aware of the consequences of it.

After this much introduction, here follows the parts of this site that I intentionally left invalid:

• Although W3AI recommends it, I don't use noscript for an alternate means of providing scripting content.
  
  Because a truely accessible site does not need noscript at all.
  
  Besides, providing a noscript just to say that "you require javascript for this web page to function properly", which is simply equivalent to providing no alternate content at all.
  
  So why use it?
• Secondly, as you may have recognized, I use CSS alpha transparency which (currently) CSS Validator generates an error for. However CSS alpha transparency is a valid CSS3 property.
• Another issue is that at parts of the site I use M$ generated invalid markup. The markup may have been transformed to a valid one by applying a response filter.
  
  Although this would not be an easy solution, it is technically possible. However I don't do it.
  
  Because M$ has promised that the coming versions of .net framework will create strictly valid markup. Providing strict markup for its custom components should be the Vendor's responsibility; not mine.
• At parts of the site I use AJAX without an alternate implementation.
  
  The AJAX parts often do not transform gracefully either (note that I say transform gracefully not degrade gracefully).
  
  This site is not my primary job function, I hope you understand this. And giving a non-ajax alternative to everything exceeds my timeframe.
  
  Yes, I know; "shame on me".

Moral of the story

Each business decision brings certain amount of risk with it.
And you decide to take that risk or not.

You are most probably working with real people and trying to conceptualize real-life scenarios.

So jump off from your ivory tower:
A SGML parser cannot do business logic decisions and risk analysis for you. It can only lead you to the right way. However it is your responsibility to take the risk.

To give an analogy:
Remember that Phantom Menace used his radar (the Validator) to detect the target (a forward compatible, future-oriented web application). However he used his feelings and subjective judgement to shoot right at the heart of the target (Star Wars - Episode I).

So use your feelings and your judgement.
Should you do, you will most probably find the right path.

May the force be with you!