ASP.NET 3.5 SP1 is the overriding technology that makes the site work. This runs on the web server and takes advantage of the functionality provided by the .NET Framework. However, ASP.NET does not run on the user's computer; instead, it dynamically generates the elements that a browser uses to render a page. The elements that are sent down to the browser consist of HTML, images, and Cascading Style Sheets (CSS), which provide colors, sizes, and alignments for various items in the HTML. ASP.NET also generates some JavaScript procedural code that is also sent down to the browser to handle data validation and to tell the browser how to interact with the web server.

HTML is created in several ways. You can use the visual form designer in Visual Studio to drop controls onto the form, and this automatically creates the markup for the controls that ultimately emit HTML. You can hand-edit or author your own HTML code in the .aspx files to give it features that aren't easily specified in the form designer. Last, HTML can be dynamically generated by your code or by classes in the .NET Framework, HttpHandlers are the best example of this.

It is not possible to give an exhaustive explanation of CSS in this book, but I'll cover some of the general concepts. You should consult other sources for complete details about CSS. The purpose of CSS is to specify how visual HTML tags are to be rendered by specifying various stylistic elements such as font size, color, alignment, and so on. These styles, called Selectors, can be included as attributes of HTML tags, or they can be stored separately and referred to by Class, by ID or by defining a rule for a specific HTML element.

Sometimes HTML files have the styles hard-coded into the HTML tags as attributes, as in the following example:

<div style="align: justify; color: red; background-color:
yellow; font-size: 12px;">some text</div%>

This is bad because it is difficult to modify these stylistic elements without going into all the HTML files and hunting for the CSS attributes. It also adds volume to each page being downloaded, thus hurting the overall perceived performance of the pages. Instead, always put the style definitions in a separate stylesheet file with an extension of .css; or if you insist on including styles inside an HTML file, at least define them in a <style> section at the top of the HTML file.

Maintaining style definitions in a separate stylesheet file makes the site more maintainable, increases performance and minimizes the administrative effort required to maintain styles and to enforce a common look and feel among many pages. You often hear the term "separation of concerns" in terms of application architecture; it applies to web development of user interfaces with CSS. The idea is to separate as much of the design concerns from the application code as possible. Keeping styles in a file means that there is only one place where you need to manage elements when you need to adjust a style. Using inline style definitions is no different from repeating a routine multiple times in code. In programming terms, it means that you can refactor a style definition to a central location instead of repeating it in each page of markup. This is a common theme you will see in modern ASP.NET with the use of master pages, themes, and user controls.

Let's assume that the client wants to change some styles of a site that's already in production. If you've hard-coded styles into the HTML elements of the page, then you'd have to look in many files to locate the styles to change, and you might not find them all, or you might change something else by mistake — this could break something! However, if you've used style classes stored separately in CSS files, then it's easier to locate the classes that need to be changed, and your HTML code will be untouched and safe.

Furthermore, CSS files can make a site more efficient. The browser will download the CSS file once and then cache it on the client. The browser will use the cached instance of the .css file and not download all the styles again, so each subsequent request will be much smaller, and therefore faster to download. In some cases, this can dramatically speed up the loading of web pages in a user's browser.

On top of downloading fewer resources, this can also help with rendering tables, which browsers do more slowly than a series of DIV and SPAN elements. That's because browsers wait until the entire contents of a table have been downloaded before rendering it to the user. Tables are good for tabular data, and that is what they should be used for. While using stylesheet layouts is tougher to become familiar with, it can be a much more flexible way to create a site layout.

While many sites use multiple stylesheet files, I personally like to have just one. The reason is that each file will need to be downloaded and thus add to the time required to download the content. While the hit may seem to be negligible, it all adds up. On the flip side, organizing related styles into specific files can be very helpful in managing styles. It can also add to confusion and duplication of styles, meaning that efforts get overwritten during rendering. The ultimate choice will come down to the needs of the application and your personal management style.

