Some notes.

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
 ---------------