A Reflection on Themes, Skins, and Cascading Style Sheets (CSS) in ASP.NET 2.0 (A Final Conclusion)
April 7th, 2008
A couple years ago I was thrown into a web application that made heavy use of ASP.NET Themes and Skins. Prior to this I depended exclusively on Cascading Style Sheet (CSS) for my web development / web design needs. A first glance at ASP.NET Themes and Skins looked promising, but a number of flaws surfaced – see the links and issues listed at the end of this post.
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 read this post about a month ago I was relieved to discover that someone else had come to basically the same conclusions I had regarding themes. I meant to leave a comment at that time but something must have interrupted me. Thank you very much for working through all the issues with themes and for so clearly articulating your conclusions. And thanks for an excellent website.
Thanks Martillo, it’s great to know someone these articles useful. :)