I was hoping so far that wrapping around a shape should just be a property on a block that allows it to wrap (regular BFC vs. non-BFC is not enough because multicolumn will definitely want to wrap and they are BFC). It looks like it is more complicated...
From: Jacob Refstrup [mailto:jrefstrup@apple.com]
Sent: Friday, March 11, 2011 10:25 AM
Consider the following (complicated) example:
[cid:image001.png@01CBDFE0.27DE4EA0]
The light blue box contains three colored objects and some text; visually this is in front of the box with the latin text and cause wrap of that; in the purple object text wrap is affected by the red'ish object. The text of the yellow'ish object is affected by wrap of the purple and red'ish object. The green'ish object is in front of everything and affects the latin text but in this case doesn't affect the text inside the light blue container box. Furthermore the text "An example of controlling..." is not affect by wrap of other boxes/objects; this may not be immediately visible but imagine if the additional wrap margin there exists around the purple object and it's hopefully clearer.
The major use cases I've seen for wrap order/influence:
- floating boxes affecting wrap (e.g. the light blue box)
- positioned boxes that are in front (e.g. the triangle)
- child/descendent boxes inside an enclosing box influence wrap in visual order; boxes in front of enclosing box doesn't affect internal wrap; i.e. some way of containing which boxes influence wrap (e.g. the children of the light blue box).
- some of of disabling wrap influence for a box (e.g. the text "An example of controlling..." in the light blue box)
As Dave stated in [1] we thought using z-ordering and the stack context to scope wrap influence would be convenient and easier for the author. It may be that we need a separate wrap order/influence model that is different from the z-order of a stacking context.
