Framesets, Frames and IFrames

Richard Wilson info at tinct.net
Mon Aug 7 16:14:37 BST 2006


Hi Everyone!
 As most of you know, I've been updating the relevant chunks of NetSurf to
allow for a more pleasing frame implemtation using the native window
manager. The basics are complete, but there are still quite a few issues and
suchlike that need to be resolved before it gets anywhere near SVN.
 First of all I best explain how things have changed internally. Set your
typeface to fixed width and prepare for some really badly drawn diagrams.


How we now handle <frameset>, <frame> and <iframe>
==================================================
 The diagram below shows the basic manner in which we extract and then later
create the frame when the window is opened, ie when we have a browser_window
to attach the information to.


 
+---------------------------------------------------------------------------
-----\
   |
|
   v
|
[Fetch] --> [Box Conversion] --> [Box Tree] --> [Browser Window] -->
[Rendering]    |
                    |                                  |
|
                    v                                  v
| 
         [Frame Data Extraction] - - - - - - - ->[Frame
Creation]-------------------/


 The actual parsing code is much the same as previously except I've added in
parsing of various extra flags that I intend to support (no_resize,
frameborder, border, bordercolor, marginwidth, marginheight.) For IFrames
this also means storing the owning box so that the frame can be positioned
correctly on a reflow -- this is currently not done for a frameset, but this
will eventually be necessary as we could have an <object> pointing to a
frameset (I can't see any real difficulty in doing this.)
 The frame name (for targetting) is attached to the browser_window, as are
the parent, children (<frame> withing a <frameset>) and inline frames. One
benefit here is that it allows us to perform targetting exclusively in
browser_* which simplifies things.


Things that have been changed to achieve this
=============================================
 There's actually very little code change that's happened because this code
required it. There are a few notable changes that may benefit other pieces
of code though so I'll briefly mention them here.

 * The RISC OS GUI window can be styled a lot more. Everything is read from
the browser_window so this should mean NSGTK can be updated fairly simply.
It also means that if we ever need to make NS run as a plugin to an e-mail
app or suchlike then we have the relevant code already in place.
 * Content is layed out again on width and height changes. This fixes
various issues, including background images not extending the full height
until a horizontal resize and the extent being too great in a similar
manner.


Things that are currently a bit pants
=====================================
 It's quite obvious that iframes need more work, and by more work I mean
actually properly looking at. The main thing I really really hate is the
fact they get loaded twice (once into the parent tree and once as a child
window.) I'm not entirely sure how to achieve this, so some comments on this
area would really be very helpful.
 Frame resizing isn't implemented at all. I got as far as adding a ptr_lr
icon before realising that the w3c spec says pretty much nothing about how
it should work. Given a grid of things specified in relative, percentage and
pixel values, how do you modify the dimensions of the pair? There are 6
basic size pairings, which I think should probably be updated such that:

	RELATIVE, RELATIVE	*, *	=> 1.1*, 0.9*
	RELATIVE, PIXEL		*,200	=> *,250
	RELATIVE, PERCENT		*, 50% => *, 60%
	PIXEL, PIXEL		200,200 => 150, 250
	PIXEL, PERCENT		200, 50% => 250, 45%
	PERCENT, PERCENT		20%, 30% => 21%, 29%

 If anyone else has any ideas on how things should move about then now's
probably the best time to start shouting. I'm not especially looking forward
to this code, so if you should too loudly you may get told to write it
yourself...
 Frame margins are read correctly and stored to the browser_window which
then fetches the content. I was thinking that we could create a stylesheet
from these and pass this with go_post so you're flow is basically:

 1) Create browser window from frameset
 2) Create stylesheet for margins (and possibly other CSS styles later on)
 3) Call _go_post with the stylesheet
 4) Stylesheet is merged with our default stylesheet and then with the page
stylesheet etc

 By implementing frame margins correctly we would fix quite a few framesets
that we currently cause to have scrollbars.


Things that have got worse
==========================
 The obvious thing here is history. We need to recursively store the entire
frameset details and then recreate this accordingly. I've vaguely begun this
by moving all the page data associated with a history_entry into a separate
'struct page' which can then be updated accordingly. I'm not too sure about
the best way to handle framed thumbnails though, but creating a thumbnail of
each frame and scaling them/positioning them accordingly wouldn't be /too/
tricky.
 Printing currently works with whichever browser_window the action was
initiated from, or the top level window for the toolbar. This actually
applies to all actions (back, forwards etc), so you can easily view the
source or suchlike from any of the frames quite easily (a Frame-> menu item
may be useful, this is definitely something for Michael to go off and be
creative at rather than me look at it as I'll just do whatever's easiest.)


Feedback?
=========
 I'm working away for a while, so don't expect any prompt replies (and I'm
sorry if this post is a bit rubbish and rambling I'm in the middle of a
dozen things at the moment.) There's a copy of a recent-ish version of my
new code on Rob's FTP server, so feel free to take a peek. Anyway, James now
officially owes me a beer for actually beginning to document all this stuff.
I'll wait until you're back from America though as I don't want any of that
watery rubbish...



R.






More information about the netsurf-dev mailing list