When you group CSS styles, you can create Selectors, which syntactically resemble classes or functions. You can assign them a class name, preceded by a period (.), to allow them to be referenced in the class= attribute of HTML tags. You can also associate an HTML element with an element name simply by creating a style rule with the same name as the element. For example, H1 maps to the <h1> element. You can also refer to specific elements by their client-side ID; just precede the name of the style rule with a # followed by the ID of the element. Finally, you can combine class, element, and ID selectors to create complex style rules.

If you use a stylesheet Selector, an ID, or element selectors, and you want to change the font size of all corresponding HTML elements, you only need to find that style rule and change that single occurrence in order to change many visual HTML elements of that given type. If the stylesheet is defined in a separate file, you will benefit even more from this approach, because you will change a single file and n pages will change their appearance accordingly.

Here is an example of how you can redefine the style of a DIV object by storing it in a separate file named styles.css. First, define a new class called mystyle in a file called mystyles.css as follows:

.mystyle
{
   align: justify;
   color: red;
   background-color: yellow;
   font-size: 12px;
}

Then, in the .aspx or .htm page, you will link the CSS file to the HTML as follows:

<head>
   <link href="/styles.css" text="text/css" rel="stylesheet" />
   <!-- other metatags... -->
</head>

Finally, you write the HTML DIV tag and specify which CSS class you want it to use:

<div class="mystyle">some text</div>

Note that when the style was declared, I used the dot ( . ) prefix for the class name. You have to do this for all of your custom style Selectors.

