ASP.NET Cure: Custom DTD for XHTML

Posted on September 23, 2004  |  

Posted in Development

17 comments

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.

17 comments

Mike Gale
on September 23, 2004

I say well done.

XHTML is called extensible for a reason. In the days of the "browser wars" we had rather rapid progress. (Initially it was much faster than the standards came out. Remember HTML 2 etc.) Now that a lot of people are screaming "standards" I sometimes hear "fossilisation". Make no mistake I completely believe in CSS, XSLT, XHTML, I also believe as strongly in progress.

The extensible gives you innovation and a way to accomodate it. It seems a reasonable approach to me.

I recently developed a custom XHTML schema, but changed it to standard when I envisaged the potential issues with validation.

I use the CSE validator (which is NOT driven by DTD's and gives validation that goes beyond what DTD's can offer). The most I have done to customise this is to change the messages that it produces. That, unfortunately, limits me.


Milan Negovan
on September 23, 2004

Yep, I've seen the CSE validator. Very cool! I need to play with it to get a better feel for it.


Mike Gale
on September 23, 2004

I've been in touch with Albert Wiersch who produces CSE. It has facilities to edit the validation engine so I'm having a look at doing that. If it's a reasonably sized job Albert will add ASP.NET specific markup to the next version, provided he gets the details. Anyone got a concise list?

I find CSE extremely valuable and often use it several times a day.


Vinnie Garcia
on September 24, 2004

If the span's attributes are there only to serve as hooks for scripting validation, why not move the whole thing into the client-side scripts instead, rather than bothering with extending the DTD? That would be the ideal way to handle this, since behavior should be in scripting (that's why Javascript is available in the first place).


Milan Negovan
on September 24, 2004

You still need some kind of hooks on a page to indicate which control to validate, what kind of validation to perform, what error message to display, etc. The rest *is* handled by JavaScript.

Vinnie, how do you envision it?


Robbert Broersma
on September 24, 2004

Well, I'm not an ASP(.NET) user, but I'll give you my opinion anyway: I think your workaround is okay, but it is just as valid as website A linking to website B by using http://website-a.com/external/website-b.asp with a 301 header plus location reference; ultimately you don't want this, and you'll probably remove this hack as soon as possible, but in the meantime there aren't all that much practical disadvantages. (Are there?)


Vinnie Garcia
on September 24, 2004

"You still need some kind of hooks on a page to indicate which control to validate, what kind of validation to perform, what error message to display, etc. The rest *is* handled by JavaScript.

Vinnie, how do you envision it?"

Why do you need hooks on the page when you can just throw all of that validation logic into the script? I've written many a form validation script that needs no hooks in the HTML other than maybe the id/name of the form control being validated and (if I use spans to show error messages rather than alerts) the ID of the span to show. Modern Javascript is all about separating behavior from page structure (HTML code), and while .NET's validation model comes close, it's still not ideal.


Milan Negovan
on September 24, 2004

Vinnie, I see your point now. Yes, I agree, that'd be a better approach. Ironically, we've written a validation library of this kind at work which works across browsers (my co-worker wrote most of it). We didn't rewrite any of the ASP.NET validator controls. It's all JavaScript.

I haven't looked into any of the ASP.NET 2.0 controls yet, so I don't know if we can hope for an improvement.


Milan Negovan
on September 24, 2004

Robbert, I appreciate your opinion!

A practical application of this approach that I can think of is to have your pages validated properly. Seeing at least 5 validation errors could be a real turnoff for some people.

I've written about quite a few ASP.NET hacks on this site, but I don't consider creating a custom DTD a hack. Especially when no ambiguous elements are added which could confuse plain text user agents. IBM use their own custom DTD, aka "ibmxhtml1-transitional.dtd".


Darren Syzling
on September 26, 2004

Got to agree with Vinnie here. Some other control authors have taken this approach to integrating server side control properties with their control's javascript code.

This leaves span or div tags with a huge number of added attributes. I can't see why these properties can't be written to the page as javascript objects and stored within an array rather than using the dom to lookup attributes on html elements.

I had a look through I think the June 2.0 beta js code for the validators. They're still using a variable named 'final' which Mozilla chokes on and persisting with document.all rather than getElementById - so Mozilla still won't use client side validators in 2.0 unless this has changed in a later beta. Not sure about the attributes on the validator span elements.


Robert Wellock
on September 28, 2004

Apparently the W3C Validator ceased to work with customised DTD as of May this year which kind of defeats their objectives with XHTML Validation.

Although last year it did work with customised DTD as I created a generic XHTML "embed /" 2003 to INCLUDE into the W3C xhtml1-strict.dtd and it was pleased, although nowadays W3C Validator will spit out errors.

Though I have the luxury of having my own Validating XML Processor which checks against both Schema and Custom DTD.

Obviously "blink" is now CSS and if it weren't for a certain large market-share browser I would have used "object" element quite happily.

Albeit customising the "span" seems rather strange as it's a generic style container.


Konstantin
on October 12, 2004

Well, here is my 2 cents.

I think custom DTD is far better approach then custom JavaScripts. There is a simple reason for this statement - validation controls run both client and server side and that is incredibly handy for situations where client-side scripts are disabled.

Yes, is it possible to write a javascript to attach validation on the fly with no extra tags, but you not only spend precious time on doing so, but spend some extra time writing the same logic all over again for the server side. It is very common now days to receive request that you cannot trust (for hackers it is a snap to submit a form bypassing your "all-in-javascript validation"). So, essentially, this mean double work.


max
on October 12, 2004

What about a XHTML 1.1 module for ASP.NET? Would that work or can it only be a new namespace and/or new set of elements/attributes?


Milan Negovan
on October 13, 2004

What module are you talking about?

The custom DTD I created for this post only effects validation results, nothing else.


Wole
on December 1, 2004

Your page is still not valid!


Milan Negovan
on December 1, 2004

Well, I don't enforce compliancy on the comments. Or would you like me to force people to enter comments in proper XHTML? :)


Mike Gale
on June 9, 2005

I'm looking at the BETA of version 7 of the CSE validator.

Albert has included handling for some markup emitted by ASP.NET (1.1).

Those changes originated from thinking that started with this post!