Most programming languages contain good parts and bad parts. … [the language designers or architects] are usually powerless to do anything except heap more features on top of the existing pile of imperfections. And the new features do not always interact harmoniously, thus producing more bad parts. - JavaScript: The Good Parts by Douglas Crockford

His words can apply to all programming languages and frameworks. Like the Microsoft .NET Framework, Visual Studio, Java, and Eclipse.

Bad parts in the ASP.NET Framework and Visual Studio:

• ASP.NET Themes and Skins
• The ASP.NET AJAX Framework
• ASP.NET / Visual Studio Inline Style Properties
• Visual Studio Design View
• ASP.NET and Visual Studio’s over dependency on XML configuration files

It would be great if someone wrote a book outlining the good parts of ASP.NET and Visual Studio. :)

In addition to these issues, here are a couple other considerations when thinking about ASP.NET Themes:

• Themes do not adequately separate the levels of concerns within your application. When using Themes all design related files are baked into the application. From a maintainability standpoint, this doesn’t bode well in large web applications. Hosting design related files on a single server or an external Content Delivery Network (CDN) is an effective way for managing site wide UI updates and increasing a sites performance, ASP.NET Themes works against this technique.
• Themes add unneeded complexity by obscuring the real technologies at work (CSS). Everything that ASP.NET Themes offer can be better achieved outside of the ASP.NET Theme Framework. Technologies like Cascading Style Sheets (CSS),  alternate Style Sheets, and JavaScript can achieve more than Themes can provide.
• Themes are a server-side mechanism. Themes become a nuisance in client-side dependent, heavily dynamic, Web 2.0, DHTML, AJAX type web applications.
• Themes discourage developers from learning more about web design and the technologies surrounding it. Themes offer a seemingly simple API, which shelters developers from the complexities of CSS and JavaScript, but sooner or later The Law of Leaky Abstractions comes into play and knowing the fundamentals of these technologies is a necessity.
• Professional web designers don’t use ASP.NET Themes, CSS is the language of web designers.

Default Skins on the other hand can be useful for defining consistent CSS hooks into common ASP.NET controls. It’s unfortunate that we can’t use Skins without Themes.

Related posts:

• The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

I've read this book, re-read it, edited it, and would like to give it away - I was the Technical Editor. The books is like new and (did I mention) it's free!

Contest Rules:

• Updated! Just Leave a comment with a valid email address!

• Post a 500 x 200 pixel image of something you're working on in the comments of this post - this image could be code, web design, or anything work related.
• Include an optional description of your work
• The winner will be chosen April 1st May 1st, they'll be drawn at random, and will be notified through email.
• I pay for shipping.

* I've included a sample entry in the comments. If you're looking for a great free photo editing application then try Paint.net. If you're looking to host your image you might want to consider Flickr or Photobucket.

Good Luck!

The contest has ended, and the winner is….. Andrew Hinde. Nice!

The Problem / Question:
ASP.NET 2.0 Themes automatically includes all the Style Sheets (.css files) found in the active Theme (App_Theme) directory into the Head of the rendered document. This severely limits the robust CSS language, and works against the last decade of Cascading Style Sheet progress. For more specific details on the problems with ASP.NET 2.0 Themes start reading the articles found here.

A Solution / Work Around:
Add a custom VirtualPathProvider to ignore the Style Sheets (CSS files) found in the App_Theme directory. For more background on this solution see my article and David Ebbo’s article titled Overriding ASP.NET combine behavior using a VirtualPathProvider.

An example of the problem:

The directory structure:

Notice all the Style Sheets (.css files), there are more in the Adapters directory too.

Before including the CustomVirtualPathProvider (code provided below) into the project’s build - the XHTML rendered by Themes:

<html xmlns="http://www.w3.org/1999/xhtml" >
  <head><title>The Problems With Themes and Skins in ASP.NET 2.0</title>
    <link href="App_Themes/Default/CSS/Adapters/ChangePassword.css" type="text/css" rel="stylesheet" /> 

    ... The other 17 externally linked Style Sheets go here, they were removed to improve readability ...

     <link href="App_Themes/Default/CSS/PrinterFriendly.css" type="text/css" rel="stylesheet" />
  </head>
