ASP.NET Developer Center
ASP.NET Developer Center > Reference >  Introduction to the ASP.NET Master Pages Templa...

Introduction to the ASP.NET Master Pages Template Set

The ASP.NET Master Pages Template Set consists of four templates demonstrating the powerful combination of ASP.NET master pages and themes on the server and standard XHTML and CSS on the client. Each template contains three original themes providing you with a total of 12 different layouts to pick from and adapt to your needs in your next ASP.NET 2.0 project.

The templates have been created with two purposes in mind:

  1. to provide you with a set of layouts you can take and adapt to your needs
  2. to showcase best practices in regards to standard-based web design using ASP.NET 2.0.

The most commonly found page layouts on the Web today have either two or three columns and either have a fixed width or adjust dynamically to the width of the visitor's browser window. Therefore, the ASP.NET Master Pages Template Set consists of templates that fulfill these requirements. Additionally, each template is best suited for a particular purpose as indicated by its name. They are:

The following table shows the type of layout contained in each of the templates:

Table 1: The available templates and their layout
 
Columns
Width
Small Business
2
fixed
Personal
2
fluid
Corporate
3
fixed
Commerce
3
fluid

While each template comes with its own documentation, this document serves as a general introduction to the template set and its features.

Note: this documentation assumes basic familiarity with ASP.NET 2.0 master pages, themes and skins as well as a working knowledge of CSS. If you need to brush up on any of these subjects, you can do so using the ASP.NET Quickstart tutorials or basic CSS tutorials.

Master Pages and CSS

One of the most prominent new features of ASP.NET version 2.0 is a technique called Master Pages. It provides the means to define the overall layout of an ASP.NET application at a single point (the .master file) and reuse it in all content pages that derive from the master. Updates to the layout can be done quickly and will be applied to the content pages immediately.

The structure of each of the four templates is defined in a master page in the application root. Aside from the sample content you will find the markup in them to be rather bare-bones. If you're coming from a "traditional" school of thought in Web design, the first thing you'll notice is the absence of tables. The templates structure the content in a number of div elements which usually have an id attribute assigned to them. The id is then referenced by an associated CSS file where the actual formatting takes place: the elements are placed at the desired locations on the page, have background-images and -colors assigned and the appearance of their content is determined. This way, a clear separation of content and design is achieved. Both can be changed independently without influencing, or potentially breaking, the other. Additionally, updates to the layout need to be done in one place only — the CSS file. If you ever had to update even a relatively small site that had content and presentational markup intermingled, you'll certainly appreciate the advantage of this approach.

If CSS is such a smart way to design web sites, then why isn't everybody using it?

Two reasons:

  1. CSS layouts are initially harder to create than conventional table-based layouts
  2. browser support for advanced CSS tends to be inconsistent.

While reason # 1 can be overcome by simply learning CSS, # 2 can be nearly a science in itself at times. Differences in the rendering engines of different browsers can often result in some rather odd page behavior upon previewing some of the CSS instructions you have written across multiple browsers and operating systems. The good news is, though, that by now most of the browser rendering issues have been documented and several workarounds exist to arrive at viable cross-browser CSS layouts (if you're interested, check out http://www.positioniseverything.net, one of several excellent resources on CSS in general and browser bugs in particular). As far as the templates in the ASP.NET Master Pages Template Set are concerned: you need not worry about necessary hacks and workarounds, as these have already been applied in the style sheets that come with each template. In fact, the templates will work correctly (or degrade gracefully) in all modern browser versions including Firefox, Opera and Safari, as well as in versions 5.0, 5.5 and 6.0 of Internet Explorer for Windows. IE 5.0 and 5.5 will have some minor glitches, but will mostly play along nicely, too.

Themes and Skins

Master Pages aren't the only new design-related feature of ASP.NET 2.0. Web developers are also provided with the ability to assign themes and skins to controls, pages or entire web sites, respectively. A theme is essentially a collection of files that determine the appearance of web application elements, such as pages and controls. Themes can include images, CSS files and skin files, where the latter specifically set visual properties of ASP.NET controls.

Each of the templates in the ASP.NET Master Pages Templates Set contains three themes. As you will see when you start experimenting with the templates, applying a different theme can dramatically change a web application's appearance — without necessitating changes in the code of any of the content pages. ASP.NET 2.0 takes web developers a large step forward on the road to strict separation of presentation and content.

Effective use of skins

There are two main approaches to skinning controls, for example a text box. Let's say you want to achieve a uniform visual appearance of all text boxes in your application. They should all look like this:

The most straightforward approach to skinning this control would be the declaration of a default skin for the ASP.NET TextBox control in the .skin file:

<asp:TextBox runat="server" BackColor="#F7DE8A" BorderColor="#933126" BorderStyle="Solid" BorderWidth="1px" />

While this works just fine when you preview it in the browser, there is another, more elegant way to achieve the same visual result: create a class rule in the CSS file and reference this rule from the skin file, as in the following example:

  • In Styles.css: .textBox {border:1px solid #933126; background-color:#F7DE8A;}
  • In Default.skin: <asp:TextBox runat="server" CssClass="textBox" />

This way, you keep all the visual elements, such as colors, in the style sheet and can manage them from one central location. Besides, let's suppose you want to assign a background image to all the text boxes later on. Since there is no way to do this directly in a skin file (ASP.NET controls don't provide a background-image property for you to use) you would have to create a separate CSS class anyway. Scattering formatting instructions across both style sheets and skin files makes site maintenance a lot harder than it should be.

