W3C home > Mailing lists > Public > www-style@w3.org > September 2011

Re: [css3-page] float Rules for Pagination into Varying-Width Pages

From: Peter Moulder <peter.moulder@monash.edu>
Date: Tue, 20 Sep 2011 12:31:49 +1000
To: www-style@w3.org
Message-id: <20110920023149.GA21788@bowman.infotech.monash.edu.au>
On Mon, Sep 19, 2011 at 03:55:17PM -0700, fantasai wrote:
> On 09/19/2011 01:33 PM, Peter Moulder wrote:
> >On Mon, Sep 19, 2011 at 10:14:35AM -0700, fantasai wrote:

> >>   * Continuations of boxes on a previous page must start at the top
> >>     of the page.  If this results in multiple shrinkwrapped floats
> >>     side-by-side that would otherwise be staggered (if they were not
> >>     continuations), [then shrink proportionally or overflow].
> >
> >Sorry, I don't understand this condition [...]
> Normally, if there are two floats side by side and they don't both fit,
> the second one will move down until it clears the first. You never get
> an overflow condition because of side-by-side floats.
> However, if we require that a float that was split across pages begin at
> the top of the page (which I think we should), then that escape hatch is
> not available on subsequent pages. This could result in either overflow
> or overlap between floats, which is not normally possible.

I'll note that this proposed change of rules for float widths isn't technically
necessary: without it, the rules of section 9.5.1 of CSS 2.1 would just mean
that the second float would be pushed down as far as necessary for it to fit on
all pages on which it occurs.

Ignoring implementation issues, this would actually be preferable for authors:
no-one wants a float to overflow off the edge of a page on a subsequent page.

The argument in favour of the proposed rule change would be speed of
implementation (both in the sense of development time and runtime), combined
with a hope that authors will do what they can to make it unlikely that the
changed rule comes into operation for their document.  (Though it isn't
entirely within author control if rendering isn't under author control.)

If the main considerations are implementation issues, then we could let each
implementor make this call for themselves, i.e. mark the rule change as
explicitly at the option of the user agent.  A counter-argument is consistency
and thus making it more likely that an author would become aware of the
problem, though for a couple of reasons I think that that's less of an issue
here than it usually is.  This question isn't worth spending too much time on,
though: I don't know whether anyone would implement the better approach, and if
someone did then maybe they would anyway regardless of the exact wording the
spec chose.

> Does it make sense?

I think the suggested wording isn't right, because I think the "if it
would result in side-by-side" condition never applies according to 9.5.1
rules.  So if I've understood the intended behaviour, then the approach 
I'd take would be to say that certain of the 9.5.1 rules (the "must fit"
ones) don't apply to the continuations of floats, and to say that the
width rules for floats are changed for continuations of floats (namely to
shrink proportionally as necessary to make them fit as well as possible,
subject to being at least the minimum width).

Speaking of which, an alternative to making the shrinking be strictly
proportional to the total width, it could be in proportion to width
minus min-width, which would be more like how table columns are sized,
and is a bit easier to implement.

Received on Tuesday, 20 September 2011 02:32:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:04 UTC