<body>

The Style Sheets are automagically inserted into the Head tag from the active Theme directory. Keep in mind that Internet Explorer has a 30 Style Sheet limitation (see article Q262161).

After including the CustomVirtualPathProvider (code provided below) into the project’s build - the XHTML rendered by Themes:

<html xmlns="http://www.w3.org/1999/xhtml" > 
  <head><title>The Problems With Themes and Skins in ASP.NET 2.0</title>
  </head>
<body>

Notice the complete lack of Style Sheets - ahhh simplicity is bliss, the very foundations of CSS Zen Enlightenment… :) Now we can manually include our Style Sheets, use Conditional Comments, and so on.

The source code for the CustomVirtualPathProvider provided by David Marzo in C#:

namespace Arfila.Web.Logic {
 
 [AspNetHostingPermission(SecurityAction.Demand,
   Level = AspNetHostingPermissionLevel.Medium)]
 [AspNetHostingPermission(SecurityAction.InheritanceDemand,
   Level = AspNetHostingPermissionLevel.High)]
 public class CustomVirtualPathProvider : VirtualPathProvider {
 
   public static void AppInitialize() {
     HostingEnvironment.RegisterVirtualPathProvider(new CustomVirtualPathProvider());
   }
 
   public CustomVirtualPathProvider() : base() { }
 
   private bool IsThemeDirectory(string virtualPath) {
     String checkPath = VirtualPathUtility.ToAppRelative(virtualPath);
     return checkPath.StartsWith("~/App_Themes/", 
       StringComparison.InvariantCultureIgnoreCase);
   }
 
   public override VirtualDirectory GetDirectory(string virtualDir) {
     if (IsThemeDirectory(virtualDir)) {
       return new ThemeDirectory(Previous.GetDirectory(virtualDir));
     }
     else {
       return Previous.GetDirectory(virtualDir);
     }
   }
 }
 
 [AspNetHostingPermission(SecurityAction.Demand,
   Level = AspNetHostingPermissionLevel.Minimal)]
 [AspNetHostingPermission(SecurityAction.InheritanceDemand,
   Level = AspNetHostingPermissionLevel.Minimal)]
 public class ThemeDirectory : VirtualDirectory {
 
    VirtualDirectory _toFilter;
    private ArrayList _children = new ArrayList();
    private ArrayList _directories = new ArrayList();
    private ArrayList _files = new ArrayList();
 
    public override IEnumerable Children {
      get { return _children; }
    }
 
    public override IEnumerable Directories {
      get { return _directories; }
    }
 
    public override IEnumerable Files {
      get { return _files; }
    }
 
    public ThemeDirectory(VirtualDirectory toFilter) : base(toFilter.VirtualPath) {
      _toFilter = toFilter;
      BuildChild();
    }
 
    private void BuildChild() {
      foreach (VirtualDirectory dirToFilter in _toFilter.Directories) {
        ThemeDirectory themeDir = new ThemeDirectory(dirToFilter);
        _children.Add(themeDir);
        _directories.Add(themeDir);
      }
 
      foreach (VirtualFile fileToFilter in _toFilter.Files) {
        string fileExtension = VirtualPathUtility.GetExtension(fileToFilter.VirtualPath).TrimStart('.');
        if (string.Compare(fileExtension, "css", true) != 0) {
          _children.Add(fileToFilter);
          _files.Add(fileToFilter);
        }
        else {
          //archivo .css no incluir
        }
      }
    }
  }
}

Some of the code has been modified for readability, download the original source code here.

Note: In order to use this VPP you’ll have to copy the code above into a new class in your App_Code directory.

Conclusion: This is one of the nicest work arounds or resolution to the issues surrounding ASP.NET 2.0 Themes. It allows us to leverage the power of ASP.NET 2.0 default Skins, allows us to logically group design related resources (Style Sheets, images, default Skins, videos, etc…) in the App_Theme directory, allows us to control the loading order (cascades) of style sheets, allows us to use Conditional Comments, to define Media Types, to override / inherit Styles, and to continue using CSS as it’s intended. In addition we can now easily integrate the ASP.NET 2.0 CSS Friendly Control Adapters into our web applications.

Discoveries:

1. Some of the more complex web sites (Amazon and Yahoo!) make use of Style Elements within the Body Element - see the source snippets below.
2. Gecko (Firefox, Flock, Mozilla, etc…) based browsers automatically move Style Elements found within the Body Element into the Head Element and render the page as expected - see the rendered Document Object Model (DOM) image below.
3. Internet Explorer doesn’t move the Style Element into the Head Element, but renders the page as expected.
4. Opera… well I wish I knew what Opera did, but the page renders as expected.

Source snippet from Amazon:

</table>
    </td>
  </tr>
</table> 

<style type=”text/css”>
.lol-hr-center { margin: 5px; border-top-width: 1px;
/* and so on… */
}
</style>

<div id=”listoflists_data” style=”display:none”>
Note how the Style element is located between the <table> and <div> tags.

Source snippet from Yahoo!:

<h4>
<a id=”paweather” class=”details” href=”r/wb/*-http://weather.yahoo.com/forecast/USKS0448_f.html”><span class=”icon”>Weather <b><strong>51&deg;</strong>F</b></span></a>

<style type=”text/css”>#patabs #weather .icon{background:url(http://us.i1.yimg.com/us.yimg.com/i/us/we/31/b/26.gif) 3px 2pxno-repeat;}</style>

</h4>
Note how the Style element is located within the <h4> tag.

A snapshot of the Document Object Model (DOM) as seen through Firebug:

Note the highlighted area references the Yahoo! source snippet from above.Â
Conclusion: Although the Style Element within the Body Element compromises the validity of a document, some of the leaders in web design and accessibility use this approach, so it may not be as big a work around or hack.

]]> http://adam.kahtava.com/journal/2007/03/20/in-favor-of-using-style-elements-embedded-style-sheets-style-blocks-style-tags-or-whatever-you-want-to-call-them-inside-the-html-xhtml-body/feed/ http://adam.kahtava.com/journal/2007/02/25/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-creating-printer-friendly-pages-defining-a-css-print-media-type-with-css-while-using-themes-work-around-5/ http://adam.kahtava.com/journal/2007/02/25/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-creating-printer-friendly-pages-defining-a-css-print-media-type-with-css-while-using-themes-work-around-5/#comments Sun, 25 Feb 2007 15:19:12 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,002ae3f5-6496-4d64-aab8-d3ccf498d7c7.aspx In this post I outline a couple alternate ways of defining the CSS Print Media Type with Themes. ASP.NET 2.0’s Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Style Sheets (CSS), but don’t fully support CSS - I’ve listed some “Work Arounds” for a couple design flaws. I don’t recommend any of these “Work Arounds” since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS selectors like classes or IDs.

The Problem / Question:
How can I use the CSS Print Media Type with Themes? In the past I’ve used an External Style Sheet which defined the Print Media Type, but ASP.NET 2.0 omits the Media Type attribute when it automatically includes all my CSS files (from the active Theme directory) into the HTML Head tag.

A Solution / Work Around:
The Print Media Type isn’t constrained to External Style Sheets and can be defined in the Style Element, in the @Media rule, and even specified through the @Import rule.

An example of the problem:

The directory structure:

The rendered XHTML:
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>
<link href=“App_Themes/Default/PrinterFriendlyStyleSheet.css”
type=”text/css” rel=”stylesheet” />
<link href=“App_Themes/Default/StyleSheet.css”
type=”text/css” rel=”stylesheet” />
</head>
Note each externally linked Style Sheet lacks a media type.

Our desired XHTML (using an Externally Linked Style Sheet and a Print Media Type) would have looked something like this:
<head>
<link href=“App_Themes/Default/PrinterFriendlyStyleSheet.css”
type=”text/css” rel=”stylesheet” media=”all” />
<link href=”App_Themes/Default/PrinterFriendlyStyleSheet.css”
type=”text/css” rel=”stylesheet” media=”print” />
</head>
Note the Media Type (media=”print”) in bold.

The solutions:

Option 1. Use the Media Rule (@Media) to define the print Media Type inside an Externally Linked Style Sheet.

An example:
@Media Print {
body {
background-color: #FFFFFF;
}
/*… your CSS here …*/
#Menu, #AdvertismentContainer {
display: none;
}
#Content {
width: 100%;
}
}
Discussion: This is probably the best alternative to defining the Media Type in an Externally Linked Style Sheet - the other solutions introduce problems of their own.

Option 2. Use the Import Rule (@Import) to load your printer friendly Style Sheet from an alternate location and define a Media Type - this involves removing your printer friendly Style Sheet from the Themes (App_Theme directory).

An example:
@Import url(”/AppName/CSS/PrinterFriendlyStyleSheet.css”) Print;

Discussion: This solution requires moving our Printer Friendly Style Sheet outside the Theme directory, since Themes don’t allow us to exclude a Style Sheet folder (see Excluding a CSS folder for more details). Once we start moving Style Sheets outside the Themes directory we should probably ask ourselves why we’re even using Themes, and consider regaining complete control over our CSS by moving all the CSS files outside the Theme directory. At this point we could revert to Externally Linking our Style Sheets where we could define our Media Type attributes. In addition the CSS URL function used in this solution confuses many.

Option 3. Use the Style Element to define a Print Media Type.

An example:
<style type=”text/css” media=“print”>
/*… your CSS here …*/
</style>

Discussion: This solution doesn’t work if the Style Elements are defined in the HTML head (see Using Internal (Embedded) Style Sheets with Themes for more details), you can however move the Style Element into the Body of the document, this compromises the HTML validation, but large e-commerce sites like Amazon and Yahoo! make heavy use of this method.

Option 4. Sub class the HtmlHead class to enumerate through the child controls and add new Meta attributes to the child controls using the HtmlLink class. See my post titled Defining a Media Type(s) for more details.
Discussion: This solution requires a fair amount of work and only solves one of the many problems with Themes, pursuing this solution would probably be a case of not seeing the forest for the trees.

In conclusion; Themes are a nice addition to ASP.NET, but have some significant design flaws particularly in the way it uses CSS - in this case how printer friendly (print) CSS Media Types are defined. I wouldn’t recommend using Themes on a complex web applications that make heavy use of CSS or AJAX, but for small projects they may be a nice option.

Related links:

• CSS Design: Going to Print
• Printing a Book with CSS: Boom!
• A Print CSS Primer
• CSS Media Types Create Print-Friendly Pages

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2007/02/25/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-creating-printer-friendly-pages-defining-a-css-print-media-type-with-css-while-using-themes-work-around-5/feed/ http://adam.kahtava.com/journal/2007/02/05/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-using-internal-embedded-style-sheets-with-themes-work-around-4/ http://adam.kahtava.com/journal/2007/02/05/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-using-internal-embedded-style-sheets-with-themes-work-around-4/#comments Mon, 05 Feb 2007 18:44:36 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,c1575144-e460-464d-b993-259ce96135f4.aspx ASP.NET 2.0’s Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don’t fully support CSS - I’ve listed some “Work Arounds” for a couple design flaws. I don’t recommend any of these “Work Arounds” since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS selectors like classes or IDs.

The Problem / Question:
How can I add Internal (embedded) style sheets (the ones that use the Style element) inside the Head tag when using Master Pages and Themes?  How can I override (overload) External style sheets for local pages or specific Web User Controls?

A Solution / Work Around:

One option is to create an ASP Placeholder (asp:contentplaceholder) in the Master Page’s Head tag to add the Style element into the Head of your Web Form (.aspx page). However, this solution doesn’t work well when using Themes, since themes automatically include the External style sheets after the Style element - I demonstrate this and provide an alternative solution later on in this post.

The Caveat / Warnings:
In most current-generation browsers the loading order for Internal style sheets, and External style sheets depend on their position in the Head tag. This behavior seems to go against what the W3C intended.

Generally speaking we can say that all the styles will “cascade” into a new “virtual” style sheet by the following rules, where number four has the highest priority:

1. Browser default
2. External style sheet
3. Internal style sheet (inside the <head> tag)
4. Inline style (inside an HTML element)

- Taken from: http://www.w3schools.com/css/css_intro.asp

As I understand and as the w3schools point out (I can’t find a reference from the depths of the W3C), Internal style sheets should have a higher priority than External style sheets, unfortunately this isn’t the reality. Instead External style sheets and Internal style sheets depend on the loading (cascading) order. An Internal style sheet will only override an External style sheet (in current-generation browsers) if the External style sheet is loaded first. This behavior introduces problems when using an ASP Placeholder because ASP.NET automatically includes the Style Sheets (.css) from the active Theme (App_Theme) directories into the Head tag after the ASP Placeholder’s contents have been loaded.

An example of the problem:

The directory structure:

The active Master Page:
<%@ Master Language=”C#” EnableTheming=”true” AutoEventWireup=”true”
CodeFile=”MasterPage.master.cs” Inherits=”MasterPage” %>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<html xmlns=”http://www.w3.org/1999/xhtml” >
<head runat=”server”>
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>

<asp:contentplaceholder id=”ContentPlaceHolderHead” runat=”server” />

</head>
<body>
<form id=”form1″ runat=”server”>

<h1>Hello World!</h1>

</form>
</body>
</html>
Note: the ASP Content Place Holder between the Head tags and “Hello World!” between the H1 tags.

The default Web Form (.aspx page) providing the Content for the Master Page’s Content Place Holder:
<%@ Page Language=”C#” Theme=”Default” MasterPageFile=“~/MasterPage.master”
AutoEventWireup=”true” CodeFile=”Default.aspx.cs” Inherits=”Default” %>

<asp:Content ID=”Content1″ ContentPlaceHolderID=”ContentPlaceHolderHead” Runat=“Server”>

<style type=”text/css”>
H1{
color: red;
}
</style>

</asp:Content>
Note: the Style element between the ASP Content Place Holder tag - H1 should now be colored red.

The contents of StyleSheet.css, the only CSS file in the Active Theme (App_Theme) directory:
H1{
color: blue;
}
Note: H1 should still be red because Internal style sheets are supposed to have priority over External style sheets.

The rendered XHTML:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<html xmlns=”http://www.w3.org/1999/xhtml” >
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>

<style type=”text/css”>
H1{
color: red;
}
</style>

<link href=”App_Themes/Default/StyleSheet.css” type=”text/css” rel=”stylesheet” />

</head>
<body>
<form name=”aspnetForm” method=”post” action=”Default.aspx” id=”aspnetForm”>
<div>
<input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE” value=”…” />
</div>

<h1>Hello World!</h1>

</form>
</body>
</html>
Note: the position of the External Style Sheet (the Link element) in relation to the Internal Style Sheet (the Style element) - the Internal style definition (color: red;) precedes the External style definition (color: blue;).

The results in a web browser:

Note: according to the style sheet priorities in the W3C guidelines (see above) “Hello World!” should be colored red not blue - the Internal Style should be applied before the External Style; however, this is not the case.
Conclusion; the ASP Content Place Holder “Work Around” doesn’t work well with Themes since ASP.NET automatically includes all the CSS files in the active Theme directory - this behavior disrupts the loading (cascading) orders. This “Work Around” could be useful if you were only using Master Pages or were painfully meticulous with your CSS names and made heavy use of the !important style definition.

Another Solution / Another Work Around:
Define the Style element outside the Head tag, directly within the content of your page.