If you want to define a style to be applied to all HTML elements of a certain kind (for example, to all <p> paragraphs, or even the page's <body>; tag) that don't have another explicit class associated with them, you can write the following specification in the stylesheet file:

body
{
   margin: 0px;
   font-family: Verdana;
   font-size: 12px;
}

p
{
   align: justify;
   text-size: 10px;
}

This sets the default style of all body tags and all <p> (paragraph) tags in one place. However, you could specify a different style for some paragraphs by stating an explicit class name in those tags.

Yet another way to associate a Selector to a HTML object is by ID, which you will see used as we start defining the layout for the new Beer House site. You define the Selector name with a # prefix, as follows:

#header
{
   padding: 0px;
   margin: 0px;
   width: 100%;
   height: 184px;
   background-image: url(images/HeaderSlice.gif);
}

Then you could use the id attribute of the HTML tag to link the CSS to the HTML. For example, this is how you could define an HTML division tag and specify that you want it to use the #header style:

<div id="header">some text</div>

You typically use this approach for single objects, such as the header, the footer, the container for the left, right, center column, and so on. If you need to apply a style to multiple elements in a page, use a class Selector.

Finally, you can mix the various approaches. Suppose that you want to give a certain style to all links in a container with the sectiontitle style, and some other styles to links into a container with the sectionbody style. You could do it this way:

In the .css file

.sectiontitle a
{
   color: yellow;
}

.sectionbody a
{
   color: red;
}

In the .aspx/.htm file

<div class="sectiontitle">
<p>some text</p>
<a href="http://www.wrox.com">Wrox</a>
<p>some text</p>
</div>

<div class="sectionbody"<
<p<some other text</p<
<a href="http://www.wiley.com">Wiley</a>
<p>some other text</p>
</div>

Often developers will use HTML tables to control the positioning of other items on a web page. This was considered the standard practice before CSS matured, but many developers still use this methodology today. I admit it took me a long time to make the switch. Although this is a very common practice, the W3C officially discourages it (www.w3c.org/tr/wai-webcontent), saying "Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen readers." In other words, HTML tables should be used for displaying tabular data on the page, not to build the entire layout of the page. For that, you should use container elements (such as DIVs) and their style attribute, possibly through the use of a separate <style> section or a separate file. This is ideal for a number of reasons:

Note that the preceding discussion refers to avoiding the use of tables for the site's overall layout. However, using tables is acceptable to create input forms with a tabular structure because otherwise too much CSS code would be required to be easily writeable and maintainable. It's also not very likely that you'll need to dynamically change the layout of the input form, so you don't need all the flexibility of CSS for that, and using HTML tables is more immediate.

ASP.NET 2.0 introduced a master page feature that enables you to define common areas that every page will share, such as headers, footers, menus, and so on. A master page enables you to put the common layout code in a single file and have it visually inherited in all the content pages. A master page contains the overall layout for your site. Content pages can inherit the appearance of a master page, and place their own content where the master page has defined a ContentPlaceHolder control.

What actually happens at runtime is that the content of the master page and the content page are merged together as one cohesive unit. Behind the scenes, the master page actually injects itself in the child control hierarchy of the Page class itself (see www.odetocode.com/Articles/450.aspx). If you think about it, this makes perfect sense because the MasterPage class inherits the UserControl class, it is just a special user control in reality.

Once the master page has injected itself into the content page's control tree, it then looks for corresponding Content controls for each of the ContentPlaceHolders declared in the master page's markup. In this action, the overall layout is produced and the page proceeds to build itself as expected. Figure 2-3 illustrates the hierarchy being implemented with master pages.

Figure 2.3. Figure 2-3

All of this magic actually happens after the PreInit event, but before the Init event of the content page. This means that the content page's master page must be set in the PreInit event and not after it. Generally, this will be done in the @Page Directive or the web.config file. But there are occasions where you want to define the actual master page at runtime, such as when you open your site up to layout customizations by the end user. You just have to remember to do this in the PreInit event handler or an InvalidOperationException will be thrown when your page is executed.

An example is worth a thousand words, so let's see how this concept turns into practice. A master page has a .master extension. Because it is an extended version of a UserControl, it can be programmed in the same fashion. The following is code for a master page that contains some text, a header div tag, and a footer div tag. It also defines a ContentPlaceHolder control between the header and the footer:

<%@ Master Language="VB" AutoEventWireup="true"
CodeFile="MasterPage.master.vb" Inherits="MasterPage" %>

<html>
<head id="Head1" runat="server">
   <title>The Beer House</title>
</head>

<body>
<form id="Main" runat="server">
   <div id="header"<The Beer House</div>
   <asp:ContentPlaceHolder ID="MainContent" runat="server" />
   <div id="footer">Copyright 2008 WROX</div>
</form>
</body>
</html>

As you see, it is extremely similar to a standard page or user control, except that it has a @Master directive at the top of the page instead of a @Page or @Control directive, and it declares one or more ContentPlaceHolder controls where the .aspx pages will add their own content. The master page and the content page will merge at runtime — therefore, because the master page defines the <html>, <head>, <body>, and <form> tags, you can easily guess that the content pages must not define them again. Content pages define the content for the master's ContentPlaceHolder controls and nothing else. The following extract shows an example of a content page:

<%@ Page Language="VB" MasterPageFile="~/MasterPage.master" AutoEventWireup="false"
CodeFile="MyPage.aspx.vb" Inherits="MyPage" Title="The Beer House - My Page" %>

<asp:Content ID="MainContent" ContentPlaceHolderID="MainContent" Runat="Server">
   My page content goes here...
</asp:Content>

The first key point is that the @Page directive sets the MasterPageFile attribute to the virtual path of the master page to use. The content is placed into Content controls whose ContentPlaceHolderID must match the ID of one of the ContentPlaceHolder controls of the master page. In a content page, you can't place anything but Content controls, and other ASP.NET controls that actually define the visual features must be grouped under the outermost Content controls. Another point to note is that the @Page directive has a new attribute, Title, that allows you to override the value specified in the master page's <title> metatag. If you fail to specify a Title attribute for a given content page, then the title specified on the master page will be used instead.

Figure 2-4 illustrates the master page feature.

Figure 2.4. Figure 2-4

When you edit a content page in Visual Studio in Design or Split View, it properly renders both the master page and the content page in the form designer, but the master page content appears to be "grayed out." This is done on purpose as a reminder to you that you can't modify the content provided by the master page when you're editing a content page. Figure 2-5 shows the home page in design mode. Notice how its master page is listed in the top-right corner (CRMaster.master), and the elements contained in the master pages are rendered in the editor but are disabled.

Figure 2.5. Figure 2-5

I'd like to point out that your master page also has a code-behind file that could be used to write properties and functions that could be accessed in the .aspx or code-behind files of content pages. This is because the master page is actually a user control, so working in a master page is almost identical to working with a user control.

When you define the ContentPlaceHolder in a master page, you can also specify the default content for it, which will be used in the event that a particular content page doesn't have a Content control for that ContentPlaceHolder. Here is a snippet that shows how to provide some default content:

<asp:ContentPlaceHolder ID="MainContent" runat="server">
   The default content goes here...
</asp:ContentPlaceHolder>

Default content is helpful to handle situations in which you want to add a new section to a number of content pages, but you can't change them all at once. You can set up a new ContentPlaceHolder in the master page, give it some default content, and then take your time in adding the new information to the content pages — the content pages that haven't been modified yet will simply show the default content provided by the master.

Setting the MasterPageFile attribute at the page level may be useful if you want to use different master pages for different sets of content pages. If, however, all pages of the site use the same master page, it's easier to set it once for all pages from the web.config file, by means of the <pages> element, as shown here:

<pages masterPageFile="~/Template.master" />

If you still specify the MasterPageFile attribute at the page level, however, that attribute will override the value in web.config for that single page.

You can take this a step forward and have a master page be the content for another master page. In other words, you can have nested master pages, whereby a master page inherits the visual appearance of another master page, and the .aspx content pages inherit from this second master page. The second-level master page can look something like the following:

<%@ Master Language="VB" MasterPageFile="~/MasterPage.master"
AutoEventWireup="false" CodeFile="MasterPage2.master.vb"
Inherits="MasterPage2" %>

<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
   Some other content...
   <hr style="width: 100%;" />
   <asp:ContentPlaceHolder ID="MainContent" runat="server" />
</asp:Content>

Because you can use the same ID for a ContentPlaceHolder control in the base master page and for another ContentPlaceHolder in the inherited master page, you wouldn't need to change anything in the content page but its MasterPageFile attribute, so that it uses the second-level master page.

This possibility has great promise because you can have an outer master page that defines the very common layout (often the company-wide layout), and then other master pages that specify the layout for specific areas of the site, such as the online store section, the administration section, and so on. Visual Studio 2005 did not have design-time support for nested master pages, making it very difficult to manage development with nested master pages. Visual Studio 2008 has resolved that issue and made working with master pages much easier all around. In this version of the Beer House I will leverage several uses of nested master pages to allow a more flexible design of the site. There will be child master pages to define two- and three-column layouts.

Other improvements around master pages in Visual Studio 2008 make it easier to see how styles are applied to the layout, even through all the layers of master pages. While I tend to spend most of my time working with the layout in the Source View, it is nice to be able to switch to Design View to get a decent idea of how things are actually shaping up without launching the site. Figure 2-6 illustrates the principle of nested master pages.

Figure 2.6. Figure 2-6

You also have the capability to access the master page from a content page, through the page's Master property. The returned object is of type MasterPage, which inherits directly from UserControl (remember that I said master pages are similar to user controls) and adds a couple of properties. It exposes a Controls collection, which allows you to access the master page's controls from the content page. This may be necessary if, for example, in a specific page you want to programmatically access a control on the master page, such as a TextBox, Button, or the like. Accessing the Controls collection directly would work, but would require you to do a manual cast from the generic Control object returned to the right control type, such as a TextBox or Button. A much better, and objected-oriented, approach is to add custom properties to the master page's code-behind class. In fact you can create public properties and functions in a MasterPage's code-behind that can be accessed from the content page. The following example wraps a property to enable or disable personalization. This is what you could write in the MasterPage's code-behind:

Private _enablePersonalization As Boolean = False
Public Property EnablePersonalization() As Boolean
    Get
        Return _enablePersonalization
    End Get
    Set(ByVal value As Boolean)
        _enablePersonalization = value
    End Set
End Property

Now in the content page you can add the following line after the @Page directive:

<%@ MasterType VirtualPath="~/MasterPage.master" %>

With this line you specify the path of the master page used by the ASP.NET runtime to dynamically create a strongly typed MasterPage class that exposes the custom properties added to its code-behind class. I know that it seems a duplicate for the MasterPageFile attribute of the @Page directive, but that's how you make the master page properties visible in the content page. You can specify the master type not just by virtual path (as in the preceding example) but also by name of the master page's class, by means of the TypeName attribute. Once you've added this directive, in the content page's code-behind file (or in a <script runat="server"> section of the .aspx file itself), you can easily access the master page's EnablePersonalization property in a strongly typed fashion, as shown here:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
Handles Me.Load
    If Not IsPostBack Then
        Me.Master.EnablePersonalization = True
    End If
End Sub

When I say "strongly typed" I am implying that you'll have Visual Studio IntelliSense on this property, and that's true: Type Me.Master. and when you press that second period, you'll see your new property in the IntelliSense list!

This methodology of accessing master objects from content pages is particularly useful when you want to put common methods in the master page, to be used by all the pages that use it. If we didn't have access to a strongly typed MasterPage object built at runtime by ASP.NET, you'd need to use reflection to access those methods, which is slower and certainly much less immediate to use (in this case, it would have been easier to put the shared methods in a separate class that every page can access).

You can cast the Master property to the master page type at runtime as well. This comes in handy when you set the master page at runtime. You just have to know what the actual type the master page is for your content page. By doing this, you can access any public members of the actual master page's class, including assigning event handlers.

Another thing to remember when using nested master pages is keeping track of which master page is actually being referenced. If you are using nested master pages then the Master property of the class returns a reference to that master page, not its master page. To access the parent master page, you need to access the content page's master page's master page. Wow! Say that a few times real fast!

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) _
Handles Me.Load
    If Not IsPostBack Then
        Me.Master.Master.EnablePersonalization = True
    End If
