Standards Frustration of an ASP.Net Newbie
By Chris Kaminski | October 3rd, 2004 | Filed in Web Standards (general)
Skip to comment formAs I mentioned in my previous post, my employer has adopted Microsoft’s ASP.Net as their server-side technology of choice.
For the most part, this decision has only tangential impact on me: I spend most of my time on client-side development, project management, IA and the odd incursion into the worlds of graphics and Flash/ActionScript. The server-side tech just stays out of my way, which is how it should be.
Once in a while, I do end up doing some lightweight server-side stuff, usually when a client is hosting their own site on an Apache server and using PHP or PERL. But last week I was pressed into service hacking together an email form in ASP.Net.
It was an extremely simple task, really — especially as I was able to crib most of what little code was needed from forms developed by our regular programmer. Even so, I have to admit being a little excited: it was a chance to develop some (very) basic chops with a widespread technology about which I’ve heard many good things.
The good feeling didn’t last long, though.
First, I discovered a very curious practice among ASP.Net developers: wrapping the entire page — everything within the <body> tags — in a <form> tag. Apparently, if you want ASP.Net to process the dynamic bits (for example, to insert text from a database where you’ve stuck a variable name), said bits must live within a <form> tag with a runat="server" attribute.
I don’t come close to knowing enough about ASP.Net to know if I’ve been sold a bill of goods, but if the foregoing is accurate it really rankles. Maybe the whole-page-is-a-<form> thing makes sense to Microsoft developers accustomed to the WinForms metaphor, wherein each and every UI is a form. But to this webhead, it makes no sense whatever. In fact, it seems downright hostile to good document structure.
Here’s hoping the whole thing is just a misunderstanding caused by my extreme ignorance regarding ASP.Net best practices.
The second issue I encountered went beyond curious to being downright frustrating. One of the oft-touted benefits of ASP.Net is it’s labor-saving built-in functions. While slapping together my primitive form handler, I employed one that promised to be seriously nifty: automated form validation controls.
I know from the dozen or so PHP form handlers I’ve written that validation is easily the most time-consuming bit in a simple email form. So the prospect of inserting a few tag-like bits of ASP.Net code and being done had me giddily cackling away. Until I saw the error output.
You see, the error messages generated by ASP.Net are all wrapped in — eeyew — <table> tags. So much for that nice semantic markup.
To be fair, the <table> markup was valid, and it did include an id attribute for easy styling with CSS. But still. Why throw in an extraneous <table> at all? The validation control offers the option of producing error messages that are enclosed in a <p> tag or marked up as an unordered list. It would be easy enough to mark-up the optional error header with an <hn> + an ID. What on earth do I need the extra <table> for?
Maybe there’s an option to change the <table> to a <div>, or even to suppress it altogether. But after 30 minutes of furious googling, I handn’t found it and the deadline was looming. So <table> it was.
Like I said at the outset, I’ve heard lots of good things about ASP.Net: the separation of server-side code from markup, the ease of developing reusable components, its OO architecture and, of course, the built-in functions.
Those last, in particular, could be real time savers. But if using them means sacrificing semantic integrity, then they look like a faustian bargain to me.
Ah, well. I suppose in the worst case, I’ll just have to roll my own replacements — something I’d be doing anyway if I were using PHP or Perl (depending on which modules/libraries were available on the server, of course). And I still hold out hope that it’s just my own ignorance that’s making ASP.Net look bad, rather than any flaw in Microsoft’s implementation itself.
Update: After I posted the above, something was nagging me about the list of ASP.Net benefits. It just seemed I was missing something. Turns out, I was: XML support. While I’ve not done a whole lot of XML wrangling (apart from XHTML, of course), from what little I know ASP.Net is at least as good as any other server-side language when it comes to handling XML, and probably better than most. PHP, for example, is pathetic without the installation of additional modules, and my (quite limited) experience with those indicates they’re rather awkward — assuming you can even get them installed, which isn’t a given if you’re on a shared server.
So whatever standards-related kvetches there may be about ASP.Net, it’s most definitely got it’s good points, too.
Update the 2nd: Another thing about the post was bothering me, too: my assertion that the markup for ASP.Net’s form validation error messages was, if not semantically kosher, at least valid.
Guess what? I screwed up. It isn’t. I’d forgotten that to color the error messages red, ASP.Net inserts a <font> tag inside the <table> tag. Apart from just being a semantic no-no, the <font> tag is also an inline element. But as noted, ASP.Net further wraps error messages in either a <ul> (the default) or a <p> — both block elments, and therefore invalid when placed inside the inline <font> element.
So the markup ASP.Net generates by default is not only a semantic mess, it isn’t even valid (X)HTML. <weeble />
Update the 3rd: Via email, Nick Vrvilo confirmed my worst fears regarding ASP.Net’s HTML generation functions. Nick says they do largely generate semantic nonsense, and invalid semantic nonsense at that.
Worse, Nick says there’s no easy way to override the default markup. To do so, one has to write one’s own libraries. Nick helpfully points to a tutorial on creating custom ASP.Net libraries but also observes that it’s an awful lot of work just to create a simple valid HTML form. Just so.
On balance, Nick says that eschewing the built-in goodies in ASP.Net is the easiest way to get valid pages, and that it’s really not that bad since you end up in the same place you’d be with other languages. True enough, and ASP.Net still has other advantages.
On a brighter note, Nick confirms my suspicion that the entire-page-inside-the-<form>-tag number is nothing more than a carryover from developers used to working on Windows apps, where each screen of an application is a form. He says developers used to that metaphor just slap the <form> element around everything out of habit; ASP.Net only requires it around the actual form elements — which is just as it should be.
So a mixed review, then. ASP.Net has much to recommend it, but Microsoft still gets raspberries for encouraging presentational, invalid markup with their default ASP.Net functions.
Update the 4th: Due to the volume of responses I’ve received, I’ve just rolled all the rest of my updates into a new post.