I posted the following in a thread I started on the MooTools forum. I had suggested earlier that the download page be redone to validate as XHTML, and my position needed some clarification:

I was going to leave this topic be; it was a suggestion and it is not up to me to decide what direction or politics MooTools adopts. With the responses so far being – EugeneZ’s aside – being so disconnected from my initial intent however, I feel the need to clarify what I meant and my position. Especially repeated comments of ‘What’s the problem?’ is a sign I wasn’t clear enough.

Firstly, I recognise the fact that there is a difference between a smaller personal website, websites demonstrating cutting-edge web technologies and big web projects by government or organisations. I do not expect or indeed want the amazingly cool web development as of late to be hampered by anal adherence to the rules where that adherence is not warranted.

It is to me a bit pointless arguing the matter of non-standard attributes from first principles. The question of “What’s the problem?” has been discussed from every angle, and the arguments are easy to look up. My stance on it is irrelevant, but I’ll state it briefly anyway. Non-standard attributes are ok to me as long as they are thouroughly tested in all browsers and as EugeneZ says – not overused. Guillermo brings up the point of eXtensible which is a red herring – extending XHTML is a great feature of the markup language but how can you make a point of that while ignoring the fact that a custom DTD should also go with that? (And yes, I know custom DTD’s are hard) This is the kind of first principle arguments I’m not interested in getting into.

That said, project of a certain size, or for certain clients, can simply not get by without passing validation. As has been stated elsewhere, getting rid of warnings (not just errors) from programming code is considered good practise and a crucial first step to getting rid of unexplainable bugs. Why not also so for XHTML? Or, put differently, who’s to say which validation error is causing a problem, and how do you explain that to the client? This is where I go on to play the devil’s advocate in my argument – my opinion in the previous paragraph still stands, it is just that in a lot of bigger projects custom attributes just won’t pass. It’s as simple as that.

It is hard enough getting to use MooTools in some of these projects, and to me it would be helpful if at least the MooTools download page passes validation. It is not the most complicated page in the world, and yet it is still the first ‘wow’-moment you have when you first investigate MooTools as a framework. If you haven’t been to the demo page first that is. So to see that kind of stuff also working on standards-compliant pages can only be a plus as I see it.

That’s the gist of it. I don’t expect the page to change judging by the responses and that’s fine; I won’t march off to Dojo (yes, that’s a joke) slamming the door behind me either. MooTools is one kick-ass framework and I want it to succeed and be used on every single web project I work on. It makes my work day so much easier and more exciting. My suggestion was merely inspired by that and the fact that I’d like to use it even more. Standards, standards, standards