DotNetNuke – Avoiding Container Collision

So many of the skin and container sets I buy are written in such a way that if I were to mix and match my containers, graphic disaster would strike my page.

Fortunately, the problem is rather easily fixed. But if more designers thought about this potential problem and applied the simple fix to avoid it, it would save us all time and make the skin all that much more valuable.


As I mentioned earlier, DotNetNuke loads the skin and container CSS files automatically based on what skin and containers you are using on the page. The skin.css file gets loaded first, and you really don’t need to worry about collisions with the skin.css file because there can only be one of those loaded at a time.

The next file that gets loaded is the container.css file from the first container on the page. Then the second container.css, if it is from a different directory, and the third until all of the needed container.css files are loaded.

And that’s where the trouble starts.

Let’s imagine that we have three containers loaded from three different directories causing three container.css files to load. Further, let’s say that each of them define the CommandButton class so that the first one is Blue underline, the second is light blue with no underline, and the third, just to make things interesting, is red text. What color will all of the items classed with CommandButton be?

No, they won’t be blue, light blue and red depending on the container they are in. They will all be RED. This is because, in CSS, the last definition wins.

So, what do we do?

In the skin file define all of your CSS classes, including all of the standard classes from the previous Skinning post, without any qualifications. These will be the defaults for the skin.

In each of your containers, create a main wrapping element for the container, maybe a DIV, and class it with something unique, like the name of your company and the container name. Just for an example, let’s say that class is named “dmbcContainerOne”. To create a CommandButton definition for container one, use the following syntax:

.dmbcContainerOne .CommandButton
{
    /* command button
       definition here */
}

Now that we have the collision issue taken care of, there is one more issue that we need to address.

Again, because many designers expect their skins and containers to be used as an isolated set, they never test to make sure that the container will work with another skin that isn’t part of the set. The most common manifestation of this problem is that everything in the container is expecting the background color to be the color of the skin. Therefore, I recommend that each skin have its own set of defaults defined for the main class name.

Then, test your skin and containers to make sure that you can load multiple containers without collision and that your containers work with other skins that you didn’t write.

Related Post

  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it wrong, which...
  • DotNetNuke Skins – Handling CSS FilesDotNetNuke Skins – Handling CSS Files One of the most common mistakes I see when I buy skins for DotNetNuke is that the skin creator places a link tag for the CSS file inside the ASCX file for that skin. I've also seen skin creators us...
  • DotNetNuke Skinning – Dealing with ImagesDotNetNuke Skinning – Dealing with Images There is one final basic topic we need to address prior to moving on to the details of working with Skin Objects, and that is the topic of including images in our skins and containers.You might t...
  • DotNetNuke Skins – ASCX vs HTML modeDotNetNuke Skins – ASCX vs HTML mode I got a question yesterday from a designer who is unfamiliar with ASP.NET asking what the difference is between ASCX mode and HTML mode when developing skins and containers for DotNetNuke. I th...
  • DotNetNuke Skinning – Getting Set UpDotNetNuke Skinning – Getting Set Up While it IS possible to create DotNetNuke skins and containers using a standard HTML editor and HTML files, I find that it is much easier to use Visual Studio and ASCX files instead. The reason for...