DHTML Jigsaw Puzzle: Cross-Browser; Considerations

The DHTML Lab Jigsaw Puzzle, Part IV: Cross-Browser
cross-browser code considerations

Cross-browser code is not as easy as it's made out to be. At least not for medium to large applications. The puzzle definitely falls into the former category. We developed, over the last few weeks, two versions of the puzzle. In certain cases, the code was similar. Property names differed, but the logic was the same. In other cases, the code and code logic was drastically different. For example, the creation of piece elements or the re-shaping of the puzzle after a new image load.

So, how do we tackle a cross-browser version?

First of all, we do not want two separate pages, nor do we want two separate scripts. Our goal is to have the puzzle look the same and act the same in both browsers, with a minimum of scripting. With this in mind, we consider:

1. the similarities

These are usually similar property value changes that we can accomplish with simple if...else statements (positioning, clipping, dragging). If a particular property is used many times, we can make the value change through a cross-browser JavaScript method of the object, as we do with visibility later on.


2. lowest-common-denominator

This is where we make decisions. For example, Explorer can automatically change position wrapping width for relatively contained elements when the parent is changed. Navigator requires a re-load of the element. We discussed both of these approaches, when designing the puzzle versions. Do we create an if...else and act accordingly? We could, but before we do, we should ask: "Could we make one browser adopt the code logic of the other without detrement, but with an inconsequential loss of efficiency?" In our example, Navigator cannot adopt the Explorer way, but Explorer can do it the Navigator way, so we modify the Explorer-specific code to mimic Navigator, retaining a single code-logic and no stylesheet problems.
Another example is Explorer's bottom-up and Navigator's top-down approach to default event handling. In the Explorer puzzle, we could drag the puzzle from anywhere, including the control panel, since the form buttons were still active and, if pressed, grabbed the event first, being on the bottom of the element heirarchy. In Navigator, if we allowed dragging from the controls, the form buttons are de-activated since the event is captured by the complete elControls element and not allowed to filter down to the buttons. This can be changed, of course, but it is much easier to disallow dragging of the full puzzle through the controls, and insist that the user grab the puzzle by the image.


3. non-conflicting proprietary features

If we can add throw-away features that only help the user, then we should by all means do it. The CSS2 cursor property, supported by Explorer, is an example. As we use it, it alerts the user to draggability, requires only a line of code here and there, and doesn't affect program flow.

With the above in mind, we will go through the cross-browser code, in our usual order, elaborating on our code decisions, where necessary. First, of course, we'll examine the stylesheet and HTML necessary for the puzzle.

Produced by Peter Belesis and

All Rights Reserved. Legal Notices.
Created: Dec. 17, 1997
Revised: Jan. 18, 1998

URL: https://www.webreference.com/dhtml/column11/puzzCBcons.html