Re: floats vs. page breaks

"Peter Sorotokin" <psorotok@adobe.com> writes:

> I have faced the same problem and in my CSS implementation if a
> float overflows, it takes all the content that follows it with
> it. Doing it this way solves this problem, but it makes
> illustrations cause undesirable overflow of the text.

Unfortunately, it doesn't solve the problem in general because CSS is
an open standard and other people are allowed to implement it also.
:-)

So the behavior can vary where the standard allows freedom.  And it
seems the behavior I'm seeing is a very legitimate (and probably
usually desirable) choice.

> I think that there should be a property that specifies if a piece of
> content should be "postponed" until it can fit on the page entirely,
> even though the content that follows it can still take up the rest of
> the page. This is useful for things like tables and illustrations in
> general - no matter if they are floats or just regular blocks. The
> property could take three values - if this postponing should be allowed,
> disallowed or up to the user agent (as it is implemented today).
>
> Without such property, I do not think there is a way to do that.

The control you are asking for is (in theory, if not in actual
implementations so far) already present for normally flowed content in
the form of the "page-break-inside: avoid" property setting.  I don't
think it will be useful in this case because floats are allowed to
escape.

I think the real problem is that the only way to get text wrapped
around a shape is to use floats.  Floats however have that name
because they are supposed to _float_, i.e., to move as needed until a
good space is found to put them.  What is needed here is the
text-wrapping feature _without_ the floating feature.

-- 
Joe

> Peter
>
> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Joe Wells
> Sent: Tuesday, October 10, 2006 9:44 PM
> To: www-style@w3.org
> Subject: floats vs. page breaks
>
>
> Usually, one wants to position a float so that its top is as high as
> the top of the lowest-positioned box from earlier elements of the
> document.  When using paged media, doing so may cause the bottom of
> the float to extend below the bottom of the page.  It seems valid (and
> indeed proper) in this case for an implementation to decide to
> postpone a float to the next page.  For example, Konqueror does this.
> The relevant rule in CSS 2.1 (essentially the same rule is in CSS Box
> Model Level 3) is "A floating box must be placed as high as
> possible.".  It seems reasonable to decide that it is not "possible"
> to position a float in a place where it would be cut in half by a page
> break.
>
> When this happens, there seems to be no way (in CSS 2.1 or CSS Box
> Model Level 3) to ensure that any inline material from after the float
> in the document gets moved down with the float.  This has horrible
> implications for the way of implementing drop caps that is recommended
> in <URL:http://www.w3.org/TR/CSS21/selector.html#first-letter>,
> because it means that the drop cap can be moved after the paragraph it
> is supposed to begin!
>
> Comments?
>
> Is there a solution?
>
> Personally, I am not doing drop caps but rather something that should
> be typeset like drop caps.  I have some paragraphs that should begin
> with an image (several lines tall) which the paragraph text should be
> wrapped around.  Using left floats for this works fine for online web
> viewing, but gets messed up when printing due to the page breaks
> causing some of the floats to drop down to the next page.
>
> -- 
> Joe Wells

Received on Wednesday, 11 October 2006 19:25:46 UTC