The ASP.NET validator controls tend to produce tags with proprietary attributes which are "not in the book" and therefore will always cause HTML validation errors. Is this a dead-end for ASP.NET or can we accommodate this?
When you place a RequiredFieldValidator on a web page and wire up its properties you end up with markup similar to this:
<span id="_ctl1"
controltovalidate="Name"
errormessage="Please, enter your name"
display="Dynamic"
evaluationfunction="RequiredFieldValidatorEvaluateIsValid"
initialvalue=""
style="color:Red;display:none;">Please, enter your name</span>
I've taken it from a simple web form I put together for this post. The page has a text field, a RequiredFieldValidator control wired to validate it, and a submit button. The page uses the XHTML 1.0 Strict DOCTYPE. If you're new to doctype switching see What's In Your DOCTYPE?.
Run this page through a validator and it'll rightfully complain about non-standard attributes on span elements.
I have to hand it to Microsoft folks for this ingenuous hack. It's a kludge, but validation controls are such a huge help. Some people will get very upset about seeing at least 5 validation errors on their pages even after all their hard work. So what are we supposed to do?
If you haven't read my previous post, Back To Basics: (X)HTML Specs Made Easy, I suggest you do so. It'll be easier for you to follow the rest of this post.
We're going to slightly adjust the XHTML 1.0 Strict schema by adding those 5 optional attributes to the span element. It's a perfectly legit thing to do.
I went to W3C and pulled down XHTML schemas. Next, I found where span is defined in the Strict DTD (xhtml1-strict.dtd) and modified its attributes:
<!ATTLIST span
%attrs;
controltovalidate IDREF #IMPLIED
errormessage %Text; #IMPLIED
display (Static|Dynamic|None) #IMPLIED
evaluationfunction %Script; #IMPLIED
initialvalue %Text; #IMPLIED
>
I saved the schema file as xhtml1-strict-dotnet.dtd and uploaded it to my server. Custom schemas need to be made available to validators. Feel free to poke around my custom DTD.
I've modified the sample form I mentioned above by declaring my own DTD (I suggest you keep it all on one line):
<!DOCTYPE html SYSTEM «
"http://www.aspnetresources.com/xhtml1-strict-dotnet.dtd">
At this point we're good to go. Run the modified page though a validator... and it goes berserk. This is where I started scratching my head. All of a sudden the W3C validator started picking on meta tags. Out of curiosity I removed all meta tags, but the validator still reported This page is not Valid ! with no (!) errors.
I've looked around newsgroups for an explanation and noticed lots of people had similar problems. Finally, I came across a link to the HTML Validator run by The Web Design Group. Unlike other markup validators this one understands custom DTDs. Straight from the horse's mouth:
Unlike other validators, the WDG HTML Validator uses a special SGML declaration when the document refers to a custom DTD. The result is that many custom DTDs, especially those built from the HTML 4.0 Transitional DTD, work correctly with the WDG HTML Validator but not other validators.
See that option Precisely, this is XHTML with custom DTD? This is us. In case you're wondering, they do parse your DTD and validate against it. I introduced a bogus attribute, and the validator pointed out it was incorrect according to my custom DTD.
2B | !2B
Now that our custom schema accommodates proprietary attributes, we need to address a bigger question, "To be or not to be?" Some purists may label me public enemy #1 for tweaking a standard DTD. By golly, you can add embed or blink back to your pages, but should you?
Instead of setting in stone what thou shalt do I'd like to hear your opinions. What do you think?
As far as mine goes: adding 5 attributes to the span tag to let ASP.NET validation controls do their job and help with markup validation is perfectly justifiable. Those attributes have no bearing on the presentational aspect of web pages. They serve more of a behavioral role which is the domain of JavaScript (or EcmaScript, to be more precise).
In terms of resurrecting blink... What was your email again? I'd like to send you a virus.
