Remastering Web Form Templates

Posted on April 18, 2004

11 comments

Visual Studio.NET comes with a number of templates for all kinds of coding occasions. The one I'm going to talk about in this article is the one you probably use most often (provided you are an ASP.NET developer): the Web Form template. Default templates suffer from being stuffed with needless markup. In this article we'll analyze what is supposed to be there and learn how to clean them up.

There are two ways to add a web form to your web project:

  1. Go to the Projects menu and select "Add Web Form...", or
  2. Right click on the web project in the Solution Explorer, select Add | Add Web Form...

Both steps lead you to the same window where you pick Web Form and type a new page name. Voila! You have a web page that is all ready to go, and you accomplished it in under 30 seconds! We tend to forget and not appreciate how easy it is.

Even though creating new pages this way is quite efficient the template itself is littered with unnecessary stuff. From this point on we will look as each and every piece of a brand new web form and figure out how we can improve it by cleaning it. In magazine articles they call it "exposing", or "dissecting", or "debunking". I call it remastering just like they remaster old movies.

The @Page directive is perhaps the most important page of a web form. In my opinion this is what makes an old-school HTML page different from an object-oriented web form. This directive is for the ASP.NET parser and compiler. Once the page is rendered and delivered to the user there's no trace of this line anywhere. The @Page directive designates a code-behind file for the web form at hand. If you don't understand the concept of code-behind or automatic event wire-up, please research these subjects once you're done with this article.

Looking at a new web form I don't understand why some HTML tags are in upper-case and some are not. If you're developing an XHTML page all tags, ids, etc, should be lower-case. The VS.NET Designer seems to insist on the upper case, though, and capitalizes tags for you.

Next, let's examine the page heading. This is what you get by default:

<meta name="GENERATOR" content="Microsoft Visual Studio .NET 7.1">
<meta name="CODE_LANGUAGE" content="Visual Basic .NET 7.1">
<meta name=vs_defaultClientScript content="JavaScript">
<meta name=vs_targetSchema «
         content="http://schemas.microsoft.com/intellisense/ie5">

I found some documentation on the vs_defaultClientScript tag and vs_targetSchema. For example, vs_targetSchema reflects which browser the HTML document will be designed for. This targerSchema setting prescribes how page controls will be positioned when in GridLayout (more on this in a second): with inline CSS or within tables. This same property affects the behavior of the Designer itself. Sounds like a noble cause.

I'm very uncomfortable with these four meta tags and here's why:

  1. When a page is rendered they stay on the page. Consequently the page contains meaningless junk, which is of proprietary nature too.
  2. The tags add up to the overall page size. Basically, they are dead weight.
  3. You don't want to use the HTML designer. It's been a well-known bug with both VS.NET 2002 and VS.NET 2003. When you switch from the HTML view to the Designer view your markup gets maimed beyond recognition. All the efforts you took to nicely indent tags are wasted. There's hope, though (see VS.NET - Designer's "Best" Friend).
  4. The list of target schemas is strangely short. All you really have there are 3 schemas of antiquated browsers and 2 schemas for compact framework. Not much considering the browser zoo a serious designer has on this/her box.

Given all this what exactly are we losing if we delete those four meta tags? Nothing. We don't gain anything by using any of the five schemas. The Designer view doesn't do its job anyway so why grease it? On top of that I'd rather not have VS.NET try to format my pages for me. I'm in control here.

What about vs_defaultClientScript? Documentation states:

The defaultClientScript property of an HTML document sets the default scripting language used by client-side <SCRIPT> elements.

All this allows you to do is pick between JavaScript (strangely enough, it shows JScript in the Properties window) and VBScript. You've got to be kidding to use VBScript as your default client-side scripting language these days, when interoperability means so much.

The two remaining meta tags are self-explanatory, even though I don't know who cares to know that content was produced by "Microsoft Visual Studio .NET 7.1" as great as VS.NET is. I understand VS.NET itself may need these tags, but why not strip them out?

The bottom line is we get rid of the 4 lines we've been talking about. Let's move on.

The MS_POSITIONING attribute the <body> tag is decorated with is what I object to the most. I think it was a bad idea to include it. When this attribute is present, the Designer allows you to arrange controls Visual Basic 6-style. You drop a control on a page and it stays where you put it. Seems unbelievable for novice ASP.NET developers. You can build web forms just like Windows forms!

There's a price to pay for this convenient feature. I simply put an edit field and a button on the page. Here's my HTML now:

