Skip to main content link. Accesskey S

Coding Guidelines

Use Semantic HTML

This code adheres to semantic HTML when coding components. This means taking advantage of the built-in structure of existing HTML elements - rather than using meaningless divs and spans - and using HTML tags the way they were intended, not for their built-in visual style.

The benefits of working this way:

Adhere to Web Standards

The phrase "coding to web standards" refers to a set of best practices for creating web pages. Coding to web standards is a methodology that makes sites easier to maintain and update, and improves performance.

Here are some key principles:

Minimize CSS

The intention with this CSS is to keep code as streamlined as possible. The less code there is, the better performance is, and the easier code is to maintain and for customers to customize.

Three techniques that help in this area are:

In production, you can improve the performance of your website by shrinking your CSS (eliminating comments and extra whitespace) and combining files together (to reduce the number of HTTP requests). While we do try to avoid lots of unnecessary whitespace, our files could be compacted more before being deployed in a production environment. There are many tools on the internet to help with this task. We do not provide compacted files and leave that as an exercise for consumers of our files.

Use Accessibility Coding Techniques

Use coding techniques that make pages accessible to people with vision and mobility issues, as well as cognitive issues (we pay less attention to that one, as it is harder to define). Details on that technique are found on the Accessibility page.

Base Styles

To get rid of some of the browser differences in rendering HTML elements, we redefine a small set of base styles.

Hacks

Our philosophy for hacks is to avoid them whenever possible. You can do things to set hasLayout for IE components by putting zoom:1 in your style declarations. This has no negative impact on other browsers but fixes a lot of IE issues. It does what the holly hack {height:1%} used to do, with less side effects and without needing to be separated out in browser-targeted hack.

There are also some things we do with inline block styles in the same declaration, redefining display in an order that browsers will pick up what they need and ignore what they don't recognize. This fixes most of the rest of the IE issues that you will run into. Here's an example:

span.lotusBtn{
  display:-moz-inline-box;/*for FF2*/
  display:inline-block;/*for the rest of the browsers*/
}

You still may need to do an occasional tweak of margins or padding in IE, and for that, you can use one of the following classnames to target your hacks (including them right near the css that works for most components). These classes are added to the html tag using browser detection code.

.lotusui_ie6 - use for IE6 hacks, in place of * html
.lotusui_ie7 - use for IE7 hacks
.lotusui_ie - use when you need a hack that works for both IE6 and IE7

CSS Sprites

The CSS uses sprited graphics to reduce the number of HTTP requests and improve performance.

Custom CSS

If a product takes the code base and needs to make adjustments, but doesn't want to lose the ability to take CSS updates while they are developing, it is recommended to create a product-specific style sheet where any CSS overrides can be placed.

The Doctype

Markup and CSS is authored and tested using the XHTML transitional doctype. However, this does not necessarily mean that you must use an XHTML transitional doctype. The markup is not exploiting XHTML capabilities. It only attempts to conform to some of the basic syntax such that when used with an XHTML doctype, it will work. The two key requirements in this space are:

  1. The browser must run in standards mode (and not Quirks mode)
  2. Markup should be written such that if it were included in a page that uses an XHTML doctype, it would still work and wouldn't fail.

The second requirement means doing many of the things discussed on this page... like using well-formed markup, using lower-case tag names, making sure all attributes have quotes, etc. Some customers demand that we support use of an XHTML doctype when products are deployed in their enterprise. We realize that there are issues (especially in the area of JavaScript and the DOM) related to changing doctypes. However, even with these issues, we want to make our markup and CSS as neutral as possible and not force the issue one way or the other unless there is absolutely no other alternative.

It should be the responsibility of each consumer of this markup and CSS to determine which doctype (or multiple doctypes) they will support.

We do know that there are some known issues with vertical alignment when using the xhtml strict doctype with our CSS. We do not recommend using that doctype at this time. We do not test in any doctype other than xhtml transitional at this time.

IBM, the IBM logo, ibm.com and Lotus are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.