WD-frames

Here are some comments on the WD-frames, and a proposal regarding
the FRAME name space.  The high-level point is that the composition
of HTML documents doesn't work as expected with the current
frame naming scheme.  With multi-framed documents emerging, the name
space is getting very messy because of the absence of structure.  The
structure I'm proposing is very simple: a hierarchical frame name
space similar to the traditional filesystem name space.

I'm at the point in my browser where I'm implementing support for FRAMEs.
The way I've implemented FRAMEs is to have a hierarchical
name space.  After playing with Netscape, it appears that it doesn't support 
this view - it supports a  global name space where conflicts are resolved by 
using a priority of parent first, then all sibling frames, etc.

Then I looked to the FRAMEs working draft for a resolution.  But there 
doesn't seem to be any specification of the frame name space, besides the fact 
that frame names must start with an alphabetic character with the 
exception of a few well-known frame names (e.g. "_parent").  Using these 
special names you can navigate to the root, the immediate parent, a new 
window, and the current frame.  But the FRAME WD doesn't state anything about 
name conflicts, e.g. two frames with the same names. 

So the proposal is that the name space be hierarchical.  Something like the 
filesystem name space, e.g. <A href="foo.html" target=".."> would always 
refer to the parent document, or the current document if the parent doesn't 
exist.  In general, for targeting frames, '..' moves up a level in the frame 
name space and '/' separates frame names.   Frames still name themselves with
locally unique names, but these names are now part of a hierarchical name 
space.  (So the frames themselves do not use the special '..' or '/' 
separators.)

For example, 
..
<FRAMESET rows="*,*">
<FRAME src="frame1.html" name=one>
<FRAME src="frame2.html" name=two>
</FRAMESET>
..

**The reason that a hierarchical name space makes sense is that the 
composition of functioning HTML documents into a FRAMEd document should
always continue to work.**  With a global, flat name space, this isn't
possible.  This hierarchical naming scheme that I've described is
similar to the JavaScript frame naming scheme.

Consider two functional FRAME documents, frame1.html and frame2.html.  
They both use the same frame names (one, two) , and were perhaps developed 
independently by two authors so that there is no way the names could be 
unique.  It should be the case that I can create a new web document that is 
the composition of these two:

...
<FRAMESET rows="*,*">
<FRAME src="frame1.html" name=one>
<FRAME src="frame2.html" name=two>
</FRAMESET>
...

Where frame1.html == frame2.html:
...
<FRAMESET rows="*,*">
<FRAME src="foo.html" name=one>
<FRAME src="bar.html" name=two>
</FRAMESET>
...

This composition doesn't behave as expected in Netscape.  See:

http://www.cs.berkeley.edu/~chad/frames/frame1.html
http://www.cs.berkeley.edu/~chad/frames/frame2.html

and the composition of these frames at:

http://www.cs.berkeley.edu/~chad//frames/complex.html

Examples:

Hyperlinks in foo.html would target the frame originally occupied by
bar.html (its sibling frame) naturally:
<A href="blah.html" target="two">

In fact, targets that are siblings would not have any special '..' or '/'
characters.

Hyperlinks in foo.html would target the other foo.html using the '..'
and '/' characters to navigate through the space.

<A href="blah.html" target="../two/one">

Comments?

-Chad Yoshikawa

-- 
Finger me for my pgp public key
Today's random buzzword: distributed cryptography

Received on Friday, 30 May 1997 20:58:01 UTC