.NET Answers

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.

Republished by Blog Post Promoter