Initial conversion from MediaWiki, 20170204

1 files changed, 115 insertions, 0 deletions

diff --git a/frames.mdwn b/frames.mdwn
new file mode 100644
index 0000000..c1b1bc2
--- /dev/null
+++ b/frames.mdwn
@@ -0,0 +1,115 @@
+[[!meta title="Frames"]]
+[[!meta author="James Bursa"]]
+[[!meta date="2011-11-26T22:20:19Z"]]
+
+
+[[!toc]] HTML5 Spec:
+
+-   [4.8.4 The iframe
+    element](http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element)
+-   [11.5 Frames and
+    framesets](http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#frames-and-framesets)
+-   [12.3.3
+    Frames](http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#frames)
+
+This is just a quick draft of a proposal for changing how frames are
+handled in NetSurf. Updates, changes, comments, etc are welcome.
+
+Current frames implementation
+-----------------------------
+
+See the [[frames documentation|documentation/frames]].
+
+### Problems
+
+-   Complication of front end / core interface
+-   Only RO implementation works
+-   Not possible on some platforms
+-   Front ends poke around inside several browser\_windows per window
+    (or tab)
+-   Can be several gui\_windows per window (or tab)
+
+New frames implementation
+-------------------------
+
+In the following, "*canvas*" refers to the front end's "surface" onto
+which it plots whatever the core tells it to. There would only be one
+per window (or tab).
+
+The front end only creates one gui\_window per window (or tab). It never
+needs to know about browser\_window objects, which will be internal to
+the core. The front end tells the core the size of the viewport. The
+front end never knows whether the viewport contains a simple page or a
+frameset, it just passes mouse actions in and plots into the canvas as
+the core instructs it.
+
+For iframes, the core just renders the HTML content in the area of the
+page that the iframe occupies during HTML redraw. If scrollbars are
+present they are handled by the core scrollbar widget, and html\_redraw
+calls for them to be redrawn. Clicks and mouse movement over iframes are
+passed on through to the content in question. IIRC we "drill down" into
+iframes already, so apart form getting the scroll offsets this may
+already be implemented.
+
+For framesets, the canvas area we render into does not exceed the size
+of the viewable area in the window. So canvas size is equal to viewport
+size, and the front end's surface would be unscrollable. This means for
+large fixed-size frames in a small window, part of the frameset would
+get cropped. html\_redraw would be updated to handle framesets. The
+canvas would be split up into rectangles with different contents in each
+rectangular area, according to the frameset. If the frame is scrollable
+and has scrollbars, scrollbars will be rendered for it. The core mouse
+tracking and clicking handling would be updated to handle framesets. It
+also needs to handle actions on the framesets themselves, e.g. frame
+resizing.
+
+For regular pages (and possibly root framesets containing one frame and
+no nested framesets), the rendered canvas size is defined by layout in
+the normal way. So canvas size may exceed front end viewport size,
+making the front end's surface scrollable.
+
+### Evaluation
+
+#### Advantages
+
+-   Much easier to develop a NetSurf front end
+-   Simplify existing front ends
+-   Fixes frames in all front ends without any work from front end
+    maintainers
+-   All frames stuff in the core, so if somone fixes or improves it,
+    it's improved on all platforms
+-   Fixes thumbnailing
+
+#### Disadvantages
+
+-   Don't get native scrollbars or surfaces for individual frames
+
+Mitigation - core scrollbar widget could optionally be overridden by
+front ends for native looking scrollbars
+
+### Changes required
+
+-   html\_redraw() changed to handle frameset & iframe internally
+-   Mouse tracking and click handling updated to handle framesets
+-   Need to pass scrollwheel events to the core. If whatever the core
+    has under the pointer can't be scrolled (further in that direction),
+    the core tells the front end that it couldn't scroll anything and
+    the front end can scroll the main viewport.
+
+Thumbnailing should "just work".
+
+Scrollbars
+----------
+
+Possibility of front ends overriding core scrollbar widgets, for native
+look.
+
+-   Need to tell core the scollbar widths for layout
+-   Override scrollbar redraw
+-   Handle scrollbar clicks and core-generated scrollable area movements
+
+Other considerations
+--------------------
+
+-   Frames history - Whole different kettle of ball games.
+