1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
/** \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:
<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.
*/
|
