- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 12 Dec 2011 15:30:59 +0100
- To: www-style@w3.org
- CC: Peter Moulder <peter.moulder@monash.edu>, fantasai <fantasai.lists@inkedblade.net>
(Apologies for the late reply.) On 20/10/2011 08:47, Peter Moulder wrote: > 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.) My understanding matched Peter's. I thought we were expressing a preference between (1) and (2), with my preference being (2) in agreement with Peter. The depicted case (3) seems odd to me; I don't think I'd want my float to be vertically-discontiguous. >> 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? I would say so. Cheers, Anton Prowse http://dev.moonhenge.net
Received on Monday, 12 December 2011 14:34:09 UTC