DotNetNuke Tips & Tricks

Monday, January 24, 2011 by Cuong Dang

DotNetNuke CSS Precedence, What You Should Know.

Filed under: Skinning, Module Development, DotNetNuke

DotNetNuke skinning isn’t easy as long as you figure out exactly how CSS files from the framework get loaded at runtime. I remember when I first started creating skins, I had to spend a tremendous amount of time fine tuning the details such as typography, padding, margin, and so on. My job became so much easier when I found out the secret is understanding DotNetNuke CSS precedence.

There are many CSS files being loaded on a page when a user lands on your site. Depending on how your site is configured (how many modules you have on a page, etc), there can be several CSS files the user must download and it can definitely affect performance. Well, we’re not exactly going to talk about how to speed up your site in this post, but I wanted to point out the precedence of CSS files in DotNetNuke so you can design better websites. Increased performance can be a welcome side effect of a cleaner implementation.

Hierarchy of CSS in DotNetNuke (and file locations)

  1. Module.css
    • (~/DesktopModule/ModuleName/module.css)
  2. Default.css
    • (~/Portals/_default/default.css)
  3. Skin.css
    • (~/Portals/PortalID/Skins/SkinPackageName/skin.css)
  4. Container.css
    • (~/Portals/PortalID/Containers/ContainerPackageName/container.css)
  5. Style.css (from module template if any)
    • (~/DesktopModule/ModuleName/Templates/template.css)
  6. Portal.css
    • (~/Portals/PortalID/portal.css)
  7. Inline.css (hard-coded in HTML)

As you can see, module.css often gets loaded on a page first if there are modules that come with CSS files in the package. Default.css loads second and provides a predefined look and feel to many html elements to set an overall theme for DotNetNuke. Web designers will need to override many selectors defined in default.css in in their skin to achieve a consistent design.

For consulting projects, I often combine CSS selectors from container.css into skin.css to eliminate an extra HTTP request from server. As a result, it helps with site performance a bit. If you intend to use your containers for many designs or if you’re creating a commercial skin package, it is recommended to have all CSS selectors defined separately from skin.css in container.css.

So what should goes in skin.css vs. container.css?

1. Skin.css

It’s 2011 and buidling websites using web standards is a must in every web project. This topic and its pros and cons have been discussed for the past decades by many industry experts.  Since web standards encourage the separation of content and its presentation, web designers often use a separate (or sometimes than one) CSS file to design their sites. Therefore, take this similar approach and apply to DotNetNuke skinning by having all the CSS for typography, layout and positioning, navigation, and other design elements in skin.css. By doing so, the content administrator will have less opportunity to alter the original design unless he/she has access to the skin itself.

2. Container.css

There are two strategies to consider when approaching container design. Either eliminate container.css for best performance or separate the style between skins and containers completely by putting all container related CSS in container.css file.

Elements that should go into container.css are headings, design elements for containers, container module navigation. When using container.css file, it is advisable to make sure the package  can be installed and used in different websites independently.

Portal.css is perfect for site editors when they do not have access to the skin package. It is often used for styling specific site content.

In conclusion, when designing for websites weather it’s built for DotNetNuke platform or others, separation of content and presentation is crucial to future collaboration and maintenance. To really master the details in DotNetNuke skinning, one must have solid understanding of CSS hierarchy in DotNetNuke to design better content and its elements as well as cross browser testing and fine-tuning.


blog comments powered by Disqus