End Sub

The last thing I want to describe in this introduction to master pages is the capability to dynamically change the master page used by a content page at runtime. That's right; you can have multiple master pages and pick which one to use after the site is already running. You do this by setting the page's MasterPageFile property from within the page's PreInit event handler, as follows:

Protected Sub Page_PreInit(ByVal sender As Object, ByVal e As EventArgs)
    Me.MasterPageFile = "~/OtherMasterPage.master"
End Sub

The PreInit event was new in ASP.NET 2.0, and you can only set the MasterPageFile property in this event handler because the merging of the two pages must happen very early in the page's life cycle (the Load or Init event would be too late).

When changing the master page dynamically, you must make sure that all master pages have the same ID for the ContentPlaceHolder controls, so that the content page's Content controls will always match them, regardless of which master page is being used. This exciting possibility enables you to build multiple master pages that specify completely different layouts, allowing users to pick their favorite one. The downside of this approach is that if you write custom code in the master page's code-behind file, you will need to replicate it in the code-beside class of any page; otherwise, the content page will not always find it. In addition, you won't be able to use the strongly typed Master property, because you can't dynamically change the master page's type at runtime; you can only set it with the @MasterType directive.

This problem can be mitigated by creating a common base MasterPage class each of the MasterPage variations inherit from. Any common member of the master pages would be contained in the parent class. For example you would want to have the EnablePersonalization property defined in the common base class and, thus, available to any of the master page variations.

