Forcing ASP.Net towards standards
In the recent Web Standards Project Buzz post ASP.Net & Standards Part II, Chris Kaminski writes a whole lot about ASP.Net, web standards, and how to make it possible to use both in the same project.
I’ve had some recent experience with this, and can only agree that the “HTML” that ASP.Net produces out of the box is for the most part horrible, invalid, non-semantic junk straight out of last century. A slap in the face of anyone who dares believe that people foolish enough to use a non-Microsoft web browser should be allowed to visit a site built with ASP.Net.
I obviously could not leave things that way for this site. When a client actually requests that their site is built with web standards, you really want to do whatever you can to get there. I went looking for workarounds, and thanks to Milan Negovan’s tutorial on response filters I was able to get rid of a few ASP.Net problems. I also use that method to remove any target attributes inserted by the site’s editors and replace them with Strict DOCTYPE-friendly ECMAScript, as described in Accessible Pop-up Links at A List Apart.
However, the major offenders when it comes to invalid HTML are the controls built into ASP.Net, so most of them had to be replaced. Not being a hardcore ASP.Net developer myself, I had to nag my friendly coworkers about it until we had nice, clean, and valid code.
But wait, there’s more. As Chris mentions in his Buzz post, ASP.Net puts a hidden <input> field called _VIEWSTATE on every page. In theory, it’s a good thing since it’s there to keep track of what a visitor has entered in a form if something goes wrong. In practice, however, you really need to keep what goes in the _VIEWSTATE field to a bare minimum. If you don’t keep an eye on it, well, I’ve seen sites with _VIEWSTATE fields that are well over 25 kb in size. Per page. Sent to the server and back every time a form is submitted. Ouch. So we disabled that for all pages that don’t really need it. In this case, that meant almost every page of the whole site.
It took some work, but we and our client are happy with the end result. I’ve seen statements that the next version of ASP.Net will produce valid XHTML 1.1 by default. Hopefully that will happen, and soon. Most of the workarounds described here would then be unnecessary. So much the better.
- Previous post: Breakestra: Live Mix 2
- Next post: Web Standards Solutions
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
We recently did some work with .NET. I was charged with making sure the interface was consistent. Fortunately, it was an intranet project that was only going to be used with IE6 in a controlled environment.
The project started out as XHTML pages using CSS. They remained that way for the most part as our programmers began the .NET portion of the project.
Because .NET was using tables to layout the forms and such, many of the styles I had applied (font sizes, color, etc.) were not even being applied to the content in the table. So I ended up having to go in and create new styles for the tables.
The code was horrendous. I am not sure, but it may have been worse than the ugliest stuff I have ever seen frontpage spit out.
The one thing that really got me is that after I would apply the styles (mostly written into the section of the page), and the page was then re-opened in visual studio, it would change the shorthand back to longhand. So if I had set border: 1px solid #f00, after running the page in the development environment, the css would have individual rules for each side.
Crazy stuff. Thanks for nothing Microsoft.
Amen to last last comment - I've spent lots of time on my current project hunting down bugs that turned out to be because Visual Studio.NET changed the doctype on a page or something.
The way the server-side code ends up dictating the client-side code utterly gets my goat. I guess it would, given that I'm a client-side developer, but I ask you .NET developers this: if something in HTML meant that you couldn't use a
forloop, or the IDE changed all your variable names to uppercase, I imagine you'd get a bit narked.And people wonder why the standards community lean towards a LAMP solution?
I think we all know why!
ASP.NET renders server controls based on the user agent string -- it renders proper HTML 4 with CSS for browsers it deems capable of handling it, and HTML 3.2 with a mess of nested tables for everything else.
Unfortunately, it only gives HTML 4 to Internet Explorer 4+. Everything else gets HTML 3.2 and the smelly end of the stick.
There's a workaround for this, though. You can edit the browscap.ini for ASP.NET to make it serve proper HTML to all capable browsers.
I would have preferred it if ASP.NET left it alone and just gave everything the same HTML out of the box, but at least you can do it on your own site. Too bad that the majority of all IIS sites force this crappy HTML on you.
I have some links with information about how to do this; I'll get back to you later.
The mere thought of ASP.NET messing with my HTML beyond my control sickens me. I wonder why they thought that behavior was a good idea...
I feel that I actually have to defend ASP.Net a bit here...
Firstly ASP.Net isn't the bad guy here, Visual Studio/Web Matrix in the wrong hands are...
When you code an ASPX page you can do that in the same way you do with PHP - Blend xhtml with server-side logic. It will work in a similar way.
Then there are something in ASP.Net called 'controls'. The meaning with these are to separate client code from server code to make it easier to maintain. -Actually they're great for a programmer...
...but you don't get a semantic page with valid markup.
There you go, the choice is all yours:
a. Create your own controls (not very hard).
b. Skip controls and write a mix of xhtml and server-side logic. (Response.Write v/s echo/print).
But please remember ASP.Net itselves doesn't mess up or change your code...Visual Studio does.
Johan: The crappy behavior you describes usually only shows up when you apply properties directly to a control in Visual Studio/Web Matrix. Leave your controls unstyled and use external CSS formatting instead, than ASP.Net will leave your controls alone (at least according to my own tests...)
I've been developing in ASP.NET for about three months now after years of experience with PHP, Cold Fusion and ASP classic plus thorough knowledge of HTML, JavaScript and CSS. The first thing I did when I started editing an existing project was disable all the code fiddling that Visual Studio loves to do to the client side code.
Now that I'm more comfortable with the environment, I've taken to using HomeSite for all the client side code and using custom controls where ASP.NET doesn't render them correctly. Reverse engineering the W3C specs was very easy.
More than anything else, I think it's disappointing that ASP.NET has fallen short of the mark and that work is required to bring things up to scratch. It certainly doesn't make it any easier for someone new to the development environment.
Johan Svensson wrote:
Not quite - the rendering engine is a half-hearted mess of XHTML and HTML 4 hence the need for response filters or some other means of fixing broken tags.
Johan: I agree with Chris here - the default HTML output is pretty messy regardless of which browser you use.
Kalle W: Right, ASP.Net in itself is not the problem. The problem is that many (most?) ASP.Net developers tend to use Visual Studio to build their applications, and use the default controls because it's convenient (for them). When I was working on the project I'm referring to here, I did all the coding on my Mac and only used Visual Studio (running on Virtual PC) to compile the application.
Good news - Visual Web Developer 2005 (Beta) defaults all pages to xhtml 1.1 strict. I've been playing around with it, and I'm quite impressed. I'm not sure when it'll go to the next/final beta, but you can download the development kit and .NET 2.0 framework and try it yourself.
That's great news! Do all controls output valid XHTML by default? Is the Doctype actually XHTML 1.1 strict, and if so, is content negotiation built in (since XHTML 1.1 should not be served as "text/html")?
We know that and the W3C knows that but try convincing IE anything to accept "application/xhtml+xml".
Sorry, comments are closed for this post.