Tuesday 30th of May 2017 07:22:58 AM

Creating Themes with CSS and JavaScript

04/27/2001

You probably have already heard about themes, but you might not know how to incorporate them into your own site.

Commonly, a theme refers to a set of graphics, color, and layout definitions that can be applied to a user interface to give it a specific look and feel. A "theme-able" application lets a user select between different looks of this application.

A well-known representative is Winamp or Netscape 6. The concept of themes is a relatively new and important development in the evolution of modern GUI applications. Themes give users the ability to choose or create individual interfaces easily for enabled applications without the need to recompile them. You might even consider this as an end-user related aspect of the growing open-source idea.

However, back to some Essential JavaScript and web application development. Clean markup, a set of style sheets, some cookie crumbs, and a pinch of JavaScript will let your visitors choose between different looks of your site and store this as their preference. However, even if you're not interested in doing this, you might read on to learn a little more about "good style."

System requirements

Basically, you only need a very basic set of technologies for the solution: some CSS support and a working JavaScript engine. This means you can run our script in, for example, both Netscape Navigator and Microsoft Internet Explorer versions 4 and up, Mozilla, Opera 4 and up, and Konqueror.

The drawback is that it may not be possible to use CSS in full effect for older 4.x platforms because of erroneous and incomplete CSS support. As a rule of thumb you should only try it with the newest browsers available (IE 5.5, Netscape 6, Opera 5, and Konqueror). The RichInStyle site provides a good list of CSS bugs and support.

Some background

Basically any application has to match one important prerequisite to switch between different themes: it must separate the data of the application -- the model -- from the view of the data. Both components are connected and controlled by a controller.

In terms of OOP, this is called the model-view-controller (MVC) concept, Java's GUI toolkit Swing is probably the most famous representative.

Unless you're totally new to web development, this concept should sound familiar to you. HTML and XML-based languages are designed to give structure to information, allowing you to form a model of your data. In addition to that, you can define the presentation -- the view -- of any element using CSS. JavaScript is the active glue between the two static components. Hosted in a browser, it forms the controller component.

Model-view-controller

After identifying the components, let's specify their roles in relation to our task:

Implementation

1. Prepare your documents

As explained above, your HTML files should only contain structural markup after the first step. A good place to learn more about separating model and presentation is Jakob Nielsen's UseIt site. Other great places to start are pages about accessible design, such as the Web Content Accessibility Guidelines and the accompanying Techniques for Web Content Accessibility Guidelines.

2. Create themes

This step assumes at least some basic knowledge of the attributes supported in CSS. If you're new to CSS, you should read some introductory material first.

After organizing your information, you're ready to give it a visual representation. You can define styles for a certain element type, classes of elements, and individual elements, and apply them using CSS selectors. With CSS, you can also define elements to become invisible, this allows you to have even greater control over your layouts. It's especially important to identify all parts you want to give distinct views in different themes and to use a clever naming system.

  • Create your own Java object model (adapter) that uses DOM to manipulate the information in your document object tree (that is created by the parser). This is slightly different from the 2nd option, because you are still using the DOM API to manipulate the document information as a tree of nodes, but you are just wrapping an application specific API around the DOM objects, so its easier for you to write the code. So your object model is an adapter on top of DOM (ie, it uses the adapter pattern). This application specific API uses DOM and actually accesses or modifies information by going to the tree of nodes. Changes made to the object model still have to be made persistence (if you want to save any changes). You are in essence creating a thin layer on top of the tree of nodes that the parser creates, where the tree of nodes is accessed or modified eventually depending on what methods you invoke on your object model.
  • Depending on which of the three options you use to access information using your Java classes, this information must at some point be saved back to a file (probably to the one from which it was read). When the user of your application invokes a File->Save action, the information in the application must be written out to an ApplicationML file. Now this information is stored in memory, either as a (DOM) tree of nodes, or in your own proprietary object model. Also note that most DOM XML parsers can generate XML code from DOM document objects (but its quite trivial to turn a tree of nodes into XML by writing the code to do it yourself). There are 2 basic ways to get this information back into an ApplicationML file: