W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[css3-gcpm] Re: conditional floats on paged media

From: Peter Moulder <peter.moulder@monash.edu>
Date: Wed, 15 Aug 2012 23:36:58 +1000
To: www-style@w3.org
Message-id: <20120815133658.GB14979@bowman.infotech.monash.edu.au>
On Thu, Aug 09, 2012 at 12:45:17AM +0200, Håkon Wium Lie wrote:

> The proposed "snap" keyword is close to what you are asking for:
>   http://dev.w3.org/csswg/css3-gcpm/#page-and-column-floats

> [...] If there is room, it will stay in its natual position

The current spec text doesn't actually say this, which might be why Michael
didn't see it as a solution.  (The current text doesn't say anything about
what happens if the box isn't "naturally" near either top or bottom.)

Also, I think the "naturally near" construct here is subject to many of
the same issues noted elsewhere in this thread for the "cause/lead to a
page break" rule for 'unless-room'.  I'm guessing that the intent is along
the lines "where the box would be if it were in-flow.  (Whereas for many
other uses of the word "natural" in the css3-gcpm text, I'd guess it means
the position of the placeholder.)  That interpretation makes sense when
intuitively thinking about pagination with a first-fit approach, but if
CSS leaves page-breaking decisions to the user agent (CSS 2.1 §13.3.5, or
the corresponding css3-page section §9.6, which both recommend against
using first-fit pagination) then "naturally near the top" isn't so well
defined (or isn't a useful criterion).

I suggest expressing in terms of requirements on the layout chosen without
reference to an alternative layout not chosen, and additionally conveying
the general goals that implementations should try to achieve (while
recognizing that these goals will conflict with other layout goals,
including the goals of other maybe-floats).  As with 'unless-room', I
expect that in practice many implementations will converge on the same
decision rule without deliberate coordination.

Received on Wednesday, 15 August 2012 13:37:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:02 UTC