This doesn’t mean XHTML is better. Strict coding guidelines can be implemented for HTML, but browsers are much more forgiving of typos and missing tags with HTML.

The W3C has also stopped development on XHTML 2.0 and is directing it’s resources to HTML 5.0. This means XHTML will never grow beyond it’s current capabilities. HTML 5 will be the future language of the Internet, so using HTML now will provide better future compatability.

Another benefit of HTML is avoiding the MIME issue. All versions of IE, including 8, don’t support the XHTML specified MIME type application/xhtml+xml. Instead IE reads the page as text/html and will render the page if it follows the HTML compatibility recommendations. Web developers have been calling on the IE development team to implement the W3C specfications, but the team decided against it during the development of IE7.

Once the language is decided, developers have to decide on implementing a ’strict’ or ‘transitional’ version of the language. With either HTML or XHTML the strict version has deprecated elements and attributes, while the transitional version will allow those elements and a looser interpretation of the rendering rules.

All web pages must have a valid DTD (Document Type Definition) on the first line of the page in order to control the rendering mode of all modern browsers. The DTD or DOCTYPE describes the language used and the strict or transitional version.

All modern browsers have two basic rendering modes: quirks and standards. All modern browsers will render in standards-compliant mode if a valid DTD appears as the first line of code in a page. Obviously, standards provides the most predictable results and similar rendering amongst browsers. It should always be the benchmark designed for, unless you are dealing with legacy code that requires deprecated elements or attributes.

Both the strict and transitional versions of the DOCTYPE will cause the browser to use standards mode, but a typo in the DOCTYPE will cause quirks mode to be used. In IE6, the inclusion of an xml declaration will trigger quirks mode even if the DOCTYPE is correct.

Quirks mode in IE6 will cause the browser to revert to IE 5.5 rendering mode and IE7 quirks mode will do the same since it will render in IE6 quirks mode.

One easy way to tell if a browser is using quirks or standards mode is with a short JavaScript code:

function testRenderMode() {
alert(document.compatMode);
}
You can also add the preceding code to a bookmark by right clicking here for easy access.

Thanks to Ingo Chao for the link and information about quirks mode.

Here are several rules for the use of Themes:

Skin files should be replaced by CSS files, because CSS more closely follows web standards, maximizes caching of CSS files in browsers, reduces bloated web pages and the extra processing time used to add control properties to every control affected. You also loose the separation of content and presentation, because the properties of skin files are written in the page with the control itself.

Skin files are used to change the appearance only of ASP controls and not their behavior. They can have any naming convention, but it is recommended to name them after the control they affect, if one skin file is applied to a control. Multiple controls can have their appearances changed by one skin file.

The controls assigned in a skin file, must have a runat=”Sever” command and for granular control they can have a SkinID attribute to assign the appearance to only those controls that also have the SkinID attribute. The control must be a matching control of the skin file. If no SkinID is named, the skin is called a default skin and only one default skin is allowed to apply to a change.

The theme can be assigned at the page level with a Theme=”name of folder” in the page directive. To assign on a directory wide level, you can assign themes in the web.config file with <pages theme=”name of folder”/>

You can also use StyleSheetTheme in the same fashion. StyleSheetTheme behaves more like CSS files, because the properties set in a Theme file will be overridden by any control properties set on the page itself. With a Theme, all local properties set on controls will be ignored.

You can override themes on a page with the EnableTheming=”false” in the page directive.

Any CSS found in Theme folders will be automatically applied if the theme is called, and ASP controls can have classes applied with the CssClass property.

If you have CSS files in the theme folder, be sure to watch how they are named, because they are imported in the page alphabetically, which means any properties set in a file named zebra.css will overwrite properties in a file named apple.css.

It is possible to dynamically assign themes. If you assign a theme with page directives, you will have to use the Page_PreInit event of the page life cycle, but if you use CssClass, you can use the Page_Load event.

You can use a dropdown list with the CssClass method, because the control tree has been created after the PreInit event and before Load, so you can use the following code in the Page_Load: control.CssClass = dropdownlist.SelectedItem.Text.

With the PreInit method you can use a hyperlink to send a querystring and then access it with: Profile.userTheme = Request["Theme name"] and then use a switch case to move through the variables and finish with Theme = Profile.UserName.

Of course you will need to add the following to the web.config file:
<profile>
<properties>
<add name="UserTheme"/>
</properties>
</profile>

Validation controls can be use with any other control that has the ValidationProperty attribute.

Check the value of Page.IsValid in the Page_Load method to test the values of all the Validation controls on the page.

There are six Validation Controls: RequiredFieldValidator, RangeValidator, CompareValidator, RegularExpressionValidator, CustomValidator and ValidationSummary.

Validation is performed on both the client and server sides. Validation can be turned off on the client with the setting EnableClientScript=false

There are three Display properties for the Validation Controls: Static (default), CSS Visibility property is set to hidden, space on web page taken up even if no message displayed; Dynamic, CSS Display property is set to None, space is used on the web page on if the message is displayed and None with the error displaying in the ValidationSummary.

The Text attribute will accept any HTML string, so it can be used to display an image. Ex: <img src=’filename.gif’ alt=’Name is required’ />

The ValidationGroup attribute allows for more than one form entry on a page, but it needs to be added to all the Validation controls and the button controls. Especially critical with Web Parts.

Controls can have more than one Validation Control assigned to them, and controls are assigned with the Validation Control’s ControlToValidate attribute.

To ensure the proper usage of a Cancel button add the CausesValidation=’false’ attribute so no validation will occur when the button is pressed.

With the RequiredFieldValidator use an InitialValue attribute when tied with a DropDownList to ensure user has selected a value other than the default value.

RangeValidator can use a DataType attribute to check the data type of the form field. Default setting is String.

There are three types of CompareValidator: Data Type, Fixed Value and Control comparison. The attributes are Type, ValueToCompare, ControlToCompare. Operator is a necessary value to determine how to compare. There are seven operator values: DataTypeCheck, Equal, GreaterThan, GreaterThanEqual, LessThan, LessThanEqual, NotEqual.

When working with Dates, the CompareValidator checks the Short Date format: MM/DD/YYYY, and for currency no symbol is used.

CompareValidator can be used in the Page_Load method. Ex: cmpDate.ValueToCompare = DateTime.Now.ToString(”d”). The control still needs an operator and Type.

RegularExpressionValidator uses the ValidationExpression to validate with a regular expression supplied by the programmer. Regular Expressions are available at regexlib.com Visual Studio 2008 also has several regular expressions available when users open the ValidationExpression property.

The ValidationSummary shows the text set in the Validation control’s ErrorMessage property. If nothing has been set in the Text property, the ErrorMessage property will display in both the ValidationSummary and the Validation control section of the page. If Display=None than the message only appears in the summary.

There are three Display properties for the ValidationSummary: BulletList, List and SingleParagraph. There are three other properties for the summary: HeaderText, text above the summary display; ShowMessageBox, uses a popup alert box; and ShowSummary to control display of the summary.

Their are four settings for cookieless: AutoDetect, UseCookies, UseUri and the default UseDeviceProfile. The default will only check the browser capabilities files in ASP.NET to see if the user’s browser supports cookies. AutoDetect will actually probe the user’s browser to see if the user has disabled cookies after checking the browser profiles. Either setting can send the authentication token as part of the URL, but AutoDetect is the only setting that will work with those users who have disabled cookies. The UseUri will automatically send the token through the Uniform Resource Identifier (the last section of the URL), but the token will be part of any bookmark of URL emailed by the user.

To set a custom cookie, developers must use the Response.Cookies method and access the Value property. Developers also have the Expires, Domain and Path properties to fine tune their cookie. Examples:

Response.Cookies["name of cookie"].Value = "5"; // all cookie values are stored as strings
Response.Cookies["name of cookie"].Expires = DateTime.Now.AddDays(1);
Response.Cookies["name of cookie"].Path = "/myfolder"; //cookies will be sent to server only for pages located in myfolder
Response.Cookies["name of cookie"].Domain = "mysite.com" //cookies limited to domain or subdomains only
Response.Cookies["name of cookie"]["value name"].Value = "value" //for holding multiple values in one cookie

You can even limit the cookie to a single server by using the hostname of the server in the Domain property. If you don’t set an Expires property, the cookie will be automatically deleted when the user closes their browser. You cannot delete a cookie on a user’s computer, but you can overwrite it and then set a date in the past (DateTime.Now.AddDays(-1) to have the browser delete the cookie.

To check if the user already has a cookie and then access the cookie use the following:

if (Request.Cookies["name of cookie"] != null)
label1.Text = Server.HtmlEncode(Request.Cookies["name of cookie"].Value);

Just remember, Request is from the user and Response is being sent to the user. Sessions are also dependent on cookies and can set the cookie encoding to be sent through the URI with sessionState cookieless = “true”

If you have tracing set up in your web.config file, you can use trace.axd to track and debug cookies.

Fritz Onion of PluralSight.com has a tool to decode the ViewState called appropriately ViewState Decoder. Version 2.2 works with ASP.NET 2.0 web pages. It is available on Pluralsight’s Tool page.

Another free tool built by Nikhil Kothari from the ASP.NET team is called the Web Development Helper. It’s capabilities go far beyond just viewing the ViewState payload. It’s also browser centric. The tool can be found at Nikhil’s web site.

At the page level, the developer can use the Page_Error event handler, and at the code level, developers can insert try... catch...finally blocks. These blocks are resource intensive, so they should be used carefully on critical code only, like database connections. Incorrect user input is so common that you shouldn’t be handled with catch blocks, but with if statements.

The Page_Error handler isn’t recommend to handle exceptions, and developers should turn to the Application_Error handler. It should also be remembered that you cannot access controls with the Page_Error, because it is called before any controls have been created.

The developer can decide whether to add handling instructions in global.asax and/or web.config with the appropriate .aspx pages to handle the exceptions. If you go with the global.asax file you will use the Application_Error method and to redirect users the Server.Transfer method is considered best practice compared to Response.Redirect, because the Server.Transfer will not create as much traffic. The Response.Redirect makes a call to the client asking the browser to make the request for a new page, while the Server.Transfer will automatically call the new page.

The global.asax code will resemble the following:

void Application_Error(object sender EventsArgs e) {
Server.Transfer("handleError.aspx");
}

In the .aspx page, you will have a Page_Error method similar to the following:

private void Page_Error {
Trace.Write("Error" + Server.GetLastError().Message);
Server.ClearError();
}

Trace.Write is the best option, because it will be seen only by the developer, as long as you are sure to have localOnly="true" in the web.config page.

HTTP errors directed at .aspx pages can also be handled with the web.config settings under <custom Errors>. Errors on web pages ending with .htm or text files will not benefit from this setting, because the IIS server will never turn over the handling of these pages to asp.net, so the customErrors settings will never be consulted.

The first places to go for HTML and CSS validation are both from the World Wide Web Consortium (W3) organization. The HTML validator is at validator.w3.org and the CSS validation is available at jigsaw.w3.org. W3 also has a web site dedicated to accessibility called the Web Accessibility Initiative

Developers at WebAim.org (Web Asccessibility in Mind) have created WAVE, a web accessibility evaluation tool that uses icons and indicators on your web page to show as close as possible how accessible your web content is. The tool has 28 new accessibility tests, including more detailed evaluation of those missing alt text issues. It works like the W3 tools. You can paste a URL into the web tool, upload a file or paste HTML directly into the tool.

For Visual Studio developers you can check accessibility without leaving your IDE. With an .aspx page or HTML page open, go to the tools menu, and the first option available is Check Accessibility. The tool will check your page against the standards set by the WCAG Priority 1 and 2 and the Access Board Section 508.

Several free tools are available at the Web Accessibility Tools Consortium (WAT-C), including a browser plugin for IE (including IE7 and Vista) that provides several different perspectives of your web page and also eases the use of 3rd party online applications. That latest version is 2.0 beta and in the latest version no functions use external scripts and most work with javascript disabled.

Notes!

- ViewState is case sensitive so ViewState["myKey"] != ViewState["mykey"]

- ViewState can create a lot of encoded text at the top of your page, creating potential issues with search engine spiders and your page’s SEO.

- While the ViewState value appears as a long string of random ASCII characters on the client side. It is easy to decode on the client side by default. The Page directive can be used to encrypt the string, but it increases server load, so it is best practice to keep sensitive data out of the ViewState.

A web user control combined with ViewState can be an effective way to store user information over an entire web site. A class can be set up to read info from a database and then store the info inside the ViewState. The class must be made serializable to allow storage of information in the ViewState. This is simple to comply with, by inserting the C# code [Serializable] command at the top of the class after the using statements and before the namespace of the class.

T o use the class and insert the properties in the ViewState only take a couple lines of code using C#:

ClassName holder = new ClassName();

this.ViewState["NameofClass"] = holder;

Pulling the data out of the ViewState is only a few more lines of code:

ClassName holder2 = new ClassName();

holder2 = this.ViewState["NameofClass"] as NameofClass;

Then populate the web user control:

label1.Text = holder2.property (add a .ToString if the value pulled out is not a string.

The web user control can be placed on any number of pages, and the ViewState will be utilized to provide a ’stateful’ option for web developers. The ViewState connection will need to be run on the Page_Load event of the user control, because the ViewState isn’t formed until after the _Init events. You will also want to check the status of the ViewState in the user control to ensure the database isn’t called when the info is already stored in ViewState.

The code to check is even simpler:

if (this.ViewState["ItemName"] == null) or if !(this.ViewState["ItemName"])

I will also use this blog as a learning resource to record the techniques and best practices I discover  from the various sources I come across from books, magazines and the Internet. I will record those sources along with my notes to create an online knowledge base for future reference and study.

I am pursuing a career as an ASP.NET developer so the great majority of information on my blog will focus on the Microsoft technology. But my blog won’t be limited to ASP.  I have experience with PHP and most of the Adobe (and former Macromedia) product line. I think Flex and AIR have great potential and I will continue to study those languages, products and technologies.