One of the issues that every DotNetNuke skin designer faces is how to design skins for multiple browsers.  Often, getting a skin to work in Firefox, Chrome, Safari and Opera is pretty straightforward and doesn’t require much tweaking.  Unfortunately, the same cannot be said of Internet Explorer.  Making your skin work with IE6, 7 and 8 along with all the other browsers can be a bit of a nightmare.

I previously addressed this issue in DotNetNuke Tips and Tricks #3: Conditional StyleSheets.  In that post, I created a skin object that allows you to conditionally add a stylesheet to the skin based on a condition defined by the designer.  This skin object was subsequently added to the core framework and is currently being used by many designers.  In fact, Artisteer uses it in all the DotNetNuke skins that their software generates.

Recently, I found a method that I like better than using conditional stylesheets.  One of the downsides to conditional stylesheets is that you end up causing stylesheet bloat.  Conditional stylesheets add round trips to the server which we should be trying to minimize.  Conditional stylesheets also require you to maintain multiple stylesheets which can be a little painful.  If you make a change in your main stylesheet, you will need to find the corresponding section in your IE specific stylesheets and potentially make changes to them as well.  From a maintenance and development perspective, this is far from optimal.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Myths and Misconceptions

Over the past several years designers have expressed a number of frustrations about the DotNetNuke skinning engine.  Often these frustrations may be based on some particular difficulty they are having and therefore there is a kernel of truth to the issue.  What I frequently find when digging into these challenges is that there is a misunderstanding by the designer which leads to the frustration or the design is constrained by limitations in HTML and CSS.  Fundamentally, we need to do a better job of providing documentation to the design community which helps them to better address their points of frustration.  Below I present some of the common myths about DotNetNuke skinning.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Packaging

History

One of the great strengths of the DotNetNuke platform over the past 6 years has been the rapid growth of the ecosystem for modules and skins.  Very early in the project’s history we realized that in order to promote redistribution of extensions, we needed a standard method to package modules.  At the time, one of the community members contributed their code for reading a standard xml file located inside a zip file containing all of the module files.  Using this contribution as the foundation, I created the core module installation feature for DotNetNuke.  The xml file that controlled the installation process came to be known as the module manifest. 

The purpose of the manifest file was to identify key files within the package and designate where they should be installed.  This manifest also contained some additional metadata that was necessary for creating the needed entries in the different module tables within DotNetNuke.

Over time, Charles and myself continued to extend the module manifest and the packaging standard so that we could handle more and more installation scenarios. Even with these additions, the manifest and packaging standard was still basically the same as what I had originally built in 2004.

When Skinning was introduced with DotNetNuke 2.0 it used a different packaging standard.  Instead of relying on a manifest, it used a convention based approach and depended on having files follow a specific naming standard.  This worked well, but it had a number of limitations.  Like the module packaging standard, this remained largely unchanged until fairly recently.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Building Containers

DotNetNuke breaks up our “themes” into two different parts – skins and containers.  In part 1 and 2 of this series, I showed you how to make the page layout portion of a DotNetNuke Skin.  It can be a bit confusing to new users because the term skin is used to describe the entire “theme” and also to describe the page layout portion of a complete skin package.  Containers are a much easier term to understand and will be the focus of this post.

Background

A DotNetNuke website consists of a set of pages on which the user places and configures one or more modules.  In order to integrate the module into your website the framework wraps your module in a DotNetNuke Container.  Containers are designed to coordinate with the corresponding skin as one element in a unified design and are used as a frame around your individual bits of content. Containers provide the ability for designers to seamlessly integrate modules from many different developers into a single cohesive site design.  Since the designer has complete control over the appearance of the container, they can choose to visually frame content or to even have content blend in with the rest of the page elements such that there is no differentiation to a normal end user where one module ends and another module begins.  Containers can also include visual elements which allow the user to interact with the module.  At a minimum, most containers will include the Module Action Menu that administrators and editors use for configuring the module.

Your DotNetNuke site can be configured with a default container which can then be overridden by both individual pages and modules.  Even though a set of containers may be designed for use with a particular skin, you are free to mix and match any container with any skin and to use several different containers on a single page.  This flexibility is one of the great strengths of the DotNetNuke Skinning engine as it allows a small set of skins and containers to provide for many different layouts and designs for a given site.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Understanding the Basics

In the first part of this series we’ll be covering the basics of DotNetNuke Skinning.  My intent is to demystify some of the terms that we use and to relate them to our simple design.  Once you understand the basic elements that make up a DotNetNuke skin, then the rest of the skinning process becomes very easy.

A Little Background

One of the original goals we had when the DotNetNuke skinning engine was first created in 2003 was to make skinning accessible to both developers and designers.  This fundamental requirement has driven many of the changes over the years and continues to shape how we think about skinning in DotNetNuke.  From the very outset we thought that it was important that skin developers should be able to use whatever tool they were comfortable with and that they should not require any knowledge of programming in order to create cutting edge designs.  We also thought it was important that we put as few restrictions as possible into the skinning engine which would provide skinners with complete freedom in their designs.

The DotNetNuke skinning engine supports 2 different types of skins:  HTML Skins and ASCX Skins.  HTML Skins are the most basic form of skin and allow designers to use whatever HTML editor they desire.  When HTML skins are installed in DotNetNuke they are automatically converted to ASCX skins in the background.  During the conversion, the only part of the HTML skin that is retained is the innerHtml of the body tag.  Anything in the HTML Header will be discarded.

The DotNetNuke skinning engine recognizes a “Skin” as having two distinct entities: skins and containers.  These elements can be packaged and installed as a single package or as two distinct packages.  We’ll discuss containers later in this series and for now will focus on just the main skin package.  All of the concepts translate directly from skins to containers with a few minor differences.  If you understand how to create a skin, then creating the associated containers is easy.