No rule without exceptions, however: it is not very efficient to burden the global style sheet with rules that apply to a single control on a single page only; likewise, styling a complex control, such as the GridView might require the creation of 10 or more classes in the style sheet, which may or may not be an approach you want to take.

You'll find that the skin files in the ASP.NET Master Pages Template Set mostly reference existing classes in the style sheets and use direct styling in the skin files where necessary.

Themes versus StylesheetThemes

You may be wondering if you'll still be able to change visual properties of controls on pages that have a theme assigned. After all, individual adjustments are sometimes necessary and you wouldn't want to be restricted by a theme once it has been set. The answer is that all templates permit overriding of the values defined in a theme, which means that in your page code you can assign any visual properties at will and rest assured they'll be taken into account when the page gets rendered to the browser.

This is achieved by taking advantage of the distinction between a Theme and a StylesheetTheme, as described in the MSDN documentation (see the section entitled "Theme Settings Precedence"). In short, the main difference between the two properties is the position in the page rendering life-cycle where they are applied: a StylesheetTheme is assigned early on in the process, before the user-defined formatting instructions have taken effect; a Theme, however, comes last and gets merged with any earlier existing settings. All templates work exclusively with the StylesheetTheme, so whatever instructions you may have assigned to controls on a page will be honored.

Note: while there is a technical difference between a Theme and a StylesheetTheme, this documentation will continue to refer to both using the generic term theme.

Assigning themes to content

ASP.NET offers a number of ways to assign a theme to content pages. You can either add a Theme or StylesheetTheme property to the @Page directive at the top of the page, like this:

<%@ Page Language="C#" StylesheetTheme="Fruits" %>

or you can assign the theme globally to the entire application by adding the following instruction to the web.config file:

<system.web>
    (...)
    <pages styleSheetTheme="Fruits" />
</system.web>

Style sheets overview

From the above explanations it should be pretty clear that the CSS files are truly at the heart of each template. And indeed, they determine the page structure, the colors and the images that are used to create a specific layout. So lets have a closer look at how the CSS is organized.

As a general rule, each theme has a single CSS file that contains the bulk of the formatting instructions for the theme. Adjustments to the design of a theme will happen almost exclusively in the CSS file. The rules in each CSS file are arranged in the order the corresponding elements appear in the master page. For compatibility with IE version 5.5 and 5.0, some of the master pages contain a short <style> block in the head of the document which is wrapped in a conditional comment . The rules in there will rarely have to be changed but you should be aware of them nevertheless in case things go awry in IE 5.x.

Duplicate style rules

As you know, there is one CSS file per theme and there are three themes per template. Naturally, there are duplicate rules in the CSS files which could have been moved to a separate style sheet. For example, the basic rules for constructing the page grid (defining which element box goes where and has which dimensions) are nearly identical across all themes. The reason they were repeated in each style sheet rather than moved to a global file lies in the intended ease of modification of the themes. This way, you can deconstruct the layout by simply studying one file and make all your changes there. Having to mentally "merge" style rules scattered across several files is unwieldy at best and complicates the customization process.

Styling pages for printing

At the end of each CSS file you will find a style block introduced by an @media print rule. The rules contained in this block work in conjunction with the existing rules further up in the style sheet and specifically apply when the user prints a page from the browser. CSS allows a page author to exert a significant amount of control over the appearance of printed pages. Unfortunately, browser support is not uniformly up to what the CSS specification defines, but the print style sheets provided should nevertheless do their job satisfactorily.

CSS rule structure

You may be aware of the fact that pure CSS layouts can be a bit "sensitive" to change. Remember, that the way they are built is by defining distinct boxes that hold the content and then stacking theses boxes neatly on top and next to each other. Therefore, if you inadvertently make a change at the wrong place, the precise arrangement of boxes might get disrupted — resulting in a broken layout. In order to assist you in getting the most out of the templates, all the rules in the style sheets have been structured according to a specific convention. The "unsafe" properties which could potentially damage the layout if changed are at the top, while the ones that can be modified without problems are at the bottom. Let's look at an example rule:

#header {
  position:relative;
  height:140px;
  margin:0;
  border-left:10px solid #FFFFFF;
  background-color:#85B94A;
  background-image:url(Images/header_bg.gif);
  background-repeat:no-repeat;
  background-position:top right;
}

The position, height, margin and border-left properties all influence the arrangement of the boxes and thus should be modified with care only. These properties are located at the top of the rule. background-color, background-image, background-repeat and background-position, however will have no bearing on the overall page grid, so they are located at the bottom of the rule.

Here is a list of the most common "unsafe" properties for reference:

Property declarations other than the above can be customized without having to worry about potential negative side effects.

The general principle is: modify the declarations within a rule from the bottom and try to leave the "unsafe" declarations as is. If you're familiar with the CSS box-model, floating and positioning, however, you're of course free to modify the styles to your hearts content.

Design templates vs. reference applications

This might be stating the obvious, but please be aware that even though some of the templates show some dynamic behavior (reading from a database, gathering products in a shopping cart etc.) these templates are intended to be used as design models for web sites or applications. They are not ASP.NET reference applications. No input validation is performed nor will you find any form of exception handling anywhere. All these tasks are assumed to be taken care of by you, the ASP.NET programmer once you decide to use one of the templates in a real-world application.






Page view tracker