VS 2005: HTML validation checking

A couple of days ago Scott Guthrie posted about HTML validation checking feature in Visual Studio 2005:

"...The reason we are now surfacing HTML validation issues in the error list by default is that we are trying to promote more standards-based HTML with VS 2005 and ASP.NET 2.0, as well as to catch potential rendering and browser functionality errors earlier in the development process (so that you dont have to run and carefully analyze every page in your app. looking for these types of issues).

...If youd rather not have these types of HTML validation errors show up in your error-list, you can disable this functionality by selecting the Tools->Options menu item in VS or Visual Web Developer."

The fact is that many developers are unhappy about this feature. For example Rick Strahl explains several issues regarding HTML validation:

"...So there are two issues here: First the fact that HTML format errors really have no business being flagged as errors. Errors in this environment should only be things that break the build and HTML errors don't qualify in my book. I can appreciate the folks who are Nazis about their HTML Validation and want to see them prominently, but having them show as errors doesn't do anything other than display here its not breaking the build, so this is purely an annoying and non-configurable GUI feature."

...The other is that of context. If I compile an individual assembly, that has nothing to do with HTML markup tags why should the IDE show these errors in this place its completely out of context. Theres no options to have VS show the difference between background compile/eval errors of whats open and what compile you just ran. All this stuff just gets jumbled together into a single bin."

I agree. Half a year ago I posted a bug on compiler errors in xhtml about inconsistent behavior and conversion issues. It was resolved by design:

"Thank you for your feedback. After Beta 2, we changed XHTML conformance to Transitional for all new Whidbey applications. Unfortunately, this triggers an issue when converting a VS03 web project. A number of developers wrote script that relied on the id attribute of the Form tag (it was the most common breaking change for ASP.NET in compatibility labs around the worlds) . This is a not allowed attribute in transitional -- so if we make it transitional on upgrade scenarios we break a lot of developer client side script. So when we convert a VS03 web project we set XHTML conformance to use Legacy mode."

What do you think ?

Related Posts:

• Visual Studio 2005: Web Deployment Projects Add-On
• Convert Web Application from VS 2003 to VS 2005
• Exclude From Project Issue Fixed in VS 2005 RTM
• Visual Studio 2005 Shipped With Bugs, Backward Compatibility Problems
• SQL Server 2005 and Visual Studio 2005 - RTM
• Visual Studio: How to Debug Script Code
• VS 2005 beta 2 -- Exclude From Project Issue
• Asp.Net 2.0 and VS 2005 Beta 2 Bugs
• Visual Studio 2005 Beta Experience Program
• Visual Studio 2005 Beta 1 with Team System Included

One of the facts of life with web development today is that we live in a multi-browser world and building good web UI that works seamlessly with all browsers isn't easy.

One of the big pain-points is the fact that a lot of things often "kinda work", but ultimately perform or render in subtle different ways in different browsers (small spacing differences, rendering issues, etc). Keeping track of "standards mode", "quirks mode", and "transitional" renderings is a real pain and time-sync (and trying to keep everyone on a team up-to-date with them is not easy). I would personally prefer chasing down a deadlock bug over a subtle Opera/IE/FireFox/Safari overlay spacing issue any day of the week.

The goal with adding the HTML validation features into VS 2005 was to help make it easier for developers to know exactly what is -- and what isn't -- legal html/css to add to their app, and to help developers write code that has the best possible chance of working consistently in all browsers the first time around (specifically by writing to agreed on standards supported by all systems).

It can ceretainly be a "pain" when you see a lot of errors show up in the error-list indicating that there are problems with your HTML. But I would argue that it is *a heck of a lot* more of a pain trying to identify and fix rendering problems in multiple browsers on multiple operating systems once the app is built and deployed (especially since the bug reports you'll receive from users tend to be hard to pinpoint comments like "it looks really bad and I don't like it"). Rather than force people to manually learn/verify what is/isn't legal, we wanted VS 2005 to help automate the verification and guide new markup to be correct.

The reason we chose to mark html validation issues as errors as opposed to warnings is because if a user using a non-IE browser is trying to access your web app and it doesn't render or work correctly for them, then they are going to interpret/believe the app is buggy. I do agree with Rick's feedback that there should be a better way to filter these errors in the error list (maybe adding another tab to enable easily turning them on and off -- something I think we should do for the next release). But I do think we need to help educate and guide developers towards writing web apps that will work in all browsers -- and to treat things that prevent this from working as "errors/bugs", instead of just "warnings/nice to-dos".

One thing to call out (for those that haven't used the feature yet), is that the HTML validation support can actually be configured to validate different things for different standards and at different levels. The default validation we use out of the box with a clean VS 2005 install is "XHTML Transitional", but can be configured to be "XHTML Strict", "HTML 4.01" or even "IE 6.0" instead. This later option is the closest approximation to the HTML generated by VS 2003, and is a setting you might want to use if you have a large amount of HTML that is non-legal but you aren't ready yet to invest the time to fix it to be more standards compliant and/or non-IE browser compatible. Switching between the different validation standards is pretty easy (by default there is a drop-down box in your toolbar to allow you to switch target schemas rapidly and on the fly).

For example, the errors in Rick's post with the colors are because the page is being validated using an XHTML Transitional validation setting, but it is using non-standard color names that might not work in all browsers and are not XHTML legal (here is the list of legal HTMl 4 and XHTML colors: http://www.webstandards.org/learn/reference/color_names.html). If he changed the validation to instead be "IE 6.0" -- then those specific validation errors will go away.

By default, when you upgrade an existing VS 2003 web project, we actually set the validation to be "IE 6.0" to help minimize the errors you see (note: this was a late RTM fix -- so wasn't what happened in Beta2). For HTML 4.01 and IE 6.0, there are also sub-levels of validation that you can set if you want to incrementally add additional validation rules (for example: you can choose to validate inside css style elements or not, validate element casing, element close tags, etc).

If you don't want or care about HTML validation at all, you can also obviously turn it off completely. This blog post shows how: http://weblogs.asp.net/scottgu/archive/2005/11/23/431350.aspx.

Hope this helps,

Scott

thanks, Scott
I really appreciate it

Any particular reason why there's no option to set the validation type to something like "Automatic" and have VS check for a DOCTYPE declaration in order to determine the rules to use?