An example of the Work Around:
The rendered XHTML:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<html xmlns=”http://www.w3.org/1999/xhtml” >
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>
<style type=”text/css”>
H1{
color: red;
}
</style>
<link href=”App_Themes/Default/StyleSheet.css” type=”text/css” rel=”stylesheet” />
</head>
<body>

<style type=”text/css” media=”screen”>
H1{
color: green;
}
</style>

<form name=”aspnetForm” method=”post” action=”Default.aspx” id=”aspnetForm”>
<div>
<input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE” value=”…” />
</div>
<h1>Hello World!</h1>
</form>
</body>
</html>
Note: the Style element (color: green;)inside the Body tag.

The results in a web browser:

Note: “Hello World!” is green as expected.
The Pros and Cons to this (the Style element outside the Head tag) approach:
Cons:

1. It’s not a recommended best practice, but is used by some of the larger sites like Amazon and Yahoo!
2. It’s not valid XHTML (but neither are iframes in XHTML Strict)

Pros:

1. Can use Microsoft’s Conditional Comments
2. Can use the CSS @Import rule
3. Can use the CSS @Media rule
4. Can use multiple CSS Media types
5. Can easily use Media-dependent cascades
6. Can easily control the CSS load order (inheritance and cascading)
7. It’s fairly intuitive and understandable
8. It’s compatible with Revision Control Systems

Conclusion; Themes are a nice addition to ASP.NET, but have some significant design flaws particularly in the way it uses CSS. Themes aren’t recommended for complex web applications that make heavy use of CSS, but for small projects they may be a nice option.

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2007/02/05/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-using-internal-embedded-style-sheets-with-themes-work-around-4/feed/ http://adam.kahtava.com/journal/2007/02/03/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-the-load-order-cascades-for-css-work-around-3/ http://adam.kahtava.com/journal/2007/02/03/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-the-load-order-cascades-for-css-work-around-3/#comments Sat, 03 Feb 2007 19:30:21 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,003772b4-6ef1-4a6c-ba46-f122c787a052.aspx ASP.NET 2.0’s Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don’t fully support CSS - I’ve listed some “Work Arounds” for a couple design flaws. I don’t recommend any of these “Work Arounds” since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS selectors like classes or IDs.

The Problem / Question:
Is it possible to define the loading order (cascades) of CSS files while using Themes in ASP.NET 2.0?

The Solutions / Work Arounds:
Order your CSS files alphanumerically - ASP.NET 2.0 parses through the active Theme directory and all sub directories alphanumerically including every CSS file into the HTML head (via an external link) of the rendered page.

An example of the problem (when load order isn’t defined).
Note: both examples use the same CSS files, but use different loading orders.

The directory structure and StyleSheets:

The rendered XHTML:
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
<link href=”App_Themes/Default/Controls/OverloadedUserWebControlStyleSheet.css“
type=”text/css” rel=”stylesheet” />
<link href=”App_Themes/Default/Controls/ReusedUserWebControlStyleSheet.css“
type=”text/css” rel=”stylesheet” />
<link href=”App_Themes/Default/OverloadedStyleSheet.css“
type=”text/css” rel=”stylesheet” />
<link href=”App_Themes/Default/ReusedStyleSheet.css“
type=”text/css” rel=”stylesheet” />
</head>

The results in a web browser:

An example of the problem (when load order has been defined alphanumerically).

The directory structure and StyleSheets:

Note: the use of alphanumeric delimiters preceding the Style Sheet names.

The rendered XHTML:
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
<link href=”App_Themes/Default/aa_ReusedStyleSheet.css“
type=”text/css” rel=”stylesheet” />
<link href=”App_Themes/Default/Controls/01_ReusedUserWebControlStyleSheet.css“
type=”text/css” rel=”stylesheet” />
<link href=”App_Themes/Default/Controls/09_OverloadedUserWebControlStyleSheet.css“
type=”text/css” rel=”stylesheet” />
<link href=”App_Themes/Default/zz_OverloadedStyleSheet.css“
type=”text/css” rel=”stylesheet” />
</head>
Note: the ordering of the CSS files.

The results in a web browser:

Comparing the web browser results:

The Pros and Cons to this approach:

Cons:

1. Being a work around it’s not intuitive _ a maintenance programmers nightmare - “I’m familiar with CSS, but how are the Cascading Style Sheets being loaded??”
2. Contributes to a fragile environment - the way ASP.NET parses through the App_Themes directories may change in newer versions of ASP.NET, not to mention changing a filename could have negative side effects on the site’s design.

Pros:

1. Allows a load order to be defined
2. Compatible with Revision Control Systems

In conclusion; Themes are a nice addition to ASP.NET, but have some significant design flaws particularly in the way it uses CSS. Themes aren’t recommended for complex web applications that make heavy use of CSS, but for small projects they may be a nice option.

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2007/02/03/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-the-load-order-cascades-for-css-work-around-3/feed/ http://adam.kahtava.com/journal/2006/11/11/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-a-media-types-work-around-2/ http://adam.kahtava.com/journal/2006/11/11/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-a-media-types-work-around-2/#comments Sat, 11 Nov 2006 16:34:50 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,63d6c2f3-4cd9-4a7d-ab5a-2796033cb3a1.aspx ASP.NET 2.0’s Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don’t fully support CSS - I’ve listed some “Work Arounds” for a couple design flaws. I don’t recommend any of these “Work Arounds” since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

The Problem / Question:
Is it possible to define CSS Media types (like media=”print”) in the HTML Head tag? ASP.NET 2.0 automatically includes all my CSS files (from the active Theme directory) into the HTML Head tag, but Themes don’t allow me to specify any CSS Media types.

The Solutions / Work Arounds:
Sub class the HtmlHead class to enumerate through the child controls and add new Meta attributes to the child controls using the HtmlLink class. In order to use multiple Media types you would probably need to use more complex logic and resolve Media types to filenames (i.e. SomeFileName_Print.css could resolve to media=”print”) - for more information on manipulating the HtmlHead class read Phil Scott’s post titled: Accessing the Html Header in ASP.NET 2.0.

An example of the problem:
The HTML source automatically generated by ASP.NET 2.0 Themes (note the lack of media attributes):
<head>
<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” />
</head>

My desired HTML source (note the media attributes in bold):
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
<link href=”App_Themes/Default/Default.css”
type=”text/css” rel=”stylesheet” media=“all“ />
<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“ />
</head>

The Pros and Cons of this approach:

Cons:

1. Can’t use Microsoft’s Conditional Comments
2. Can’t use the CSS @Import rule
3. Can’t use the CSS @Media rule
4. Can’t easily use multiple CSS Media types
5. Can’t easily control CSS preferred and alternate style sheets
6. Can’t easily control the CSS load order (inheritance and cascading)
7. Contributes to a fragile environment
8. Not intuitive _ a maintenance programmers nightmare - “I know CSS, but Where are the Media types defined and How are they controlled?”

Pros:

1. Can define a single Media type for all .css files relatively easy
2. Could define multiple Media types - with more complex logic dependant on .css file naming
3. Could control CSS preferred and alternate style sheets - with more complex logic dependant on .css file naming
4. Compatible with Revision Control Systems (CVS, Subversion, Visual Source Safe, and so on)

In conclusion; CSS will continue to be the industry design standard - it has been the standard for well over 10 years. CSS is far more powerful than Themes and Skins, I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2006/11/11/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-a-media-types-work-around-2/feed/ http://adam.kahtava.com/journal/2006/11/09/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-excluding-a-css-folder-work-around-1/ http://adam.kahtava.com/journal/2006/11/09/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-excluding-a-css-folder-work-around-1/#comments Fri, 10 Nov 2006 00:32:47 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,7e992478-da0f-4ce4-bb43-3a0b58f6f3ad.aspx ASP.NET 2.0’s Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don’t fully support CSS - I’ve listed some “Work Arounds” for a couple design flaws. I don’t recommend any of these “Work Arounds” since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

The Problem / Question:
How can I exclude a subdirectory (sub folder) containing Cascading Style Sheets (CSS) in a Theme (App_Theme) directory? ASP.NET 2.0 automatically includes all CSS files (.css) from the active Theme directory and sub directories into the rendered HTML page, but doesn’t allow me to exclude a folder of CSS files or a single CSS file.

The Solutions / Work Arounds:

1. Create your CSS directory outside the App_Theme directory then map a Virtual Directory inside your Theme directory.
2. Add a custom VirtualPathProvider to ignore the non-root level CSS files in sub directories  - See David Ebbo’s article titled: Overriding ASP.NET combine behavior using a VirtualPathProvider.

These “Work Arounds” are useful if you want to do something like this (note: Default.css is sitting in the root of the active Theme directory):

/* Default.css */
@Import “StyleSheets/Common.css “;
@Import “StyleSheets/Masterpage.css”;
<!–[if IE]>
@Import “StyleSheets/FixInternetExplorer_Quirks.css”;
<![endif]–>
<!–[if IE 7]>
@Import “StyleSheets/FixInternetExplorer7Quirks.css”;
<![endif]–>

Or if you wanted to use an Embedded CSS Statement like this:

<style type=”text/css”>
<!–
@Import “StyleSheets/HideNavigation.css”;
@Import “StyleSheets/HideSearchBars.css”;
–>
</style>

The Pros and Cons of this approach:

Cons:

1. Can’t really define CSS media types, but we can now use the CSS @Media rule
2. Can’t control CSS preferred and alternate style sheets
3. Doesn’t scale well
4. Contributes to a fragile development environment
5. Not very compatible with Revision Control Systems (CVS, Subversion, Visual Source Safe, and so on)
6. Not intuitive _ a maintenance programmer’s nightmare, “I know CSS, but Where is the CSS folder?” or “I know CSS, but Why and How are some CSS folders excluded?

Pros:

1. Can control the load order (inheritance and cascading) through the CSS @Import rule
2. Can exclude a folder containing CSS files
3. Can use the CSS @Import rule
4. Can use the CSS @Media rule
5. Can use Microsoft’s conditional comments

In conclusion; CSS will continue to be the industry design standard - it has been the standard for well over 10 years. CSS is far more powerful than Themes and Skins, I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

Related posts:

• Where it all Falls Apart
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2006/11/09/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-excluding-a-css-folder-work-around-1/feed/ http://adam.kahtava.com/journal/2006/11/08/the-problems-with-themes-skins-and-cascading-style-sheets-css-where-it-all-falls-apart/ http://adam.kahtava.com/journal/2006/11/08/the-problems-with-themes-skins-and-cascading-style-sheets-css-where-it-all-falls-apart/#comments Thu, 09 Nov 2006 01:11:28 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,4df765e2-b408-471e-9999-652cd804b683.aspx 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:

<head> 
 <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" />
</head>

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.

Problems:

• 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:

<head>
  <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" />
  <![endif]-->
  <!--[IF IE 7]>
    <link href="App_Themes/Default/StyleSheets/FixInternetExplorer7Quirks.css" 
      type="text/css" rel="stylesheet" media="all" />
  <![endif]-->
</head>

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:

• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2006/11/08/the-problems-with-themes-skins-and-cascading-style-sheets-css-where-it-all-falls-apart/feed/ http://adam.kahtava.com/journal/2006/10/30/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-2/ http://adam.kahtava.com/journal/2006/10/30/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-2/#comments Tue, 31 Oct 2006 00:26:43 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,69f6fc25-9820-4abf-a930-b119401b1dc7.aspx 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.

Questions:

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.

]]> http://adam.kahtava.com/journal/2006/10/30/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-2/feed/ http://adam.kahtava.com/journal/2006/10/29/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-1/ http://adam.kahtava.com/journal/2006/10/29/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-1/#comments Sun, 29 Oct 2006 16:06:18 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,7febbbfc-c506-45ad-817d-af62ed1645be.aspx 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: www.damowmow.com.

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.

]]> http://adam.kahtava.com/journal/2006/10/29/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-1/feed/