This topic explains some problems you might experience when using CSS style to control how your widgets display when rendered in a browser. Fortunately, many solutions are available to help solve these problems.

This topic explains some problems you might experience when using CSS style to control how your widgets display when rendered in a browser. Fortunately, many solutions are available to help solve these problems.

Understanding the problems

The following list provides some common problems you might encounter when you use CSS style to control the appearance of your widgets:

The CSS namespace can fill up quickly when you are working with several CSS files and multiple widgets.

Developers often create styles simply to fix side effects, which in turn might lead to more side effects and conflicting declarations.

Styles are not isolated from other styles. When widgets are rendered on a page, styles can be affected by other styles and also by other HTML elements that are loaded on the page.

Styles can rely on libraries such as the Dojo Tundra style, but you can not always guarantee that every environment will load or reference Tundra.

When using basic element selectors, such as the following input construction, elements of other widgets are often impacted unexpectedly:

input {

/* ... */

}

Solving the problems

See the following suggestions for solving the problems discussed above:

Since multiple elements might share a common name, do not use ID-based declarations, for example:

#my_id_may_be_used_twice {

/* ... */

}

Use the myClassForInput class instead of the myClass input class to prevent child elements, such as Dojo dijits that are loaded within the <element class="myClass"> string, from having the styles attached to their input elements. For example, the following code is not recommended:

.myClass input {

/* ... */

}

<div class=”myClass”><input>...

Instead, use this code:

.myClassForInput {

/* ... */

}

<input class=”myClassForInput”>

Note:

When using the recommended code, attach class="myClassForInput to your input boxes. Also, be aware that using input.myClassForInput selectors might run slowly on the Microsoft™ Internet Explorer browser.

Avoid using the :hover pseudo class on non-link elements such as <a> to prevent performance issues when using Internet Explorer.

To prevent collisions, use the same name or prefix for your class selectors as those used by the widget namespace. If your widget's JavaScript™ class is declared as com.ibm.widgets.SomeWidget, all your CSS prefixes should be com-ibm-widgets-SomeWidget, for example:

.com-ibm-widgets-SomeWidget {

/* ... */

}

If you need additional classes, always use the prefix. For performance reasons, the following example is not recommended:

.com-ibm-widgets-SomeWidget .Button {

/* ... */

}

Use this code instead:

.com-ibm-widgets-SomeWidget-Button {

/* ... */

}

Code styles inline when they are used only one time. The following code is not recommended:

.onceOnly {

display: none;

}

<div class="onceOnly">

Use this code instead:

<div style="display: none;">

If you are using shared code, you can not always predict the structure of that code. Therefore, if you are using a URL Dijit, Dojo dijits, or other type of shared code, apply your selectors only to elements that you know. The following code is not recommended:

<div class="myClass">

<div>Content</div>

<div dojoType="unknown.Dijit">

<!-- This dijit will be affected by myClass -->

</div>

<div>Content</div>

</div>

Use this code instead:

<div>

<div class="myClass">Content</div>

<div dojoType="unknown.Dijit">

<!-- This dijit will remain unaffected by myClass -->

</div>

<div class="myClass">Content</div>

</div>

When using Dojo templates, if you do not know the final class name, for example when versioning is applied, use the following code to calculate the style name. For JavaScript, use this code: