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

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

From: Peter Moulder <peter.moulder@monash.edu>
Date: Thu, 20 Oct 2011 17:47:28 +1100
To: www-style@w3.org
Message-id: <20111020064728.GA17286@bowman.infotech.monash.edu.au>
On Wed, Oct 19, 2011 at 11:23:22AM -0700, fantasai wrote:
> On 10/19/2011 07:09 AM, Anton Prowse wrote:
> >On 20/09/2011 04:31, Peter Moulder wrote:
> >>On Mon, Sep 19, 2011 at 03:55:17PM -0700, fantasai wrote:
> >>>
> >>>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.
> >
> >I agree with this. I wouldn't want floats to be calculated according to dimensions on one page and then look bad on the
> >continuing page; I imagine that the first impression of authors if they saw that would be that it were a UA bug.
> >
> >For me, this issue is even clearer in the case of regions rather than pages. I really don't think we want overlap or overflow.
> 
> The question then is, if I get a layout like this
> 
> +----------------------------------+
> |###########           ############|
> |###########           ############|
> |###left####           ####right###|
> |###float###           ####float###|
> |###########           ############|
> |###########           ############|
> |###########           ############|
> |###########           ############|
> +----------------------------------+
> 
> And on the second page:
> 
> +-----------------+
> |###########      |
> |###left####      |
> |###float###   A  |
> |###cont.###      |
> |###########      |
> |     ############|
> |     ###right####|
> |     ###float####|
> | B   ###cont.####|
> |     ############|
> |      ...        |

There seems to be some confusion as to what proposal is being discussed.

There are I think three approaches that have been discussed in this thread:

  (1) vertically-contiguous floats (i.e. continuations always start at
      the top of the next page), with float rules modified to overflow or
      truncate if necessary;

  (2) vertically-contiguous floats, with no modification to float rules
      (each float is placed as early as possible such that it fits *on
      all pages*), so no extra overflow.  This is the approach being
      discussed above, described as "preferable [over option 1] to
      authors, if we ignore implementation issues".

  (3) vertically-discontiguous floats (i.e. continuations can start lower
      down the page or even skip a page), with float rules modified such
      that only one page is considered at a time for whether the float
      fits.  (No other change to float rules, so no extra overflow.)
      This is the option that fantasai is depicting above, but
      is not mentioned in the quoted text.

(Under option 2, the second of the two floats wouldn't start on the first
page, given that it can't fit in one page, and has no solution in the
second page if it does start on the first page.)

> Does text after the float wrap into section A? I think that would make
> sense if you are using floats as floats (not as a substitution for e.g.
> flexbox). But it would require some clarification, I think.

I'm not sure I understand the question, but isn't it the same situation
as in the unpaged case, if we discard the first page?

pjrm.
Received on Thursday, 20 October 2011 06:47:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT