Web Standards for DotNetNuke

Excerpt from DotNetNuke and Web Standards

By Cuong Dang

Web standards are sets of recommendations published by W3C to encourage industry professionals to use the latest technologies in their web development approach. The most notable recommendation is the transition from HTML to XHTML.

Many organizations in the world besides W3C publish such recommendations; the European Computer Manufacturers Association (ECMA) is an example of an organization that is responsible for standardizing JavaScript. But in this Wrox Blox, we only focus on the recommendations of the W3C to help designers and developers make their DotNetNuke web sites standard-compliant.

The Benefits of Using Web Standards

There are many resources available discussing the benefits of using web standards. If you’re still busy coding the old way, I’d recommend taking a few minutes to browse the Web and hear what others have to say about the new approach in web development and the current web standards to get the full picture. Meanwhile, here’s a list of the principal advantages in using web standards for web development:

  • Cleaner Markup Leads to Increased Productivity—Whether you work by yourself or in a team environment, coding with web standards provides tremendous time-saving for both you and others who use your code. If all developers follow the W3C recommendations, we will all be speaking the same language. It simply helps developers work well together.
  • SEO-Ready—Coding with web standards provides an advantage in search engine optimization (SEO) because the markup is not only meaningful to humans, but also to machines. (Meaningful markup means that it is easy to interpret for the browsers and easy to read for web developers.)
  • Less Code, Faster Page Load—Because we use XHTML and CSS to create meaningful markup to separate content and presentation, the browser will load the page much faster and improve the user experience even for those browsing at a slower Internet speed.
  • Reachable by Larger Target Audiences—With appropriate markup, web sites are accessible by larger target audiences such as users with disabilities or visitors using a variety of platforms and browsers to view your content.
  • Ease of Maintenance and Updates—Using web standards prepares your code to be compatible with future web technologies and helps reduce maintenance and update time. Keeping up-to-date with the latest technology standards means that upgrading and maintenance will be more cost-effective in the long run.

Applying Web Standards in DotNetNuke Programming

Currently, the DotNetNuke community has limited resources or endorsements by developers for building web sites and applications using the web standards approach. To gain the benefits mentioned above, developers should increase their efforts to adopt the web standards approach in creating modules and skins. This will help improve the quality of the ecosystem around the DotNetNuke framework.

There are two essential parts in the framework that could be improved to properly render a DotNetNuke web site in a standards-compliant mode: modules and skins. Modules essentially provide the features and functionality of a web site in the DotNetNuke framework. Skins control the design or look and feel of a web site and are developed by DotNetNuke skin designers.

DotNetNuke is pushing their effort in version 5 to make the framework (not modules) standard-compliant. Skins and modules are the two elements that we need to put more effort into to comply with the web standards approach.

In this Wrox Blox, you will learn about making your DotNetNuke web sites web-standards-compliant, starting with the skins. But first, you need to learn a few basics of the new web standards. The next sections show you some differences between HTML and XHTML and explain the DOCTYPE declaration, to get you started on applying the new web standards.

HTML versus XHTML

Simply put, XHTML is a new way of writing your HTML document but in a stricter format. XHTML maintains backward compatibility to older browsers while preparing for more modern browsers. XHTML isn’t hard to learn; it just takes a little time and patience to update your coding habits.

There are a few elements from HTML that are not supported in many modern browsers, compared to XHTML, but that shouldn’t be a hurdle in moving forward. Here are a few simple rules to follow when writing XHTML markup:

  • All Tags Must Be Closed—HTML allows you to open tags without closing them, and the browsers still load and display the data correctly. However, when writing in XHTML, you must close all tags, as shown in the following example:
  • Invalid:

    <h2>XHTML vs. HTML

    Valid:

    <h2>XHTML vs. HTML</h2>

  • Close All Empty Tags—A single space after br orhr and before the trailing slash (or forward slash) is required:
  • Invalid:

    <br>or<hr>

    Valid:

    <br />or<hr />

  • Close Self-Closing Tags—Self-closing tags such as this should be closed as well:
  • Invalid:

    <img src=images/header.gif>

    Valid:

    <img src=”images/header.gif” />

  • All Attributes with Values Must Be in Single or Double Quotes
  • Invalid:

    <div lang=en-us>Your Content</div>

    Valid:

    <div lang=”en-us”>Your Content</div>

  • All XHTML Tags and Attributes Should Be Written in Lowercase
  • Invalid:

    <DIV> or <IMG>

    Valid:

    <div> or <img />

These are just a few simple examples of some basic differences between HTML and XHTML standards. A detailed tutorial is beyond the scope of this Wrox Blox. If you wish to learn more about these recommendations or standards published by W3C, please visit the official web site at www.w3.org/TR/xhtml1/.

When you’re new to web standards, having a utility plug-in with your browsers to help validate your markup is beneficial. W3C validation mechanisms can find and detect the errors or warnings on the page and suggest solutions or alternate approaches to coding certain elements on the page.

You can validate your XHTML via the web address, file upload, or by direct input of your markup. For more options, see the following URL: http://validator.w3.org/.

If you are a Firefox browser fan, there are many plug-ins that are very helpful to assist in validating markup. One of my favorite plug-ins is the Web Developer Toolbar add-on. Find the download at https://addons.mozilla.org/en-US/firefox/addon/60. This plug-in allows you to validate not just HTML, but your CSS skills as well.

Document Type Definition

While writing valid markup is a very important fundamental step, it isn’t enough to get your content to render properly in all browsers. The DOCTYPE, or Document Type Definition, is the first line of (X)HTML markup that a web document should have, before the HTML and HEAD tags. The purpose of the DOCTYPE is to inform the browsers that the author of this document used a specific language (HTML 4.0 or XHTML 1.0) so that the browser will interpret and render the page in standard compliance mode rather than “quirks” mode (a terminology for a non-standard compliance rendering of browsers). Therefore, before you start writing any markup, you should decide which DOCTYPE is right for your project.

There are three common DOCTYPEs currently being used by many web designers and developers:

  • Transitional
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

The Transitional option is recommended for any project that may include deprecated HTML syntax.

  • Strict
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

The Strict option is appropriate for projects in which you might have complete control over the coding techniques.

  • Frameset
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

The

Frameset

option is used when your projects require frames to be embedded on the page.

To use the right DOCTYPE for your project, you must first understand the requirements and define the appropriate language to achieve the broadest range of visitors from all platforms. You will learn how to implement DOCTYPE in DotNetNuke skinning later in this Wrox Blox.

While XHTML and DOCTYPEs are not the only web standards elements that apply to DotNetNuke programming, they should give you a starting point for updating your coding practices. Next you’ll look at the DotNetNuke framework and begin applying your new knowledge.

Introducing the DotNetNuke Skinning Engine

DotNetNuke is currently the largest Open Source project built on the ASP.NET framework. The DotNetNuke skinning engine provides a powerful tool for administrators to manage the design of an existing web site with minimal effort.

The skinning engine allows designers to write their markup in HTML and transform it into a DotNetNuke skin by adding dynamic elements represented by

TOKENS

.

TOKENS

are a simplified form of skin objects (often representing dynamic elements) that allow web designers to work with skins without having a solid understanding of ASP.NET. DotNetNuke 5.0 introduced a new skinning concept to make the process of HTML skinning friendlier to designers using HTML object tags.

After converting HTML into skins, those files are then compressed and packaged into a single zip file. Through the web administrative tools, users can then install the zip file package onto a DotNetNuke web site.

Recommendations for CSS in DotNetNuke Framework

This section introduces the background of CSS in DotNetNuke and explains how to work with the default.css file to make it better.

CSS and DotNetNuke Skinning

Because DotNetNuke is a mature framework that was established before web standards received so much attention, there are many issues with consistent browser rendering. One important step of the skinning process is learning how your skin needs to override DotNetNuke’s default styles, found in the default.css style sheet.

The process is time-consuming for newcomers since they have to find the right tools to locate which CSS selectors are overridden. The default.css file needs much work (cleaning up the file for optimal performance) to smoothly improve a designer’s workflow in designing and developing skins.

While the DotNetNuke approach is to create a style sheet that allows people with limited knowledge of CSS to easily work with the framework right out-of-the-box, there is still much room for improvement. Many businesses are still using older DotNetNuke versions. This will likely result in time and financial costs when a company decides to upgrade to the latest version, as their design may not adopt the new style sheet easily.

To help reduce the time of designing and troubleshooting browser inconsistencies, it’s essential to clean up the default.css file for your DotNetNuke web sites as you design them. Here are a couple of tips:

  • You should keep those CSS selectors that dictate the look and feel of the administrator tasks, such as the control panel, module menu, data grid, and file manager.
  • CSS selectors that should be defined by designers are global links, text, headings, navigation for the site, and content text, as well as some default HTML elements, such as horizontal rule and buttons.

The Web Standards Approach to DotNetNuke Skinning: Building an Example Skin

In this section, you will build a simple skin that uses the XHTML/CSS approach. There are two approaches to DotNetNuke skinning: HTML and ASCX. This example takes a simple approach, HTML, so that both designers and developers can follow easily.

Here are the basic steps involved in putting your DotNetNuke skin together using an XHTML/CSS approach (each step will be described in greater detail later):

  1. Defining the DOCTYPE—As mentioned earlier, when designing with web standards, an important step to ensuring that the site is rendered properly is to define the right DOCTYPE. In this step, you define the DOCTYPE to override DotNetNuke default rendering.
  2. Setting up a Layout in XHTML—In this step, you create the HTML file that represents your DotNetNuke skin.
  3. Adding CSS—A CSS file is required to separate content and presentation. In DotNetNuke, you save this file as skin.css.
  4. NOTE: To make the process of creating a layout easy to follow, you just need to create a skin.css file and place it in the same folder with the rest of the files. I will be showing the CSS code throughout the process of creating the skin.

  5. Inserting Dynamic Elements (skin objects and panes)—After you complete the layout using the XHTML and CSS approach, you will add skin objects and define placeholders for content areas.

 

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *