Archive for the ‘Themes and Skins’ Category

The Problems with Themes, Skins, and Cascading Style Sheets (CSS) – Where it all Falls Apart

November 8th, 2006

Themes and Skins are a promising addition to ASP.NET 2.0, but too immature for large web projects.

The problem with Themes and Skins begins with the way Cascading Style Sheets (CSS) are automatically included into the rendered page. Through compilation logic, ASP.NET 2.0 parses through the directory and sub directories of the active Theme. ASP.NET 2.0 automatically includes an external CSS file reference into the HTML Head tag of the rendered page for every CSS file encountered.

Here’s an example for a better understanding.

My directory structure:

The output generated by Themes from the preceding directory structure:

 <title>The Problems With Themes and Skins in ASP.NET 2.0 </title> 
 <link href="App_Themes/Default/HandHeld.css"
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/Print.css" 
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/Screen.css" 
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/StyleSheets/FixInternetExplorer7Quirks.css"
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/StyleSheets/FixInternetExplorerQuirks.css" 
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/StyleSheets/HideAdvertisments.css" 
   type="text/css" rel="stylesheet" />
 <link href="App_Themes/Default/StyleSheets/HideBorders.css" 
   type="text/css" rel="stylesheet" />
 <link href="App_Themes/Default/StyleSheets/HideMenus.css" 
   type="text/css" rel="stylesheet" />

As you can see, the external CSS file references are automatically included in the rendered page – the load order of CSS files seems to depend on the directory and CSS file name. In this example the root directory is parsed alphabetically then the sub directory is parsed alphabetically.

It’s neat how ASP.NET 2.0 automatically includes .css files, but this behavior severely limits the use of CSS (see the list below), and encourages developers / designers to create many .css files which introduces new problems – Internet Explorer has a 30 style sheet limitation, see article Q262161.


  • As the name implies Cascading Style Sheets (CSS) depend on the order in which files are loaded (cascades), in addition to other rules like the CSS @import and CSS @Media rule. By automatically loading all .css files into the header, Themes prevent cascades and loading order from being defined.
  • The automatic inclusion of .css files prevents the use of Microsoft’s Conditional Comments.
  • The automatic inclusion of CSS files omits the CSS Media type.

A rough list of CSS features compromised by Themes in ASP.NET 2.0:

  1. CSS media types
  2. The CSS @Import rule
  3. The CSS @Media rule
  4. Preferred and alternate style sheets
  5. Media-dependent cascades
  6. Inheritance and cascading
  7. The use of Microsoft’s Conditional Comments

An example of when these compromised features are useful:

  <title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
  <link href="App_Themes/Default/HandHeld.css" 
    type="text/css" rel="stylesheet" media="handheld" />
  <link href="App_Themes/Default/Print.css" 
    type="text/css" rel="stylesheet" media="print" />
  <link href="App_Themes/Default/Screen.css" 
    type="text/css" rel="stylesheet" media="screen" />
  <!--[IF IE]>
    <link href="App_Themes/Default/StyleSheets/FixInternetExplorerQuirks.css" 
      type="text/css" rel="stylesheet" media="all" />
  <!--[IF IE 7]>
    <link href="App_Themes/Default/StyleSheets/FixInternetExplorer7Quirks.css" 
      type="text/css" rel="stylesheet" media="all" />

The contents of Print.css or HandHeld.css would generally look something like this:
/* Contents of Print.css or HandHeld.css*/

@Import “App_Themes/Default/StyleSheets/HideAdvertisments.css”;
@Import “App_Themes/Default/StyleSheets/HideBorders.css”;
@Import “App_Themes/Default/StyleSheets/HideMenus.css”;

In conclusion; Themes have a number of design flaws which limit a significant portion of CSS’s mature feature set. Themes are OK for small web applications, but not recommended for large / complex applications. While there are “work arounds” for some of the issues on my list, implementing each “work around” contributes to software entropy before your application is even developed. Since Skins and Themes are really based around CSS you might be better off sticking with CSS and a single default ASP.NET 2.0 Skin in which you define some default CSS classes or ID elements for some basic ASP.NET server controls.

Related notes:

Rick Strahl came to a similar conclusion:

theming is nice but really most of that can be accomplished with CSS and what Themes offers beyond that is really not that critical. [...] As it stands I don’t really see how I can utilize Themes in my apps in a meaningful way. – Playing around with ASP.NET Themes

Scott Allen makes a great point:

Web designers will be more comfortable with css files. If you put the design of your site into the hands of professionals than you should be asking them to use css wherever possible. – Themes In ASP.NET 2.0

