/** \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. Which widgets may be drawn? ------------------- All drawing starts with the toplevel widget (cf. dw::core::Widget::queueDrawArea, dw::core::Layout::queueDraw, and dw::core::Layout::expose), and a widget has to draw its children, in a way consistent with their stacking order. There are two exceptions: 1. Direct descendants, which are not children, may be drawn, if the parent can distinguish them and so omit drawing them a second time. See dw::core::StackingContextMgr and \ref dw-stacking-context. Parents should not draw children in flow for which dw::core::StackingContextMgr::handledByStackingContextMgr returns true. 2. Interrupted drawing: via dw::core::Widget::drawInterruption; see \ref dw-interrupted-drawing. Similar rules apply to handling mouse events (dw::core::Widget::getWidgetAtPoint). Interrupted drawing ------------------- → \ref dw-interrupted-drawing. Similar rules apply to handling mouse events (dw::core::Widget::getWidgetAtPoint). 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 =================== General ------- (See also *relative positions* below.) What about negative positions? dw::oof::OutOfFlowMgr::tellPosition1 and dw::oof::OutOfFlowMgr::tellPosition2 could be combined again, and called in the respective circumstance, depending on dw::oof::OutOfFlowMgr::mayAffectBordersAtAll. Relative positions ------------------ **General Overview:** At the original position, a space as large as the positioned element is left. This is implemented by assigning a size to the widget *reference*. For this there are two new methods: dw::oof::OutOfFlowMgr::calcWidgetRefSize and dw::oof::OOFAwareWidget::widgetRefSizeChanged. **Bug:** Since the size of a relatively positioned element should be calculated as if it was in flow, the available width should be delegated to the *generator*; however, since dw::oof::OOFPosRelMgr::dealingWithSizeOfChild returns *false* in all cases, it is delegated to the *container*. **Idea for fix:** dw::oof::OOFPosRelMgr::dealingWithSizeOfChild should return *false* if and only if the generator of the child is the container (to prevent an endless recursion). In other cases, dw::oof::OOFPosRelMgr::getAvailWidthOfChild and dw::oof::OOFPosRelMgr::getAvailHeightOfChild should directly call the respective methods of the *generator*, which must be made public then. **Performance:** In many cases, the first call of dw::oof::OOFPosRelMgr::sizeAllocateEnd will queue again the resize idle, since some elements are not considered in dw::oof::OOFPosRelMgr::getSize. One case could be removed: if a positioned element has *left* = *top* = 0, and its total size (the requisition) is equal to the space left at the original position, the size of the widget *reference* (dw::oof::OOFAwareWidget::getRequisitionWithoutOOF, see dw::oof::OOFPosRelMgr::calcWidgetRefSize). **Documentation:** Describe why the latter is not covered by dw::oof::OOFPositionedMgr::doChildrenExceedContainer. (Is this really the case?) **Open:** Stacking order? Furthermore: a relatively positioned element does not always constitute a containing block (see CSS specification). Fixed positions --------------- Currently, fixedly positioned elements are positioned relative to the canvas, not to the viewport. For a complete implementation, see \ref dw-fixed-positions. */