Diffstat (limited to 'frames.mdwn')
1 files changed, 115 insertions, 0 deletions
diff --git a/frames.mdwn b/frames.mdwn
new file mode 100644
@@ -0,0 +1,115 @@
+[[!meta author="James Bursa"]]
+[[!toc]] HTML5 Spec:
+- [4.8.4 The iframe
+- [11.5 Frames and
+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]].
+- 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
+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.
+- Much easier to develop a NetSurf front end
+- Simplify existing front ends
+- Fixes frames in all front ends without any work from front end
+- All frames stuff in the core, so if somone fixes or improves it,
+ it's improved on all platforms
+- Fixes thumbnailing
+- 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".
+Possibility of front ends overriding core scrollbar widgets, for native
+- Need to tell core the scollbar widths for layout
+- Override scrollbar redraw
+- Handle scrollbar clicks and core-generated scrollable area movements
+- Frames history - Whole different kettle of ball games.