While changing a MasterPage at runtime is pretty cool, a more common practice used on the web is changing stylesheets to produce a different layout. Because we've decided to use a table-free layout, we can completely change the appearance of the page (fonts, colors, images, and positions) by applying different styles to it. ASP.NET provides a mechanism called themes to help us accomplish just that.

The dMainHeader DIV is composed of several child DIV elements for the logo, login elements, and theme selection.

<div id="dMainHeader">
            <div id="dLogo"
                <img src="~/images/tbh_logo.gif" runat="server"
alt="The Beer House" enableviewstate="false" />
            </div>
            <div id="dLoginLinks">
                <div id="dLoginMenu">
                    <a id="btnDisplayLogin"
href="javascript:DisplayLoginHandler();"
class="LoginLink">Login</a></div>

<div id="dLogoutMenu">
                    <div id="dUserName">
                    </div>
                    <a id="btnDisplayLogout" href="javascript:logoutHandler();"
class="LoginLink">Log Out</a>
                </div>
            </div>
            <div id="dThemeselector">
                <uc2:ThemeSelector ID="ThemeSelector1" runat="server" />
            </div>
</div>

Each of these elements has further style rules used to define their positioning and visual representations. The dMainHeader uses a background-image (the beer steins from Creative Commons), a height of 80 pixels, and width of 780 pixels. clear is set to both, clearing the element's floating inheritance from its parent element. both designates both left and right clearing.

