By:
A lot of questions about skinning DotNetNuke are caused by a lack of understanding on what stylesheets are being used and for what. When I created my first skin I had the same issue. In this post I'll try to wrap up the most important information on the DotNetNuke stylesheets.
DotNetNuke and Style sheets
In HTML development it's a good practice to separate content and design.
The CSS styles that make up the actual design are defined in separate files called stylesheets.
DotNetNuke loads several style sheets for a page.
For every level of DotNetNuke there is a style sheets that could be loaded / used.
These "parts" are: Framework, Portal (Site), Skin, Container(s) & Module(s).
The Framework stylesheet always gets loaded, the rest only get loaded if they exist.
Framework CSS
This file that contains basic framework CSS, get loaded for every portal (Site) in your installation of DotNetNuke.
This CSS is the only stylesheet that always gets loaded.
Location of the file: /Portals/_Default/Default.css
Because this file contains quite a bit of legacy CSS (from previous DNN versions) a lot of people prefer not to load this file.
Further below I explain how and why you should not edit or delete this file.
Portal / Site CSS
This is a CSS file that is specific to a portal. By default it does not contain any CSS, but it can be edited by a site admin from within DNN to overrule CSS in the skins. (Mostly used for small tweaks)
Location of this file: /Portals/”PortalFolder”/Portal.css
If you remove this file from the portal folder it does not get loaded (through the file manager)
This is the file you edit if you use the stylesheet editor in the Site Settings.
It is meant to allow an admin to verwrite CSS defined in the skin.
Currently there is no possibility to edit the other CSS files from the admin interface.
Be careful with changes to portal.css. If they are in fact corrections for a specific skin, it's better to add them to skin.css. If you don't, you can get unexpected results if you ever use the skin package in another installation or portal.
There are two other kinds of CSS files that are only loaded if they exist;
Css Files belonging to Skins / Containers and Modules.
Skin package related css files
These are also the CSS files that also only get loaded if they exist in the skin package.
(if you don’t add them to the skin package, there won’t be a linked in the head of the page)
Stylesheets for a Skin
A. Skin.css
A style sheet that contains CSS for all the skins in a package.
If a Skin.css file exists in the package it will load for every skin in the package.
Locations:
/Portals/_Default/Skins/"MySkin"/Skin.css
OR
/Portals/"PortalFolder"/Skins/"MySkin"/Skin.css
B. “SkinName”.css
A Stylesheet with the same name as a skin file (ASCX/HTML), it contains specific CSS for that skin.
It is generally used to overwrite styles from Skin.css for that specific skin variation.
Locations:
/Portals/_Default/Skins/"MySkin"/"SkinName".css
OR
/Portals/"PortalFolder"/Skins/"MySkin"/"SkinName".css
Style sheets for a Container
A. Container.css
A style sheet that contains CSS for all the containers in a package.
If a Container.css file exists in the package it will load for every container in the package.
Locations:
/Portals/_Default/Containers/MyContainer/Container.css
OR
/Portals/"PortalFolder"/Containers/MyContainer/Container.css
B. “ContainerName”.css
A Stylesheet with the same name as a container file (ASCX/HTML), it contains specific CSS for that container.
It is generally used to overwrite styles from Container.css for that specific container variation.
Locations:
/Portals/_Default/Containers/ MyContainer /"ContainerName".css
OR
/Portals/"PortalFolder"/Containers/ MyContainer /"ContainerName".css
Note on Container HTML in relation to styles.
There is something fundamentally different between the CSS for a skin and a container.
A page can have only one skin, but because you can have different modules all with mutual or different containers on the same page there are 2 things you should take care of.
- You cannot use Ids in the static HTML of your container.
The reason for this is that a container can appear more than once on the same page (if 2 modules have the same container). Using an ID would result in an XHTML error, since ID’s must be unique on the page.
- You should try to use unique "root" Css classes in your containers and address those.
If you don’t ,you risk two containers influencing each other. If two containers have a style selector (read class) in common their Css wil influence each other.
|In that case the container that gets loaded last on the page will overrule the one before it.
Modules: Module.css
Some modules have a module.css file with some basic CSS to make sure the module renders ok.
If a module on the page has a module.css file available it will get loaded.
So only the CSS files of modules that are on the page get loaded.
Location of these files:
/DestopModules/"ModuleName"/Module.css
DotNetNuke Style sheet load order
If you want to create DNN skins effectively it is important to understand the order in which the stylesheets get loaded. The order is; modules, framework, skin, container, portal.
Module.css
Default.css
Skin.css
Skinname.css
Container.css
Containername.css
Portal.css
This means an Admin can always overrule any CSS by editing Portal.css, because it is loaded last.
Number of style sheets loaded & DotNetNuke page performance
If you want to improve the performance of your pages on the client side, it is best to have as little CSS files as possible loaded by the browser.
DotNetNuke can potentially load a lot of CSS files, this can make managing your CSS easier (smaller files split up), but it also adds HTTP requests to the process of loading the page.
If you are worried about the number of requests, you can limit the number of CSS files loaded to only 1.
Only one Skin / Container styles sheets
You don’t have to use all the CSS files DotNetNuke can load, since the framework will only load the skin / container css files that exist in the skin package.
You can put all your CSS for skins and containers in one file; Skin.css, DNN will only load one stylesheet for every skin / container in that skin package.
This does however mean you have to add unique CSS classes to a root element of every skin and containers and address them accordingly.
You also have to be sure the containers are not going to be used in combination with a skin from another skin package (as they would miss the needed styles).
Portal.CSS
If you don’t want Portal.css being loaded, you simply delete it, DotNetNuke will not load the file if it does not exist. (Menu: Admin > FileManager)
Default.css & Module.css
With the skin object you use the RemoveCssFile="module.css,default.css" attribute to prevent both CSS files from beoing loaded
Beware that some modules could look strange without the CSS they normally load, so you might have to copy some of the modules default CSS to your skin.css file.
What about editing or deleting Default.css & Module.css?
There are 2 reasons you should not edit or delete these files.
1. These files get overwritten on upgrade, so you will loose your changes on every upgrade (or have to keep backups of your changes).
2. Editing or deleting these files will influence all portals, not only the one your working on now.
As this is done from the skin, it's portal specific but skin specific.
You don't need a core hack or remove / restore the style sheets on every Core / Module update.
Warning on Stylesheets names and HTML skins
If you create an HTML skin, you should stick to the CSS files that are mentioned in this post.
You can link stylesheets with a different name in the head of the HTML skin, but they will be ignored if the skin gets parsed (converted to an ASCX file) and they will not be loaded on the DNN page.
I hope this makes the use of the DotNetNuke stylesheets a bit clearer for people who start skinning. In principle anything you can do with HTML can be done with DotNetNuke skinning. If you have a good understanding of HTML and CSS, the possbilities are endless.
A good example of what can be done with DotNetNuke, in our portfolio, is the website of
Mecanoo Architects.