These projects are retired. The development has stopped and we don't provide support for them anymore.

Leaving the existing classes

At first we started using parts of several existing classes and guides :

Initially we mainly based ourselves on the classes found on the Dynamic Duo site. We were quite satisfied with it in the beginning, but as we progressed there were a number of features which were lacking in the underlying design :

  • the layer size and position were fixed and not relative to the browser window or parent layer,
  • access to nested layers was not transparently handled amongst different browsers,
  • the code that had to be inserted in the actual HTML document was not centralized and still a bit too long to my likings,
  • first the available area of the layer had to be defined which then had to be clipped to the actual visible area.

When trying to add these shortcoming to the existing classes by integrating parts of other code, we quickly noticed that it would be better to start from scratch and design a class of our own.

Focus on web design

The main guideline that was adopted to design the functionalities of RelativeLayers, was that layer creation and definition should be completely oriented to web design and not to web programming, without losing the power and flexibility of direct manipulation through code. This means that when thinking of the positioning of layers and their dimensions, it should be possible to write and maintain the code that executes the imagined design in an intuitive and immediate manner. To achieve this, the current model of layer definition is not appropriate in several areas :

  • The position and size of the layers is still defined as a fixed number of pixels. This is acceptable when one knows which size the containing window will be. However, since screen resolutions vary and windows can be re-dimensioned, this information is not constant and enforcing a predefined window size lacks user-friendliness (see Figure 1-1 and Figure 1-2).

    Figure 1-1. Layers defined with a fixed number of pixels, before and after resize of the browser window.

    Figure 1-2. Layers defined with relative dimensions, before and after resize of the browser window.

  • Designs made with layers have to be envisioned in terms of available areas which are clipped to there visible parts. This is very uncomfortable since each time a layer is repositioned or re-dimensioned during the design process, intermediate calculations have to be performed before being able to adapt the actual code. (see Figure 1-3 and Figure 1-4).

    Figure 1-3. Layers envisioned first with the available area and then clipped to the visible part.

    Figure 1-4. Layers envisioned first with the visible part and then the available area is defined in a relative manner.

  • Positions are always defined relative to the window or the containing layer. In advanced designs, elements are often dependent on the position and size of other elements. This requires additional coding and maintenance to ensure that all the layers are in the right place when some of them are moved or resized. (see Figure 1-5 and Figure 1-6).

    Figure 1-5. Layers positioned relative to their parent.

    Figure 1-6. Layers positioned relative to another layer when needed.

  • Lengths are always literal values. When a design changes, the calculations that are required to obtain these values have to be remembered, changed and performed again (see Figure 1-7 and Figure 1-8).

    Figure 1-7. Lengths defined as a single value.

    Figure 1-8. Lengths defined as expressions to remember to logical and make it easy to adapt.

The solutions that RelativeLayers offers to all these issues make the creation of advanced designs significantly faster and much more understandable. Imagined design concepts and their relations can exactly be transposed to code and maintained without having to keep seperate notes about the construction process.

Extending the event model

Javascript always has had an event model that can tie only one handler to one event type for each object. Typically this is done through the use of simple definitions like :

layer.onclick = clickhandler;

Working like this can be sufficient for basic scripting needs. More elaborated DHTML applications however, require the possibility to register as many listeners as needed and to remove them at will. This offers an event model that is completely similar to what can be found for the development of regular GUI applications with modern toolkits such as Swing, Qt and Gtk+. In RelativeLayers, event listeners can be registered like this :

layer1.addEventListener("click", handler1);
layer1.addEventListener("click", handler2);

function handler1(event)
{
    // do something
};
function handler2(event)
{
    // do something
};

The extended event model contains a large number of additional event types that provide access to the new functionalities of RelativeLayers. Custom event types can be transparently integrated, gaining instant access to all the new features.

Adapting to the browsers

The features of RelativeLayers were very carefully designed to make sure that as many browsers as possible were able to use the core functionalities. The following list contains the browsers and platforms that are constantly checked and targeted. A complete list of all the tested versions and supported features can be found in Appendix A.

  • Netscape 4.x, 6.x : Linux, Windows and Macintosh,
  • Internet Explorer 4.x, 5.x : Windows and Macintosh,
  • Mozilla 0.8 (and higher) : Linux, Windows and Macintosh,
  • Opera 5.x : Linux, Windows and Macintosh.