/* Header Elements */

#dMainHeader
{
    background-image: url('images/bh_header.png'),
    clear: both;
    color: #800000;
    float: left;
    height: 80px;
    padding: 0;
    width: 780px;
}

H1.dMainHeader
{
    font-size: 24px;
    font-weight: bold;
    color: #996633;
}

#dLogo
{
    width: 480px;
    float: left;
    margin-right: 40px;
    margin-left: 40px;
}

#dLoginLinks
{
    width: 200px;
    float: right;
    margin-top: 10px 5px 0 0;
    padding-right: 10px;
    padding-top: 10px;
}

/* Login */

#dLoginMenu
{
    text-align: right;
    display: none;
}

#dLogoutMenu
{
    text-align :right;
    display: none;
}

a.LoginLink:link
{
    padding: 2px 1px 2px 1px;
    color: #FFFFFF;
    font-size: Small;
    text-decoration: none;
    font-weight: bolder;
}

a.LoginLink:visited
{
    padding: 2px 1px 2px 1px;
    color: #FFFFFF;
    font-size: Small;
    text-decoration: none;
    font-weight: bolder;
}

a.LoginLink:active
{
    padding: 2px 1px 2px 1px;
    color: #FFFFFF;
    font-size: Small;
    text-decoration: none;
    font-weight: bolder;
}

a.LoginLink:hover
{
    padding: 2px 1px 2px 1px;
    color: #FFFFFF;
    font-size: Small;
    text-decoration: none;
    font-weight: bolder;
}

/* Themes */
#dThemeselector
{
    text-align: right;

height: 80px;
    padding: 2px;
    font-size: 10px;
    margin-top: 50px;
    margin-right: 10px;
    color: #FFFFFF;
}

#dThemeselector select
{
   color: black;
   background-color: #e1e1e1;
   font-size: 10px;
}

The next section in the header is the site's primary horizontal navigation, composed of a specially styled unordered list (<UL>). There are actually two child DIVs in the dMainNav DIV: dMenu and dSocial. The first DIV is the traditional menu; the second is a series of image links pointing to Beer House pages on various social networking sites. Following is a list of the dMainNav's style properties; they define the background gradient image, dimensions, and position of the element.

#dMainNav
{
    background: url(images/menu_bg.gif) repeat-x;
    float: left;
    padding: 2px 0 0px 0;
    top: 85px;
    height: 28px;
    bottom: 100px;
    left: 1px;
    width: 780px;
    font-family: Arial, Helvetica, sans-serif;
}

The horizontal menu is defined by a series of style selectors applied to the UL and its child elements. The most important rule to notice is the one applied to the list items (<LI>). It defines how each of the list items is rendered in the list, which is inline. This tells the browser not to render the list as a stacked list of elements, but rather as if it is normal text or horizontal. Once this is defined, the remaining rules define the actual appearance, such as spacing, size, and colors for the elements in the list. Collectively, these rules define a list of horizontal links that compose a nice horizontal menu. The resulting HTML output is much thinner than the output of the Menu control, which outputs a large set of nested tables to accomplish the same effect. Similar rules are applied to the dSocial element to display the social site icon links. Following is the HTML markup:

<div id="dMenu">
<ul>
            <li><a href="<% =ResolveUrl("default.aspx") %>">
<span>Home</span></a></li>
                <li><a href="<% =ResolveUrl("showcategories.aspx") %>">
