SWF seeking VWM

Slim-Waisted Frameset seeking Valid Working Markup for harmonious live-in relationship. Introduce me to new style that everyone can love. Otherwise, you must be able to understand and accept the cosmetic tricks I use to hide my own stretch marks.

Give it up. It’s a fantasy. It’s a dream. Never meant to be. Not now. But why?

By nature, framesets possess borders that magically show up between each frame. Borders which vary in appearance and thickness in each browser. They generally take on a three-dimensional “chromed” appearance of 2 to 6 pixels in width, depending on browser and platform. By current (and past) specifications, (X)HTML only allows the single frameborder attribute to control borders on frames. It can have a value of “1” (borders on), or “0” (borders off). And frameborder can only be placed inside the frame element. That’s it. End of story.

The problem with this limitation is frameborder can only turn off the grayscale chrome-like border effect between frames. But when turned off, it leaves behind the exact amount of space the border previously occupied. However wide the border was is now filled with blank (usually white) space, still leaving the frames completely separated. There is currently no valid means to affect the width of this cleft, 3-D border present or not. You’d think this would have been addressed by now. Oversight of the W3C HTML Working Group?

What about using CSS? Surely the border could somehow be eliminated by rule of style. Several readers suggested slight variations to the methods I tried last week. Some even included the application of margin, padding, and border attributes to style the html element itself. I had never seen nor tried such a thing. Alas, none of them brought success or seemed to have any impact on our beloved spacing between frames.

One reader stated removal of frame border/spacing was equivalent to hijacking the browser, withholding frame resize control. Valid point for some browsers. When the border/spacing disappears, the ability to resize “resizeable” frames gets lost, or becomes very tricky. But that’s why we have the noresize attribute for frames. And in some cases, we choose to set frames to “noresize”. Another reader provided links to archived discussion from css-discuss (archive not working at time of writing) stating that frame borders are not unlike other pieces of “browser chrome”, such as toolbars and menus. Browser appearance isn’t normally addressable by the loaded document’s CSS, except in proprietary cases, like IE/Win’s scrollbars.

Warning: Invalidity Around the Corner

I’m not alone in this framed frustration. Quite a few have written since last week sharing their struggle with the exact same issue. Some gave up on validating their markup. Some gave up on frames entirely. Either road is not one I go down happily.

Not content with the sparse resources I found on the issue, I put together a semi-comprehensive Frame Spacing Test and recorded the results in a table for all browsers to which I had immediate access.

The border attribute was a late entry to the game, and welcomely eliminated the space in all browsers. Except IE5.2/Mac. And as testing shows, this browser requires both frameborder and framespacing to completely eliminate the gap.

Assuming we must continue to use frames, and that the default stretch marks between frames are unacceptable, the alternative is to give up validation for the frameset file, and use the attributes that display our frames prop’rly. Pete Fairhurst wrote to say he came to the same conclusion. He includes comment tags within the frameset HTML above the offending markup, noting the awareness of invalid attributes, and stating they’re essential to display that application as intended. In this case, I’m choosing to (and will recommend that my client) do the same.