<TABLE height="169" cellSpacing="0" 
cellPadding="0" width="484" border="0" ms_2d_layout="TRUE">
    <TR vAlign="top">
      <TD width="328" height="112"></TD>
      <TD width="156"></TD></TR>
    <TR vAlign="top">
      <TD height="32"></TD>
      <TD><INPUT type="text"></TD></TR>
    <TR vAlign="top">
      <TD height="25"></TD>
      <TD><INPUT type="button" value="Button"></TD></TR> 
  </TABLE>

This is with the Netscape Navigator 4.0 schema. If I switch the schema to Internet Explorer 4.0 I get this:

<INPUT type="text" style="LEFT: 328px; « 
POSITION: absolute; TOP: 104px"><INPUT type="button" « 
value="Button" style="LEFT: 328px; POSITION: absolute; « 
TOP: 144px">

This is a simple form with two controls! Both code samples are examples of utmost coding mess! Again, I don't get why casing is so messed up. The rule of thumb is write CSS styles in lower case.

The point I want to strongly get across is this: you DO NOT design web pages laying out controls like VS.NET did for you. Windows forms and web forms are two different beasts from completely different worlds. I can afford to say it because I've done a great deal of both. There's nothing wrong with absolute positioning with CSS. To the contrary, check out beautiful designs at the CSS Zen Garden. Most of them are done with absolute positioning but it's accomplished with well thought-through layouts. You control positioning either via an external or embedded stylesheet. Not the kind of hodge-podge code you see above.

Same goes for table layouts: tables are for tabular data! Quit abusing tables for presentational layout.

So what changes are we making to the template? We remove MS_POSITIONING="GridLayout".

Let this be your priority #1: remove MS_POSITIONING="GridLayout". If you've already added controls strip the style attributes or untangle table tags. Keep it clean. Keep it simple.

Now is the time to add what the web form template is supposed to contain. We can debate what is relevant and what isn't until cows come home. What follows next is my take on "effective simplicity". Here's what I suggest you include:

  • Page title is a must for search engines (SE). Don't get your hopes high with the keywords meta tag—these days major search engines ignore them. Page title matters a great deal. Run a Google search and see what comes up in the search results. Page titles, for the most part. The subject of page titles merits an article of its own which—coincidentally—was published at SitePoint as I was proof-reading this text. Please see The Importance of the Hypertext Document Title.
  • A content-type meta tag. I suggest you always include it to designate content type and encoding.
  • A description meta tag. Doesn't affect your position in search results but it's good practice to include it.

That's really it. You might want to add a few more meta tags, such as author, robots, etc, but they aren't critical. The rest is your magic—high quality content.

Search engines live off of it. Don't regard this as extensive advice on search engine optimization (SEO), but this practice has proven to be successful. Besides, always be on the lookup for "page fat" that needs to be burned. Don't bloat your pages with junk just because everybody does it. Remember, each search engine has its own preferences as to meta tags and often times doesn't play by the conventional rules. This is why I prefer to include the bare minimum of page structure.

What are we left with after all? I've put together an online tool to help you generate web forms. All you need to enter is a namespace name, class name, page title (optional) and description (optional). A hypothetical page produced by the template generator looks as follows:

<%@ Page Language="c#" Codebehind="SampleClass.aspx.cs" «
AutoEventWireup="false" Inherits="AspNetResources.Web.SampleClass"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0«
Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
 <title>This is a sample page</title>
 <meta name="description" content="This page does nothing so far"/>
 <meta http-equiv="content-type" content="text/html; charset=utf-8"/>
</head>
<body>
  <form id="Form1" method="post" runat="server">
  </form>
</body>
</html>

Nice and clean. There is a lot of room for improvement, and if you would like to make a suggestion, please drop me a line.

Conclusion

