Archive
Monthly
Go
|
|
DNN Blog
Jun
7
Posted by:
Cuong Dang
Monday, June 07, 2010 2:28 PM
So many times when you sit down and start a new DotNetNuke skinning project, the first thing to do is to define your own CSS properties and values to override some of the default selectors from the default.css file in core DNN framework. I even created a little CSS template file I use on start of every skinning project I’m involved in.
The Experience team has been taking notes from conversations within the community for a while. It’s not we didn’t realize the CSS file needs improvement, but it’s how it should be implemented and corrected so it would help us to from making continuous changes for a while before newer approaches and techniques are introduced (CSS3).
Years ago when DNN was first created, those CSS selectors were there to help non-web designers to have something visually working right away after installing DNN. Over time, we learned newer techniques that help speed up sites performance, better organization of selectors to increase productivity when we collaborate with others and so on.
We, the Experience team, met bi-monthly to talk about issues that can help improving the experience within the community and the platform itself. There are many things we want to do to help improve DNN, but a good plan to prioritize our work is crucial to make sense of the business values and the effort we put out (in this case, it’s our time).
I am currently involved in updating the default.css file to avoid breaking changes for legacy DNN versions while eliminating the deprecated CSS markup. Our team consists of Timo Breumelhof, Salar Golestanian, and myself, have re-organized, optimized, and tested the new default.css file and hope it will be incorporated into the core framework so everybody can take advantage of a more semantic approach of writing CSS.
So, we need your help! If you wish to help speeding the process, go ahead and grab the file and test it in your environment. You can start using it and report issues you encounter. We will correct it and hope this would be one less thing you have to think about when designing and developing DotNetNuke skins in the near future.
Download the Default.css beta version.
Participate in Forum Discussion
11 comment(s) so far...
Re: The New and Clean Default.css (Beta)
Dang this is great!
By Brad Bamford on
Monday, June 07, 2010 2:37 PM
|
Re: The New and Clean Default.css (Beta)
This sounds great Cuong. But I wonder if it is a bit premature. Given that there is now a UX person and a focus to improve all of the DNN core controls to be more XHTML compliant, doesn't the CSS go hand in hand with the new HTML?
I would love to see the default.css file trimmed down, but I also wonder if instead of trying to prevent breaking changes, it might be easier to just add a portal setting "Load Legacy CSS" that would load this CSS file and then start fresh with a new and improved CSS file for the new HTML that comes from the UX team. That way, portals that dont need it and avoid the overhead completely.
By Jay Mathis on
Monday, June 07, 2010 3:35 PM
|
Re: The New and Clean Default.css (Beta)
@Jay ~ I doubt the UX team would disagree with any of that. But we have figured out that waiting until "stars align" keeps things from moving far at all. It takes a little longer for some things to happen than others. This was something the UX team could do (and collect feedback on) that would have positive benefits without waiting on anything.
By Scott Willhite on
Monday, June 07, 2010 3:37 PM
|
Re: The New and Clean Default.css (Beta)
Cuong,
It's nice to see that other skin designers/developers are using a template css file at the start of new projects, I think for a while this is just the way it's going to have to be to overcome the legacy css of older versions.
I agree that it would be nice to turn off all the additional css that comes with DNN, but this is a greatly appreciated file that I'll be using as a reference from here on in.
DNN is definately moving in the right direction from a design/HTML/CSS point of view and these are all good steps towards an optimised CMS.
Thanks for all your efforts.
By Rick Beddie on
Monday, June 07, 2010 5:56 PM
|
Re: The New and Clean Default.css (Beta)
@Jay: thanks for the feedback!
We did talk about the option to allow loading default.css using different approaches. However, as Scott mentioned, we can do all that but it will take time to coordinate with engineering team to make it into an official release. I don't think it is hard to accomplish, just a matter of good timing and which effort the team should focus on first.
I'm a big believer in making things happen rather than talking about forever. Therefore I'd rather take baby steps and see the progress we make that would benefit the community than waiting till the perfect timing to do something. But we certainly want to make this CSS handling works properly.
By Cuong Dang on
Tuesday, June 08, 2010 11:38 AM
|
Re: The New and Clean Default.css (Beta)
Is there an acid test of sorts for this file? I've saved 5k with a few basic optimizations and "better practises" but I need a definitive test bed.
Re backward compatibility, one assumes this will be an optional download or only available in 5+ installs/upgrades... so what is the point of any backward compatibility on some of these blocks? At the very least, we could annotate the sections as legacy so site administrators could easily remove them.
If the UX team is working on a new CSS concept, I would VERY interested in being involved.
By lance on
Tuesday, June 08, 2010 2:12 PM
|
Re: The New and Clean Default.css (Beta)
h1, h2{font: #666644 normal 20px Tahoma, Arial, Helvetica, sans-serif;}
Why is the default css file imposing it's will on standard tags? These should be empty styles for html tags. I never understood why these needed to be in default.css when they will be declared in my skin css anyways.
By ech01 on
Friday, June 11, 2010 12:42 PM
|
Re: The New and Clean Default.css (Beta)
@ech01 I know these might not make sense at this moment but since we don't want to make any breaking changes for the existing skins out there, we decided to keep those properties intact. The work we've done are pretty much a lot of CSS grouping and shorthand techniques tidy it up.
By Cuong Dang on
Friday, June 11, 2010 12:53 PM
|
Re: The New and Clean Default.css (Beta)
@lance we'd love to have people involved in the process. send me an email and I'll follow up with you. Thanks! (dang[dot]hcmc[at]gmail[dot]com)
By Cuong Dang on
Friday, June 11, 2010 12:55 PM
|
Re: The New and Clean Default.css (Beta)
Sorry Cuong, since I never use purchased skins, this never occurred to me. I guess it makes sense, but at some point we have to cut the cord to the past. I understand the need for backwards compatibility, especially in core modules and functions, but skins are easy to fix in comparison. In fact, if you did an upgrade and the skin is broken as a result of a new default.css file, can't you just reload the old one?
Thanks for the effort, Cuong. It's at very least, a small step in the right direction.
By ech01 on
Monday, June 14, 2010 2:27 PM
|
Re: The New and Clean Default.css (Beta)
+1 ech01 - this has been the most frustrating part of working with DNN since the beginning - the pollution of style rule for standard tags. Default.css has improved significantly in v5, but there are still global H1-H6, TFOOT, THEAD, TH, IMG, A, SMALL, BIG, BLOCKQUOTE, PRE, LI and HR rules in there.
I can't understand why this was ever done: where styling is needed for admin elements (e.g., headings on admin pages), this could have been done via classes on each element (e.g., "H1.dnn"), or qualifying via parent classes (e.g., ".dnn H1").
All style rules that affect CONTENT should be in the skin CSS alone - the end result for the default install would be identical: content would appear with default styling. But when creating one's own skin, we wouldn't have to include a block overriding the various default.css styles every time.
Hopefully this won't be far off. I appreciate the point about legacy skins - but this could be dealt with via a tickbox or detecting the version in the skin manifest.
Before anyone suggest editing "default.css" to remove the offending styles, or unloading via "UnloadCSS" - the former means that have to manually maintain a customised copy of default.css across upgrades (when it often changes); the latter effectively means the same, as we need copies of the "filemanager" etc style rules.
Cheers, BJ
By B Johnson on
Monday, June 14, 2010 6:10 PM
|
|