diff options
| -rw-r--r-- | doc/dw-miscellaneous.doc | 104 |
1 files changed, 93 insertions, 11 deletions
diff --git a/doc/dw-miscellaneous.doc b/doc/dw-miscellaneous.doc index 4f47b5a4..27508991 100644 --- a/doc/dw-miscellaneous.doc +++ b/doc/dw-miscellaneous.doc @@ -7,30 +7,112 @@ partly to be created). General ======= -A **widget allocation outside of the allocation of the parent** is +Widget allocation outside of parent allocation +---------------------------------------------- +A widget allocation outside of the allocation of the parent is allowed, but the part outside is not visible. -**Interrupted drawing:** \ref dw-interrupted-drawing. +Interrupted drawing +------------------- +\ref dw-interrupted-drawing. Floats ====== -**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", ...). +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. +- 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. Positioned elements =================== -**Positioned elements outside of the container:** ... +Positioned elements outside of the container +-------------------------------------------- +... -**Relative positions:** ... +Relative positions +------------------ +... -**Fixed positions:** ... +Fixed positions +--------------- +... */ |