ASP.NET and XHTML
I found a couple of interesting articles about ASP.NET and web standards when I was looking for information about seperating presentation and business logic in ASP.NET using XML.
The guy from ASP.NET resources makes the argument that it’s not economically viable to put the resources into developing ASP.NET applications that return properly compliant XHTML. I really think he has a point. The built-in ASP.NET server controls (particularly validation) return HTML code that is not XHTML compliant. The code the validators generate is hard coded into the components, so if you want to generate code that is compliant with the W3C XHTML standard, you need to override the default behaviour.
There are third party components out there that replace the ones that come with ASP.NET, but the problem with using them throughout your applications is it makes your application less future proof. When (not if) microsoft changes things significantly again, they are more likely to provide upgrade paths for people using the standard tools. People who are using third party tools are basically on their own.
On the other hand, one of the guys from the web standards project makes a good argument that standards are strengthened by people actually using them. Clientside standards make the web a fairer place for everyone. If the dominant browser maker can force people to create sites that aren’t standard compliant by ignoring and misinterpreting the standards, then the people making the standards (and the other browsers) may as well just pack up and go home.
A web based on principles of product lock-in isn’t a fair web for anyone. If other browsers support the differences required to make pages render correctly in the dominant browser, the people who make the dominant browser basically have a licence to define the standards. If the other browsers don’t render pages in the same way as the dominant browser, people using other browsers will only be able to view the parts of the web specifically designed to accomodate them. This also makes webpages more expensive to develop and maintain. Time and money that could be spent on generating content or improving usability instead has to be spent crafting pages that can be viewed by as many people on as many different platforms as possible.
One of the big attractions of standards compliance for me is that it makes the things I build a tiny bit more future proof. Microsoft Internet Explorer may or may not be the dominate browser in five years time.. the font tag may or may not be forgotten.. but chances are that the standards agreed on by W3C will probably still be supported, in some form or another, and at least the poor person who gets to rewrite my work has a chance of guessing at what I was trying to do.
What complicates things is that with ASP.NET applications, suddenly there are two types of “standard” ways to do things. To make my life easier, I try to work with the ASP.NET way of doing things where possible. This means that even if the implementation of the “required validator” changes significantly in the next version of the framework, respecting the meaning of the validators (rather than using incredibly evil work arounds) should minimise the changes required to make my code work with new version. However, because of the was ASP.NET is designed, doing things “the microsoft way” on the server also means letting them decide how standard compliant my clientside code will be and the guys at microsoft seem to have a different agenda when it comes to clientside standards compliance than I do.
What I’d like to do would to have the best of both worlds. I’d like to be able to do things on the server the microsoft way and do things on the client in a way that supports the W3C standards. What I’d really like to do is have my ASP.NET code build XML documents containing all of the information that my pages need and then use something else (probably XSLT) to actually generate the webpage code.
The way things are at the moment, I can’t have it both ways. To implement a system that seperates clientside and serverside code more cleanly would mean overriding a lot of the ASP.NET framework and deciding that I don’t really want to do things the microsoft way. It could mean significant work rewriting my framework each time the ASP.NET framework is upgraded. It will mean I don’t actually get the full benefit of the ASP.NET framework. It could mean that in three or four upgrades time my framework is incompatible with the microsoft way of doing the same thing.
It’s all a bet really. I don’t know if microsoft will ever change ASP.NET to provide better seperation between presentation and business logic. I don’t know if in three or four years my current applications will be hopelessly incompatible with the latest version of the framework even if I do play by the rules. I don’t know for sure if the next generation of browsers will be more standard compliant than the current ones. I don’t know if the standard won’t change so much that the work I’m currently doing will still even be compliant with the next versions of the standards from the W3C. What I do know is that solving the non-domain specific parts of my problem the way everybody else solves these problems are the best odds on offer for a robust solution that’s as future proof as I can make it. The problem is I also know that a web that is controlled by any particular company is not going to be a fair or even particularly innovative place and it’s not the sort of web I want to help to build.