DotNetNuke Default.CSS: Seriously??
Monday, June 2nd, 2008 | Artemis Solutions Group, CSS, DotNetNuke, Improving Code, Programming, Ranting, Skinning, Venting, Web Development, Work Stuff
Here’s another one of the myriad of reasons that I am displeased with DotNetNuke as a web development platform:
The “default.css” included with all installs of DNN has this (and more CSS for other stuff like it) in it:
H1
{
font-family: Tahoma, Arial, Helvetica;
font-size: 20px;
font-weight: normal;
color: #666644;
}
H2
{
font-family: Tahoma, Arial, Helvetica;
font-size: 20px;
...
(I think you get the point)
Excuse me, DotNetNuke core team, but isn’t stuff like this up to the Designers and Developers? Why are you including a default stylesheet with definitions for HTML elements that would be used by Web developers? I can’t tell you how many times default.css has left me absolutely baffled about the smallest details not being quite right according to our design specs because it has these random “defaults” in it. It’s not up to DNN Core team to define my font families, sizes, and colors. And seriously, stop using pixel font sizing.
It’s becoming clearer to me almost on a daily basis, that DNN is not the right CMS for a professional Web shop to be using. They probably have this default.css for people who don’t make skins or know anything about Web development. And if you remove default.css, it completely hoses all the Admin pages and Control Panel. It takes way too much time and effort to figure out what’s removable and what’s not, and you always end up surprised when some random element isn’t positioned or styled correctly later on down the road.
It’s time for us to move on to a CMS that gives the developer full control over the theme, and not put a bunch of defaults in it that you can’t get rid of.
14 Comments to DotNetNuke Default.CSS: Seriously??
Defaults you can’t get rid of? All you have to do is override the values in any of the following CSS files and you have everything you need
Module.css
Skin.css
Container.css
Portal.css
DNN loads the CSS in that order, and due to the cascading nature anything applied in those files will override. Is that too hard for a designer to figure out?
Agree with you on this. The framework is developed by well-versed programmers and developers so web standards doesn’t mean much to them.
However, they did provide a powerful skinning engine which allows users (designers and everybody) to create skins (theme) for a site design. You will have to override what they put in default.css in your skin.css. I know it is a lot of work, but the result is… much better.
ok fair enough on both points. I do agree they can be overwritten but I’ll be damned if it isn’t a pain in the ass. I really like the ability to have my themes separated between front-end and admin side on wordpress. But I wouldn’t suggest WP for a CMS. This is really me ranting.
I would prefer that default.css stick to admin side styles and leave the rest up to the designer and front end programmer. I can understand the need to leave in defaults for the unskilled user who wants to stick with default skins, but leave the CSS in skin.css for those folders, then.
Dang hit me over the head and made me see the error in my ways a bit today after I made the first comment. This is something that the skinning team might be interested in having as a suggestion for future improvement.
@Chris: you know, now that I think about it, I always assumed module.css would come after skin.css since modules only appear on whatever page they are installed on.
That certainly clears some issues up for me, however, I think it might make more sense for module.css to be included after skin.css, since you would hopefully only define styles in there specifically for those pages. Leave the theme defaults to skin.css and overwrite them on module pages, where necessary.
It would definitely help to encourage module developers not to define font sizes(in pixels anyway) or families in module.css. That cerainly gets annoying.
Regards.
and one more thing! :) I wish there was a way to define a default doctype for all skin files contained in a folder. Is there? I’ve never found info on such a thing. Its a bit time consuming to have to make and name two files per skin. Anyway, that would make my day!
Hey Joe, I agree… everytime we do a new DNN install we append a chunk of CSS at the very end of it to reset everything that makes us curse. We have a handful of DNN tweaks we do to every install that makes life much more tolerable.
Yeah, we make the doc type per skin, I’m not aware of any other way of doing it.
I think that module.css is loaded after skin.css
And yes, we still need to get together and take some pics. I went to Lainsburg state park this weekend, great day and got some good photos of some wildlife.
Thanks for the great post ;D
Module.css though contains module specific CSS, that applies to any portal it is installed on. By putting your modifications in skin.css or portal.css you can override the default modules. This might not make sense for modules you develop yourself, but for third party modules to me it makes more sense to load those first. The skin is what applies to my site, not the module.css.
@Ryan: Man sometimes I get the feeling you’re just leading me on ;) Set a date already!
CathalJune 3, 2008
ah, the stylesheets, the bane of many designers. The biggest problem here is that these have been in existance since probably 2002, so we can’t simply rip them out without impacting a huge number of sites. If we could start again I think these files would probably be mostly empty. There was some discussion in the core a while back about this, and I think we’ll have a solution for it it a future version (we’ll probably define their locations in the web.config, meaning you can remove/replace them easily)
[...] I’ve been getting quite a bit of attention from the DNN Core Team the past couple [...]
Here is an article about CSS Precedence in DotNetNuke:
http://www.engagesoftware.com/Blog/EntryID/140.aspx
What Chris said makes sense. If module.css loads after the skin.css, you won’t have a complete control of your site design anymore.
I also agree with Cathal, there are countless number of sites out there built using DotNetNuke framework, we can’t just remove something out of the default.css file.
June 2, 2008