I’ve been a big fan of using grid in most of my work in recent years. One of the main things I enjoy doing it is because of the symmetrical of the design and the aspect of re-using many of the CSS selectors within the same project. It’s exciting to write less markup and CSS to do more with design and implementation. And as many have heard “less is more”; by using CSS framework, it allows you to do just that.

I consider DotNetNuke community (at least the web designer community within DotNetNuke) is sort of a laggard group in adopting web standards until recently. Many people have talked and written books about the benefits of using web standards as well as how to do it properly, but I’ve seen a slow progress within DNN community.

For those of you who are using DNNMenu (or DNNNav) from the core DotNetNuke framework, you might notice there is a huge change in DotNetNuke 5.x with the inclusion of DNNMenu version 2. The change for this webcontrol had not been well documented in details so people might find a hard time to get up to speed with what’s new when using it.

As you may know, many experts in the DNN forum have been talking about eliminating SolPartMenu and start using DNNMenu for years when developing skins, but the details about controlling the design of this challenging webcontrol isn’t easy to find or even unavailable out their on the web.

Some claims DotNetNuke is notorious when it comes to performance. I beg to differ. Consider the advantage that you’ll get from using an enterprise-level platform for every web project can possibly build, a little bit of performance sacrifice is worth the tradeoff in my opinion.

But that’s not the point. You can build DotNetNuke sites that have kick-ass performance if you do it the right way. There are many respected developers in the community have spoken about this specific topic, but rarely touched on the front-end aspect. In this post, I’d like to share a few best practices that help to get the most out of your DotNetNuke site's performance by just improving front-end development approaches.

When you're using terms and privacy skinobject for your web site, it will pull in the web administrator e-mail address to display as part of a way for visitors to communicate with a site's webmaster.

If you are like me, just wanted to add something real quick and move on, you'll more likely to come back in the future when the project is done and find a way to correct it.

Well, remember during the process of installing DotNetNuke or creating a new portal for your project, you are asked to provide administrator information including name, username, e-mail address and so on? When visitors click on the terms or privacy link, they will be taken to the control that display the content pulls from a resource file somewhere on your site with the e-mail address you provided during the portal creation. If this e-mail is incorrect and you'd like to modify it, you will need to log in as an administrator and edit your profile to correct the e-mail address. I realize that a site can have multiple administrators, but this administrator have to be the one who created the portal for the change to take effect.

Recently I had an opportunity to play with UnloadCSS skinobject from Timo Breumelhof. What a nifty little tool to use for your front-end performance optimization.

I wrote an article a while back about cleaning up your default.css from the framework (or just get rid of it). There are many unnecessary CSS files get loaded within the framework (not to mention some not-so-good practices in CSS coding techniques within these files) that a web designer wants to take control of. Default.css is one of those files that need improvement.

As many of you may know, I work closely with the development team at Engage on various projects. One of the most common mistakes I’ve seen is that developers use <br /> (BR) to create padding between elements. Sometimes, I see big chuck of BR element being used across just to create a larger padding between their elements. This isn’t new to many developers; I often see it in many commercial modules we bought as well.

If you find yourself doing this religiously and not know what it means (some developers know what the BR element does but choose to do so), it is your time to change this bad habit by using the proper HTML tag: the <p> (P) tag.