From e7366bf41f68cfe07e9ea03fc4a398baecbae651 Mon Sep 17 00:00:00 2001 From: Daniel Silverstone Date: Sat, 4 Feb 2017 09:41:13 +0000 Subject: Initial conversion from MediaWiki, 20170204 --- frames.mdwn | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 frames.mdwn (limited to 'frames.mdwn') 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. + -- cgit v1.2.3