buglab: ASP.Net and W3C Standards - a Marriage Made in Purgatory

Developing websites with Microsoft Visual Studio.Net is relatively easy. Developing W3C Standards compliant websites with Microsoft Visual Studio.Net is not, as I found out when developing Powderseekers. Pages generated by ASP.Net using the platforms extensive out-of-the-box controls simply don't validate. So, you find yourself being put in ridiculous position, such that you have opted for .Net as it is feature rich, has an amazing array of tools, developer assistance and a Class library so enormous that its daunting. But, you want to make your websites W3C Standards Compliant. To achieve this you must forget using the controls and tools, which pretty much negates your reason for choosing the platform.

Most of the validation errors can be worked around but for me the worst offender is caused by the way that .Net handles Session State - holding state information in a hidden <code>input</code> tag which is invalidly formed and utilises client-side JavaScript which is invalidly declared. I've seen a few discussions around the web on the subject (here's one).

and it seems that the only feasable workaround is to take each server control, inherit it and override it's render method(s) to output XHTML. It didn't take long for me to decide that I really didn't have the time for this, I've seen Custom Controls available for download - but at a fee - and at the time that I realised that this was a problem I didn't feel technically proficient enough with C# to implement the workaround (which, as workarounds go is some pretty hardcore coding).

A few tips: -

Don't ever use the Design View. Ever.

This is a shame as it can be fairly handy, for example - if you add an item with 'runat=server' to the aspx page and then switch to Design View then the item is automatically declared in the code-behind (.cs), also it can sometimes be handy when working on a complex layout to highlight a div or input and check its properties. The problem though, is that switching to Design View triggers some kind of demented code sweeping process which, when you switch back to Code View, has pretty much mangled your code without asking. The changes made appear to be random and don't consistently happen, the most common of which is stripping out the closing </li> in an unordered list effectively making your code invalid! There are loads of little quirks like this, and yes, I have tried every combination of box-ticking in the preferences window to no avail. Best advice, once you have the basic page structure nailed down then don't use it.

Don't drag-and-drop Controls

Not sure if this is good advice or not really but make of it what you will. I found that using the controls [...] caused yet more validation headaches. Although, to be honest this is more a question of semantics - I would find that when trying to code lists that the control would spit out the necessary XHTML as a table. If I then specified that it should be a list then I'd find that sometimes the list would be wrapped in a , which won't validate. More problems became apparent when I noticed that even if I'd managed to get lists to come out as valid markup in IE6 when I looked at the source in Firefox they were rendered as tables again!? There is a fix for this at bloggidity). By this time I was ready to set fire to my .Net books and decamp to PHP. I decided instead that I would ignore all the obviously useful suite of tools available in the .Net Development Environment and just create all the valid XHTML in the back end and send it to the browser correctly formed.

Below is a simple version of what I mean. On the front page I want a list of the top 10 latest Forum Threads and I want them to be in an unordered list. So, all you do in the code-behind (.cs) is execute the relavant query, fetch back each row and build up the XHTML required into 'forumsposts', which in this example is the id of a div which has the runat=server attribute.

string cmdForums10 = "SELECT TOP 10 a.idThread, a.idMember, b.nmMember, a.txSubject, a.dtCreate, d.txCategory FROM thread a INNER JOIN member b ON a.idMember = b.idMember INNER JOIN category d ON a.idCategory = d.idCategory WHERE (a.flDisplay = 'Y') AND (a.cdArea = 'forums') ORDER BY a.dtCreate DESC"; SqlDataAdapter dadpForums10 = new SqlDataAdapter(cmdForums10, ConnectStr); DataSet dsetForums10 = new DataSet(); dadpForums10.Fill(dsetForums10); DataTable dtabForums10 = dsetForums10.Tables["table"]; //construct the XHTML for the latest posts forumsposts.InnerHtml = "Latest forum threads"; forumsposts.InnerHtml += "<ul>"; foreach (DataRow drowForums10 in dtabForums10.Rows) { forumsposts.InnerHtml += "<li>" + "<a class=\"bull\" href=\"forums.aspx?threadID=" + drowForums10["idThread"].ToString() + "\">" + drowForums10["txSubject"].ToString() + "</a> " + "- >a class=\"mem\" href=\"profile.aspx?memberID=" + drowForums10["idMember"].ToString() + "\">" + drowForums10["nmMember"].ToString() + "</a></li>"; } forumsposts.InnerHtml += "</ul>";

Messy, but it means I have total control over what is sent to the browser - that demented code sweeper can't touch it. By the way - to make this simpler 'forumsposts' could have been a ul with the runat=server attribute but I needed to be able to fill it with other tags if needs be (ie. if no rows returned then forumsposts.InnerHtml = No threads.

Accept that pages with Forms won't Validate

Not good, obviously. This is one of the faults I decided I just had to live with.

This may or may not be good advice depending on your stance, but I started using .Net in good faith and by the time I realised how difficult it was to create W3C Standards Compliant pages it was too late to switch. For my mind until all these issues are ironed out in the next ASP.Net release I'm just going to have to make do with some problems and workaround others.

Validation issues aside I think that the .Net Development environment is fantastic to work with. The debugging tools alone save your sanity and the compile time and run-time error messages are spot-on every time and identify exactly the piece of code at fault. Anyone who has worked with compiled languages like COBOL (yes, that's me) will know how random, vague and downright useless complile and run-time error messages can be. The Server Explorer is great for doing quick database queries without having to use Enterprise Manager and the 'intellisense' is absolutely invaluable.

All-in-all - a fantastic development platform, but hugely lacking in Standards Compliance support.