news at terrainformatica.com
Fri Mar 16 13:25:03 PDT 2007
Couple of thoughts aloud about that notorious <frame>s.
Sidenote: There are use cases when frames are good.
As an example: online (and offline) help systems, e.g. 
In such cases they provide level of usability higher than
any other method of presenting content of such type.
<iframe>s are defined currently in WHATWG spec but
frameset/frame are not there yet as far as I can see.
So couple of ideas about <frames> and results of experiments
with "windowless" frames I did recently.
First idea is to separate <frameset> and <frame>/<iframe>:
1.1 <frameset> alone could be used as a container where
different panels are splitted by so called splitter - UI element
that allow to changing size of panels inside.
In my interpretation/implementation <frameset> is a
block element with display-model: blocks-inside so following
markup is valid:
<h1>HTML 5 elements</h1>
<frameset cols="200px, *">
<frame class="content-panel" />
That will create two panels divided by the splitter.
First panel (nav.toc) will have static content that is
given inline. Second panel is frame.content-panel
(or iframe.content-panel , see below).
1.2. I think that it makes sense to allow <frameset>
to appear in any place where block elements are allowed.
I do not think that I need to elaborate this more. Benefits
should be clear for those who are doing practical design
If we will allow <frameset> to appear not only as
immediate child of the body then I think we can do the same
with the <frame>. This allowance will effectively eliminate
all differences between <frame> and <iframe>.
So <frame> and <iframe> can be declared as synonyms
for backward compatibility.
3. "windowless" frame
In my implementation <frame>s are windowless entities.
"windowless" here means that <frame> DOM element has
no window object associated with it. Document with the <frame>
plus loaded content of the frame constitute single DOM tree.
In such model <frame>s are close to ordinary block elements.
The main purposes of such lightweight frames are:
1) isolation of style systems for parts of the page - needed
in cases like on-line mail clients and the like.
2) isolation of script namespaces.
3) <frame> as a dynamic "update panel" in terms of AJAX.
By addition of couple of attributes host document can
share (provide default or override) style system with
the content of such frame. So dynamic update of the page
fragment will not require that ugly and highly non-effective
tricks used by AJAX.
I think that by adding some simple attribute switch for the
<frame> element frame tag can be reused for windowed/windowless
frames. If this needed of course.
4. "frameless" frames.
To extend interface HTMLElement by the method:
void loadFrom( DOMString urlRemoteDoc );
this method will replace innerHTML of the element
by the innerHTML of the body element of the document
given by urlRemoteDoc. No invocation of scripts from
remote doc should be made, all <style> blocks need to be
ignored. So this is only for pure content loading.
5. <frame> as an <input> element.
To allow <frame> be inserted as <input> element
on the <form>.
Think about the case:
<frame contenteditable name=e-mail-body />
More information about the whatwg