/** \page dw-miscellaneous Miscellaneous Notes on Dw This is a barely sorted list of issues which I consider noteworthy, but have yet to be moved to other parts of the documentation (which is partly to be created). General ======= 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. 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", ...). Float containers in flow ------------------------ Consider the following HTML snippet:

Text

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. this page 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 -------------------------------------------- ... Relative positions ------------------ ... Fixed positions --------------- ... */