Remastering Web Form Templates

By Milan Negovan

Print

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."

Discuss

Liked it? Hated it? Discuss this article