This article was meant to be a wake-up call. I've been developing in ASP.NET for quite a while now but haven't seen anyone urge developers to consider what's relevant in web form templates and what's not. VS.NET is great and templates are extremely helpful but not all that shines is gold. Go back to basics. If you include a meta tag, read up specs and learn what it means. Do you want your site positioned well with search engines? Learn how to structure pages to help bots index you better. (Don't even think about spamming them with shady techniques!) Code for "effective simplicity."

11 comments

Michael Khalsa
on April 21, 2004

Personally, i also never design in VS.net. My approach is to use Dreamweaver, then i cut and paste the section between body tags to vs.net. If i make a change, i make it to the dreamweaver side, and do another cut and paste. Not very elegant, but it works.

(one advantage of this, is that i have created a backup of my desing, i.e., one in dreamweaver and one in vs)

I also experience dreamwever (mx 6.1) to be lacking, while it has some great property windows, the program itself shows poorly written code, and code formatting problems, so for important pages - its always back to hand coding for touching up the html.

IN my opinion, the market is still open for a great wysiwyg designer, perhaps someone could make a plugin to work with vs.net

For bandwidth savings, something i have thought about is stripping away all the unecessary spaces, tabs, etc from pages which are frequently downloaded.

Michael


Ezequiel Espíndola
on September 28, 2004

Nice article, Milan.

I think you probably know it already, but someone could make use of this. You can avoid copying and pasting your own template by modifying the default one.

If you're using C#, just go to C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\VC#Wizards\CSharpAddWebFormWiz\Templates\1033 and modify WebForm1.aspx there. Make a backup copy first just in case.

Now, whenever you do Add Web Form... your template will appear.

This quick and dirty solution works pretty fine, but for a cleaner one, Enterprise Templates could be used.

Ezequiel


Milan Negovan
on September 28, 2004

There's a HUGE chunk of documentation on how to roll out your own enterprise templates. I managed to read through all of it at one point. It was cumbersome, to say the least. I hope they simplify it somehow. Even that stand-alone tool you can download from Microsoft (I can't recall its name) doesn't make it any easier.

One of my readers said he was going to rewrite standard templates and publish his finding on his site, so I've been waiting to hear from him to avoid doing double work.


Dylan Thomas
on January 18, 2005

Thanks for this post. I've starting using your tool and will take the suggestion of altering my default aspx template in VS.NET. I must say that working with CSS rather than Grid Layout or tables all over the place is fairly hard work (I design online mapping tools that have a LOT of buttons, widgets, DHTML), but seems to be worth the efforts. Thanks again.


David Rhdoes
on February 16, 2005

In addition, some of the VS meta tags provide intellisense support so are useful for development


Kumanan Murugesan
on May 03, 2005

Hello Milan,
Your article was really good. I got some solution to the problems which I had in VS.NET particularly CSS compatibility. I liked the comment of Ezequiel Espíndola too.


Anon
on March 22, 2006

Silly. You mention meta tags taking up valuable bits when rendered from the server? Gimme a break, those tags are not even material compared to the damn page view state that is generated on your behalf thanks to crappy webcontrols that everbody seems to abuse - why don't you concentrate on something like using regular input tags and reducing the size of the viewstate or eliminating it all-together, or how about inheriting all your pages from a parent page class and modify the default templates as one astute reader already knew about, or screw it use perl or cgi-scripts - oh wait you wouldnt know about any of that because all you web types are worried about is text formatting only - nevermind what really works. You web types make me laugh with your dream weaver and pretty tools - if you can't do it in emacs, vi or notepad then maybe you should find another career!


kapil
on March 25, 2006

i need some Asp form desing Tool,I've starting using your tool and will take the suggestion of altering my default aspx template in VS.NET. I must say that working with CSS rather than Grid Layout or tables all over the place is fairly hard work (I design online mapping tools that have a LOT of buttons, widgets, DHTML), but seems to be worth the efforts. Thanks again.


darklinux
on May 03, 2006

the problem in asp.net that there is no tamlate engine
same in php we have smarty
mey be soon we might fine asp.net tamplate engines
still master pages can be handy for the current time
peace
:)


newkidonthe.netblock
on August 04, 2006

This article has confirmed to my decision of doing away with ms_positioning property and other problems... So i could let my team know something.. But i have one problem though... i am not able to make a screen irrespective of client resolution... i need u to pull me out of this .. i do not want to use CSS stuff... i have been able to achieve this for all control in ASp.net by taking out ms_positioning property , postion:absolute and providing a tag for my body.But when i add HTML Table control and aligning to center does not adjust to screeen size... For eg: if i have a label control on top as header and i build a HTML Table control beneath it within which rests a login control namely 2 test boxes and submit button.... in 800*600 i get it properly but when i change it to 1024*768 Label control header adjusts to center of the now larger space... but Table control beneath it maintains almost the same left and does not adjust...
Could u help me out
Thanks


Damon Allison
on February 20, 2007

Nice article, thanks. I'm not a fan of the 'default' meta tags either. I liked the rant by "Anon", including the use of viewstate killing performance, it's so very true. As an emacs devotee I feel there is a whole lot of truth to the 'being able to do it in emacs' mantra.

In my opinion, I think these proprietary 'extensions' that are being added are killing productivity. I shouldn't need vs_targetSchema for visual studio to recognize a 'class' attribute or 'link' tag, which are valid html. The bloat of these tools (vs.net sp1 takes 1-1.5 hours to install, what!!?) is extremely counterproductive.