Richard P makes a related comment:

there are so many flaws in Themes and how they use CSS I dont know where to begin! [...] The concept of CSS and the web skin has been around for some years, and we have been building great solutions despite Visual Studio and ASP.NET. – Themes and Skins Flawed in ASP.NET 2.0

Learn more about Themes and Skins here: A Quick Tour of Themes in ASP.NET 2.0.

Related posts:

Author: Adam Kahtava Categories: .NET, ASP.NET, CSS, Themes and Skins Tags:

A Reflection on Themes, Skins, and Cascading Style Sheets (CSS) in ASP.NET 2.0 (Part 2)

October 30th, 2006

Themes and Skins depend on Cascading Style Sheets (CSS) and HTML / XHTML, but Themes and Skins don’t fully support CSS – now that’s a paradox.

HTML, XHTML, XML, and other related Markup Languages can all be manipulated through CSS – ASP.NET generates most of these languages. If your not yet familair with ASP.NET 2.0 Themes and Skins: Skins give developers and designers a little more precision to manipulate server side controls like datagrids, and calendars, but Skins fundamentally depend on CSS. Themes allow us to group our Skins, CSS files, graphics / images, and so on into logical groups or directories, but Themes really depend on CSS through Skins and CSS (.css) file references.

Both ASP.NET Themes and Skins are directly dependent on Cascading Style Sheets (CSS). However; Themes and Skins prohibit a good deal of CSS’s functionality – I’ll discuss this is my next post. CSS has been with us for over a decade, it’s a pretty powerful display mechanism for web applications. CSS can manipulate HTML, XHTML, XML, SVG, XUL and other common Markup Languages.

I’ve come up with a number Theme and Skin related questions that I have yet to answer.


If Themes and Skins rely on CSS why not just use CSS?
Answer: Default Skins are good, they provide hooks (class and ID selectors) for defining CSS. Themes are OK they let us logically group images and design related files, but fall short in a number of areas and are not recommended for large web applications. 

If it’s possible to accomplish all that Skins and Themes offers through CSS why should I make the switch?
Answer: Skins can make life easier for your web designers, when used to hook into CSS classes and ID selectors.

CSS is a mature, robust language, it’s been around for over 10 years so more designers / developers are familiar with it, why should I switch to a a technology that is unfamiliar to most of the people that will be maintaining the application?
Answer: It’s not a clear case of CSS vs Themes since you really can’t have Themes without CSS. If used properly Themes can augment CSS.

Are Themes and Skins really scalable for a large enterprise level web application?
Answer: Not really, having a seperate server or Content Delivery Network for site resources like images, stylesheets, etc… is probably the best approach. Themes and Skins do prove uesful for small web applications.

Author: Adam Kahtava Categories: .NET, ASP.NET, CSS, Themes and Skins Tags:

A Reflection on Themes, Skins, and Cascading Style Sheets (CSS) in ASP.NET 2.0 (Part 1)

October 29th, 2006

While Themes and Skins are new to ASP.NET 2.0, the underlying concepts have been around for a long time. For those unfamiliar with Themes and Skins, skins give web designers greater flexibility to manipulating ASP.NET server side controls (calendars, datagrids, etc…) through Styles / Cascading Style Sheets (CSS). Themes logically group the design tier of an application into a common folder or directory (a Theme folder(s)), giving developers the ability to programmatically change (swap), or expose these Themes to the user.

Learn more: ASP.NET Themes and Skins Overview.
See a live example here: ASP.NET 2.0 Colorful Web Site Starter Kit.

The concept of interchanging layout and changing design styles (Themes) has been around for quite some time. The W3C Recommendation for Style Sheets in HTML documents outlines the “alternate stylesheet” that should be interchanged through the browsers menu; unfortunately Internet Explorer (IE) fails to support this method.

An example: changing style sheets with a Mozilla based browser (Firefox).

See the live example (if you’re not using IE) at:

Other methods for changing design layouts (Themes) range from Client Side Scripts (JavaScript) to Server Side Scripts (ASP, PHP, ASP.NET, and so on).

Learn more about style interchanging scripts and more here: Style Switching – css-discuss.

Themes and Skins are a welcome addition to ASP.NET 2.0, they offer a simple solution for grouping design specific files, and a nice way to programmatically change these Themes. However; this simplistic approach significantly hampers the power of Cascading Style Sheets _ I’ll discuss my difficulties / problems in subsequent posts.

Author: Adam Kahtava Categories: .NET, ASP.NET, CSS, Firefox, Themes and Skins Tags: