diff options
| -rw-r--r-- | doc/dw-miscellaneous.doc | 62 |
1 files changed, 44 insertions, 18 deletions
diff --git a/doc/dw-miscellaneous.doc b/doc/dw-miscellaneous.doc index 5a5f7517..d2b10bdd 100644 --- a/doc/dw-miscellaneous.doc +++ b/doc/dw-miscellaneous.doc @@ -130,26 +130,52 @@ 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 ------------------ -- 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. +**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. + +**Open:** Stacking order? Furthermore: a relatively positioned element +does not always constitute a containing block (see CSS specification). Fixed positions --------------- |