<span>Articles</span></a></li>
                <li><a href="<% =ResolveUrl("ShowDepartments.aspx") %>">

<span>Store</span></a></li>
                <li><a href="<% =ResolveUrl("BrowseEvents.aspx") %>">
<span>Events</span></a></li>
                <li><a href="<% =ResolveUrl("ShowForums.aspx") %>">
<span>Forum</span></a></li>
                <li><a href="<% =ResolveUrl("BrowseAlbums.aspx") %>">
<span>Gallery</span></a></li>
                <li><a href="<% =ResolveUrl("About.aspx") %>">
<span>About</span></a></li>
                <li id="liAdmin"><a href="<% =ResolveUrl("Admin") %>">
<span>Admin</span></a></li>
            </ul>
</div>

Here are the styles applied to the menu:

#dMenu
{
    width: 550px;
    float: left;
}

#dMenu ul
{
    clear: left;
    float: left;
    width: 100%;
    list-style: none;
    margin: 1px 0 0 0;
    padding: 0;
}

#dMenu ul li
{
    display: inline;
    list-style: none;
    margin: 0;
    padding: 0;
}

#dMenu ul li a
{
    display: block;
    float: left;
    margin: 0 0 0 1px;
    padding: 3px 10px;
    text-align: center;
    color: #FFFFFF;
    text-decoration: none;
    position: relative;
    left: 15px;
    font-size: medium;
}

#dMenu ul li a:hover
{
    background: transparent;
    color: #CECECE;
}

#dMenu ul li a.active, #dMenu ul li a.active:hover
{
    font-weight: bolder;
}

#dMenu ul li a span
{
    display: block;
}

The footer section is a collection of two DIVs — one for navigation and one for a copyright notice. The menu is, again, a UL and applies similar style rules as the primary navigation. The other DIV contains the site's copyright notice — more on that later.

<div id="dMainfooter">
<div id="footermenu">
            <ul>
                <li><a href="<% =ResolveUrl("default.aspx") %>">
<span>Home</span></a></li>
                <li><a href="<% =ResolveUrl("showcategories.aspx") %>">
<span>News</span></a></li>
                <li><a href="<% =ResolveUrl("ShowDepartments.aspx") %>">
<span>Store</span></a></li>
                <li><a href="<% =ResolveUrl("BrowseEvents.aspx") %>">
<span>Events</span></a></li>
                <li><a href="<% =ResolveUrl("BrowseAlbums.aspx") %>">
<span>Gallery</span></a></li>
                <li><a href="<% =ResolveUrl("Contact.aspx") %>">
<span>Contact</span></a></li>
                <li><a href="<% =ResolveUrl("Privacy.aspx") %>">
<span>Privacy</span></a></li>
                <li><a href="<% =ResolveUrl("Terms.aspx") %>">
<span>Terms</span></a></li>
                <li><a href="<% =ResolveUrl("SiteMap.aspx") %>">
<span>Site Map
</span></a></li>
            </ul>
        </div>
        <div id="footerCopyright">
            <uc1:FooterCopyright ID="FooterCopyright1" runat="server"
CompanyName="The BeerHouse"
                StartYear="2003" EnableViewState="false" />
        </div>
</div>

There are some more elements that complete the main master page for the login dialog, and those will be explained in Chapter 4. The remaining element is nested between the header and footer elements and contains a ContentPlaceHolder control named MainContent.

There are two more master pages used in the site, plus another for the site's administration. The remaining two master pages; LCMaster.master (2-Column layout with thin right column and left primary content) and CRMaster.master (another 2-Column layout with a thin left column and right primary content). Both of these master pages are nested master pages from the primary master page. Inside each of these master pages is a Content control that corresponds to the MainContent ContentPlaceHolder of the TBHMain.master page. Each of these child master pages contains two DIV elements, one for the primary content of the page and one for a side column with ancillary content. The side column contains a link to the site's overall RSS feed and then a ContentPlaceHolder control that lets the actual page set the remaining content.

<div id='left-column'>
        <div id="dRSS">
            <a href="thebeerhouse.rss">Subscribe:
                <img id="Img1" runat="server" src="~/images/beercap.gif" border="0"
 alt="Follow The BeerHouse via RSS." /></a>
            <hr />
        </div>
        <asp:ContentPlaceHolder ID="RightColumn" runat="server">
        </asp:ContentPlaceHolder>
</div>
<div id='right-main-content'>
        <asp:SiteMapPath runat="server" ID="TBHSiteMapPath"
CssClass="tbhSiteMapPath" ParentLevelsDisplayed="2">
        </asp:SiteMapPath>
        <asp:ContentPlaceHolder ID="CenterColumn" runat="server">
        </asp:ContentPlaceHolder>
</div>

The primary content DIV contains a SiteMapPath control and a ContentPlaceHolder. I'll discuss the SiteMapPath in more detail in the next chapter. I want to point out here the use of a DIV element with a specific name. In the preceding example, the content DIV is named right-main-content. The other child master page uses left-main-content. This allows different style rules to be defined for each element to position them either on the left or right side of the page.

When pages are rendered by ASP.NET, the markup will contain the DIV elements in the desired nesting hierarchy. The reason the columns are contained within a wrapping DIV element is to keep the footer element below the dynamic content rendered by the site. The two columns apply style rules that define their float or horizontal position and their width:

#left-main-content, #right-main-content
{
    background-color:#FFF;
    margin:5px;
    min-height:400px;
    width:570px;
}

#left-main-content

{
    border-right:thin solid #000080;
    float:left;
}

#right-main-content
{
    border-right:thin solid #000080;
    float:right;
}

#right-column, #left-column
{
    background-color: #E6BB70;
    margin: 4px;
    min-height: 190px;
    width: 180px;
}

#right-column
{
    float: right;
    left: 380px;
}

#left-column
{
    clear:left;
    float: left;
    margin-right: 5px;
}

A quick tutorial on the CSS Box Model is in order. Every element in HTML is defined as a box or a rectangle. The position of the box is determined by the Top, Left, Right, and Bottom values, which are either an integer value or a percentage. There are different unit types, but I use pixels (px) throughout this book to keep it simple. Generally I use absolute positioning, but this may vary from relative to static as needed. When absolute positioning is used the values for the position are calculated from the containing element, which would be the body, a DIV, and so on. As you will see by examining the layout of the new Beer House, this helps control where content is rendered (see Figure 2-9).

Figure 2.9. Figure 2-9

In the actual Box Model, there are three important value groups to understand: margin, border, and padding. The margin is the effective space around the box from another element. Think of it as cellspacing in a table. The border defines a line that designates one or more of the sides of the box and can have its style, width, and color defined. Padding refers to the space between the border and the actual content of the element. Effective use of these values enables you to produce some pretty stunning layout effects.

Figure 2-10 shows these concepts being applied to the About page.

Figure 2.10. Figure 2-10

A three-column layout that keeps the footer below all the page's content is often referred to as the Holy Grail of CSS layouts.

The only page in the new Beer House that uses a three-column layout is the home page. I chose to use the two-column layouts on the remaining pages because I wanted more room for the actual content. The home page, however, needs to expose as much content as possible to the visitor, so using three columns on the page — a column on each side of 180 pixels in width and a center column — made the most sense. The difference between a three-column layout and a two- column layout is that one of the thin columns is contained within the larger content DIV element. This keeps the footer element from overlapping any of the content elements.

<div id="MainColHome">
        <div id="center-main-content">
            /* Main Content */
        </div>
        <div id="right-column">
                 /* Side Content */
        </div>
</div>

Following are the style rules applied to the layout elements:

#center-main-content
{
    background-color:#FFFFFF;
    border-right:thin solid #000080;
    float:left;
    margin:5px;
    min-height:400px;
    width:360px;
}

#left-main-content, #right-main-content
{
    background-color:#FFF;
    margin:5px;
    min-height:400px;
    width:570px;
}

#left-main-content
{
    border-right:thin solid #000080;
    float:left;
}

#right-main-content
{
    float:right;
}