Re: [css3-multicol] improving the behaviour of floats

FWIW, I agree that in most cases floats should indeed be able to, well, float,
i.e. that the position is not "dogmatic", and that this is especially important
when other floats are nearby that need to be avoided (as with 'clear') or when
pagination or columns are involved, and especially if floats can span columns.

There are however (as Christian suggests) a small number of exceptions where
the 'float' property is currently used where it is important to start at
exactly at the specified line, even if that means moving the current line to
the next column or page.  One such case is that the 'float' property is
sometimes used for decorative drop-caps (perhaps using a replaced element for
the capital).  Another case is where the text refers to the position of the
float ("the image on the left").  This supports Christian's suggestion of
allowing designers to specify whether or not the floated box may move to a
different column or page, and to specify whether text should move with the
float.


Regarding the specification of how floats should span columns, one issue to
consider is that designers don't in general know the ratio of the float content
width to the column width[*1]; in which case the designer isn't in a position
to say how many columns the content should span, or to know whether or not the
float fits in one column leaving enough space for text to flow down one side,
or whether it should occupy a whole number of columns with no text flowing down
either side.

[*1] For example because users can change font size, and either the column
  width or the float's width may depend on the font size (column-width
  specified in ems or float width depending on the float's text's width).
  Column width might also depend on window/viewport width: one might want an
  integer number of columns in the viewport.

Thus there is value in allowing designers to specify merely that the float is
allowed to span columns, and thus allow the actual number of columns spanned to
be influenced by the widths involved.  There are however some cases where there is
more than one reasonable solution, and where the designer may want to influence
which choice is taken rather than leaving it for the CSS spec or individual
user agents to try to codify aesthetics.  If we want to avoid needing designers
to specify general conditionals, then some relevant measures that a designer
might constrain are: the aspect ratio of the intersection of a float and a
column block; the aspect ratio of the float itself; and the width in ems in
which text is to flow [presumably limited to the font size of the context where
the float appears in the source document even if this differs from the font
size of some of the text that's actually flowing down the float].

Christian and css3-gcpm also mention that floating to top or bottom of the page
or column is valuable when paginating or using columns.  I note that this is
particularly valuable when a float (including any spacing on its sides)
occupies all of the width of any column (to avoid dividing the rest of the
column's text into two).  So floating to top or bottom would be another thing
to consider along with the question of how many columns to span and whether
text should flow down the sides of the float.



One issue we have found in our own experimentation when the user agent chooses
whether to span more than one column (or even if the user agent just chooses
whether to float to left or right of a single column) is that designers often
specify different margin or padding on the left versus right of the float, but
doing so is only appropriate if the designer actually knows which side or sides
of the float will have text.  E.g. in pre-existing web-pages that have
float:left, one typically specifies that the left side has zero
margin/padding/border while the right side has non-zero spacing from the
neighbouring text.

A trick I've used in my own software when applying columns to pre-existing HTML
documents (not designed for columns) is to reinterpret padding-left (and
margin-left etc.) as padding-on-any-side(s)-without-flowed-text etc. and
similarly padding-right as padding-for-any-side(s)-with-flowed-text (or vice
versa for float:right).  I'm not proposing such an interpretation be written
into CSS, I'm just reporting that such an interpretation does seem to work
(in the relatively small number of sites I've looked at), i.e. that presence of
text flowing down a side seems to be the most important thing for deciding
spacing.  Maybe in CSS this might translate into properties like padding-inside,
or maybe there's some notion of margins that can collapse with the column/page
margin, I don't know.

pjrm.

Received on Monday, 18 May 2009 05:29:18 UTC