diff options
Diffstat (limited to 'devdoc/dw-miscellaneous.doc')
| -rw-r--r-- | devdoc/dw-miscellaneous.doc | 142 |
1 files changed, 0 insertions, 142 deletions
diff --git a/devdoc/dw-miscellaneous.doc b/devdoc/dw-miscellaneous.doc index d6b3cae3..cb4303c2 100644 --- a/devdoc/dw-miscellaneous.doc +++ b/devdoc/dw-miscellaneous.doc @@ -42,146 +42,4 @@ 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: - - <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. - -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. - */ |