Last post Dec 20, 2005 11:29 AM by jjmartin
Dec 16, 2005 08:44 PM|morgancase|LINK
I've read the DNN skinning documentation and have been doing some skinning of my own. I'm a little confused about how portal.css and default.css interact with a portal skin. I've noticed that default.css plays a big part when i reverse engineer some of
the standard DNN skins. it's as though default.css and skin.css work together to provide all classes needed for the total skin. is this always true or just with the standard skins?
this is where i need help. here are my questions.
1. if i duplicate every class found in default.css and put them in my skin.css, will the default.css effectively be rendered irrelevant by my skin?
2. if i have a custom skin, why would i ever want default.css or portal.css to be involved?
3. can i delete default.css and portal.css altogether and let skin.css do all the work?
4. when people create skins for sale, do they create skin.css files that duplicate everything in default.css so they can guarantee the behavior of all classes for the skin? or do they allow default.css to do some of the work. and if so, to what degree and
5. it seems that portal.css doesn't really play a part, at least in the standard skins I've been working with. doe it ever? does it have to?
Dec 17, 2005 12:59 AM|nbc|LINK
Only my limited experience... so any experts out there feel free to correct me
2. You don't really, you can effectively clear all values in those files
3. No - I think DNN needs them so something has to be there
4. Yes - I normally duplicate all those values and then modify them to suit
5. Now this one I'm less sure about - but remember that on first install DNN needs something to run with and I am guessing that is portal.css role
Dec 17, 2005 10:06 AM|leupold|LINK
default.css is used as a basis, all skins can rely on and it is usually not changed by the core from version to version, so that these classes do not have to be re-declared in every skin.css or container.css.
Skin.css and container.css are for skin specific styling.
portal.css is for portal specific adoption and can be edited by portal admin using css editor in menu item "portal settings".
Replying to your questions:
Dec 17, 2005 10:53 AM|morgancase|LINK
so if i understand correctly, if I were to design my own skin, from scratch, for others to use, i could follow either of the following scenarios.
1. create a skin.css that only contains additional classes needed for my skin and let default.css handle the classes that are already there, and are not unique to my skin. this reduces the complexity of my coding and probably won't impact how my skin looks
from site to site since most people don't alter default.css? sound right?
2. duplicate everything in skin.css to better guarantee the look of the skin in all situations knowing that it increases the amount of work for me. sound right too?
as i typed the two options above a few new questions came to mind.
1. which option, if either, results in faster performance?
2. it seems to me that putting all classes in skin.css would give more control when it comes to getting your skin to work consistently over IE, netscape, safari, IE mac, opera, etc. does this seem logical? i mean, you can't really guarantee that people
won't alter their default.css files, so you can't really guarantee your skins look unless you either put all classes in skin.css or include a new default.css with your skin (which doesn't really make any sense). does this seem right?
3. please let me know if there are other variables i haven't thought of.
Dec 19, 2005 04:49 PM|xddg|LINK
Morgan - on my site - under resources/skinning articles (only a couple here ok nothing that fancy) I discuss the CSS hierarchy and how it impacts on the output of CSS and your files.
I don't touch the default/portal css files unless I'm doing a complete site design.
I know people who do but boy oh boy - when you want to make a change - you better have a good memory knowing where you've changed it becuase if it's duplicated or left out - you can spend a month of Sundays trying to work it out - only to find out the reason
it wouldn't update is because it's duplicated somewhere else and you forgot.
For me - I tend to use the skin.css for most instances, and if embedding lots of skins in a file - like my XDMediaMadness pack - I have 60 files with one skin.css file and a custom css for each of the skins for elements that affect that skin only.
In my opinion, if you spend time at looking at what your skin themes require on a global level, then whats needed at a per skin level, you can create a site that is easy to manage and not requiring opening and closing lots of files because you simply wanted
to change the padding that affected all the skins, as opposed to opening up the custom css file (skinname.css) and changing text colour to suit that particular skin.
I'm talking about skins that are bound together in one folder and are what I would call a single skin theme with multiple pages.
I hop this helps and not confuses. *sigh* it's hard not to sometimes but I can't explain any better. However the article does cover a little bit more in depth to help you.
Dec 19, 2005 05:24 PM|morgancase|LINK
Dec 20, 2005 11:29 AM|jjmartin|LINK
there is a fairly good reason for NOT deleting the default.css. If your skins have any errors in it, DNN reverts to a default skin/container that generally does have some reliance on the default.css to be there.
Although this is normally only a concern during development, you can get some very odd looking or even hard to read stuff if you take out the default.css and get one of these errors.