diff options
| author | Sebastian Geerken <devnull@localhost> | 2015-11-01 12:58:49 +0100 |
|---|---|---|
| committer | Sebastian Geerken <devnull@localhost> | 2015-11-01 12:58:49 +0100 |
| commit | 38084cbc8a15c236bceb247492160106de2f8d3e (patch) | |
| tree | ebb4d6757b0b2d2ae6a58d45018a9abe7e6fc247 /devdoc/dw-out-of-flow-floats.doc | |
| parent | f3208e402d57f50a253c693dbc32db5d3b2e8299 (diff) | |
Clean up documentation for Elements OOF (at least remove irrelevant parts).
Diffstat (limited to 'devdoc/dw-out-of-flow-floats.doc')
| -rw-r--r-- | devdoc/dw-out-of-flow-floats.doc | 156 |
1 files changed, 89 insertions, 67 deletions
diff --git a/devdoc/dw-out-of-flow-floats.doc b/devdoc/dw-out-of-flow-floats.doc index 53c6b220..6d0777fc 100644 --- a/devdoc/dw-out-of-flow-floats.doc +++ b/devdoc/dw-out-of-flow-floats.doc @@ -1,73 +1,9 @@ /** \page dw-out-of-flow-floats Handling Elements Out Of Flow: Floats -(Note: Bases on work at <http://flpsed.org/hgweb/dillo_grows>, I plan -to split the documentation on elements out of flow into different -parts: general part, floats, positioned elements. In this document, -informations about floats are collected.) +TODO: Much missing. - -GB lists and CB lists -===================== - -Floats generated by a block which is not yet allocated are initially -put into a list related to the *generator*: - -- dw::OutOfFlowMgr::TBInfo::leftFloatsGB or -- dw::OutOfFlowMgr::TBInfo::rightFloatsGB. - -These lists are also called GB lists. - -Floats of allocated generators are put into lists related to the -*container* (called CB lists): - -- dw::OutOfFlowMgr::leftFloatsCB or -- dw::OutOfFlowMgr::rightFloatsCB. - -As soon as the container is allocated, all floats are moved from the -GB lists to the CB lists (dw::OutOfFlowMgr::sizeAllocateStart → -dw::OutOfFlowMgr::moveFromGBToCB). - -Here, it is important to preserve the *generation order* (for reasons, -see below: *Sorting floats*), i. e. the order in which floats have -been added (dw::OutOfFlowMgr::addWidgetOOF). This may become a bit -more complicated in a case like this: - - <head> - <style> - \#fl-1, \#fl-2, \#fl-3 { float: right } - </style> - </head> - <body> - <div id="bl-1"> - <div id="fl-1">float 1</div> - <div id="bl-2"> - <div id="fl-2">float 2</div> - </div> - <div id="fl-3">float 3</div> - </div> - </body> - -The floats are generated in this order: - -- \#fl-1 (generated by \#bl-1), -- \#fl-2 (generated by \#bl-2), -- \#fl-3 (generated by \#bl-1). - -Since the floats must be moved into the CB list in this order, it -becomes clear that the floats from one GB list cannot be moved at -once. For this reason, each float is assigned a "mark", which is -different from the last one as soon as the generator is *before* the -generator of the float added before. In the example above, there are -three generators: body, \#bl-1, and \#bl-2 (in this order), and floats -are assigned these marks: - -- \#fl-1: 0, -- \#fl-2: also 0, -- \#fl-3 is assigned 1, since its generator (\#bl-1) lies before the - last generator (\#bl-2). - -dw::OutOfFlowMgr::moveFromGBToCB will then iterate over all marks, so -that the generation order is preserved. +(Historical) Note: Floats make use of dw-size-request-pos, which reduces the +complexity of a previous design. Sorting floats @@ -118,4 +54,90 @@ block, for both floats and child blocks. dw::OutOfFlowMgr::Float::ComparePosition ... + +Miscellaneous notes +=================== + +Handling collisions +------------------- +The CSS specification allows two strategies to deal with colliding +floats: placing the second float beside or below the first one. Many +other browsers implement the first approach, while dillo implements +the second one, which may cause problems when the author assumes the +first. Example: the "tabs" at the top of every page at Wikipedia +("Article", "Talk", ...). + +Float containers in flow +------------------------ +Consider the following HTML snippet: + + <body> + <img src="....jpg" style="float:right"> + <p style="overflow:hidden">Text</p> + </body> + +Interestingly, dillo shows "Text" always *below* the image, even if +there is enough space left of it. An investigation shows that the +paragraph (<p>) is regarded as own floats container (because of +*overflow:hidden*), so the floats container above (<body>) +regards this block as widget which must be fit between the floats +(dw::Textblock::mustBorderBeRegarded > +dw::Textblock::getWidgetRegardingBorderForLine). However, since a +textblock in flow always covers (at least) the whole available width, +which is defined *without* considering floats, the space left of the +float will always be to narrow, so that the paragraph is moved below +the float, by inserting an empty line before. + +When searching for a solution, several difficulties show up: + +1. The available width, which is used for the width of the textblock, + is defined independent of floats. Aside from problems when changing + this definition, a dependance on floats would be difficult to + implement, since *sizeRequest* is independent of a position. (See + also \ref dw-out-of-flow.) +2. I must admit that I do not rembember the exact rationale and the + test case behind adding the exception in + dw::Textblock::getWidgetRegardingBorderForLine (see above), but + simply removing this exception will result in a possible + overlapping of floats from both containers, since no collisions are + tested for. +3. On the other hand, mixing the float containers (interaction of two + or more instances of dw::oof::OOFFloatsMgr), e. g. for + collision tests, would become too complex and possibly result in + performance problems. + +Instead, this approach is focussed: + +- Goal: the paragraph is narrowed so it fits, *as a whole*, between + the floats. +- The approach is to remove the exception in + dw::Textblock::getWidgetRegardingBorderForLine. A textblock, which + is a float container in flow (as this paragraph), is returned by + this method and so dw::Textblock::mustBorderBeRegarded returns + *true*. This will put this paragraph again at the correct position. +- To avoid overlappings, the linebreaking width of this paragraph + (which is also used for positioning of floats) is the available + width, minus the maximal float width on either side. (This is an + approach similar to the one dw::Ruler will use soon). Most likely, + some new methods will have to be added to calculate this. +- For paragraphs like this, dw::Textblock::borderChanged must rewrap + all lines; *y* is irrelevant in this case. +- Since the textblock will tend to become taller when getting + narrower, and so possibly cover more (wider) floats, and so become + narrower again etc., there may be multible solutions for calculating + the size. Generally, a smaller height (and so larger width) is + preferred. +- There remains a problem: what if a word is too large? Should a + textblock of this kind then reard the floats in detail, to insert + empty lines when needed? + +**Real-world cases:** *Overflow:hidden* is set for headings in +Wikipedia, and so this case occurs when there is a float (thumb image) +before a heading. See e. g. +<a href="http://de.wikipedia.org/wiki/Emmerich_am_Rhein#Ans.C3.A4ssige_Unternehmen">this page</a> +and scroll a bit up; the company logos should be right of this section. + +**Priority:** Since this is not a regression, compared to not +supporting floats at all, a fix is not urgent for a new release. + */ |