Frames, as represented by the <frameset> and <frame> tags, have been put in the DO NOT column by many people since the day they were introduced, so many years ago, with the advent of Netscape 2.0. Initially this was with good reason; broken implementations meant that the back button and bookmarking did not behave as expected in their presence. However, browser support has advanced to the point where they are not serious hindrances to navigation, and in some cases (say, when implementing a web version of a multi-paned app) they represent the best tool at hand.

With their need and usefulness thus established, we can turn to more superficial matters, aesthetics. Frame borders are one of the few areas where a web designer has minimal control. Netscape, in its day, supported a proprietary bordercolor attribute, but this has been dropped from the equivalent XHTML module. In any case, this was coarse control over the color of the border, and nothing more.

The obvious workaround is to create another frame of a narrow width (or height) and within this fake divider specify the border appearance as desired. The trade-off was that frame resizability was lost - at best the user has to drag two sets of borders (on either side of this faked divider). Fortunately, support for the browser DOM has advanced to the point where we can do something about it.

Roughly speaking, we can use the same method that enabled us to make the draggable magnifier. In this case, instead of moving a <div> in response to mouse move events, we change the frameset's cols property (or rows, as appropriate). Additionally, while we previously used an event's pageX/Y fields to determine the mouse's location, since the page itself is now shifting, these would not give us accurate data. Instead, we can use screenX/Y to get the coordinates relative to the user's screen, something that won't be changing on us.

The implementation then becomes very simple, as this example shows. There is the caveat that Firefox seems to have issues if the mouse is moved too fast (if it escapes beyond the boundaries of the divider frame, it stops receiving events), but Safari and IE 6 have no problems with the technique. A possible workaround to the Firefox limitation is to use inline frames and then attach the event handler to the root document, but this may not degrade as nicely (the given approach would look OK even with the oldest frames-supporting browser (albeit with no resizing support), while iframes are a more recent development).