[whatwg] Frames.

Andrew Fedoniouk 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. [1]
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. frameset

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:

<body>
<h1>HTML 5 elements</h1> 
<frameset cols="200px, *">
    <nav class="toc">
       <h>TOC:</h>
       <ol>....</ol>
    <nav>
    <frame class="content-panel" />
</frameset>
</body>

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
these days.

2. frame

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.
<html>
<body>
  ...
  <frame>
       <html>
            <body>...</body>
       </html>
  </frame>
</body>
</html>

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: 
<form>
  <frame contenteditable name=e-mail-body />
  <button type=submit>Send</button>
</form>

-----------

Andrew Fedoniouk.
http://terrainformatica.com


[1] http://www.terrainformatica.com/htmlayout/doxydoc/index.html

More information about the whatwg mailing list