Part of the problem with frames is that they are (as I understand things) designed to support the display of both local and remote content dynamically. Some such content is intended to be available to the browser for manipulation, some is not. Alack and alas, I do not understand the details of these restrictions and the circumstances where they apply. There are certain circumstances where understanding these restrictions could, perhaps, be made unnecessary by creating a frame that is intended to be a child of the same document object as its parent. In other words, the frame would never be used to display a different URL than that of the parent.
The way it stands now, the DOM support for a frameset seems kind of like this:
<frameset>
<reallyWeirdKludge>
<frame>
<HTMLDocument/>
</frame>
</reallyWeirdKludge>
<reallyWeirdKludge>
<frame>
<HTMLDocument/>
</frame>
</reallyWeirdKludge>
</frameset>So what you end up with is a DOM structure that may, or may not consiste of nested Document objects. Not to mention the fact that this is basically HTML specific, rather than XML + CSS or somethig similar.
Now if I have some kind of multi-page form to work with. Let's call it Cert-O-Matic for the sake of discussion (I got Tidy to accept it BTW). I may want to have a frame for controling the overall flow of filling out the form, and one for entering the data. The traditional way of doing such a thing is represented by my pseudo-code above. The problems I usually encounder have to do with the <reallyWeirdKludge/> element. If I could work within a known closed environment where all content is from the same DOM tree, it seems to me, I might be able to work with 'frames' more efficiently.
A restricted XUL implementation might accomplish the same thing, and more. As it stands, XUL has security issues which seem to be the inverse of the standard browser's restrictions. If an XUL with inverse security were available, perhaps that would be the answer to all of this.
Does any of what I'm saying make sense?
