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

On Mon, Aug 06, 2012 at 06:20:55PM +0200, Michel Onoff wrote:
> You're writing a paper on computer science. For illustrative purposes,
> you include short code snippets.
> 
> Since they are short and since you don't want the reader to be
> distracted by back and forth page flipping, you disallow page breaks
> inside the snippets. On the other hand, you don't want to waste precious
> space either, so you have no troubles if the snippets are taken out of
> the normal flow and positioned on the top of the next page.
> 
> You only care that your snippets' listings are visually rendered as a
> whole, preferably inside the normal flow if there's sufficient room, or
> out of flow, on the next page, otherwise. Of course, you are prepared
> for forced breaks if the snippets are longer than a page.
> 
> There are CSS working drafts about:
> 
> * "CSS Paged Media Module Level 3" (http://dev.w3.org/csswg/css3-page/)
> * "CSS Generated Content for Paged Media Module"
> (http://dev.w3.org/csswg/css3-gcpm/)
> 
> There are new float properties and controls for page breaks but they do
> not seem to solve the problem above, not even when combined.
> 
> Are there plans to add "conditional" floats to the mentioned specifications?

As already noted, the 2011-11-29 Working Draft has an 'unless-room'
modifier that has essentially the behaviour you're looking for:

 http://www.w3.org/TR/2011/WD-css3-gcpm-20111129/ text:

   unless-room
     Only float the box if it otherwise would have lead to a column or page
     break.

 http://www.w3.org/TR/2010/ED-css3-gcpm-20101101 text:

   unless-room
     If the element can be laid out in its natural position without causing a
     page break, it should be laid out there disregarding the ‘float’ property;
     in other cases the other values on ‘float’ will determine its floating
     behavior.

I don't know why it isn't in the current Editor's Draft text; though some
issues I can think of would be:

  - Corresponding content changes, both to the maybe-float (if floated then add
    a caption and maybe add a border) and to the body text (e.g. simple ":" vs.
    "as shown in <a href="...">Figure 5</a>.").  If there's more than one
    maybe-float in the document, then these substitutions might interact, e.g.
    body text referring to "Figures 5 and 6", or maybe even allowing related
    maybe-floats #foo and #bar to go to a single float with shared caption.

    That's starting to sound like an open-ended problem.

  - There are various issues as to the exact rule as to whether a given
    maybe-float should be floated or not.  However, we always have the option
    of leaving it completely up to user agents to decide whether to float or
    leave in-flow, and I suspect that many UAs would happen to implement the
    same thing, just as many UAs implement the same line-breaking and
    page-breaking decision rules without any deliberate coordination.

pjrm.



[The reasons why "natural position without causing a page break" isn't
 well-defined, and why it isn't easy to give a good and well-defined rule,
 are as follows.

 The "causing a page break" or "lead to a column or page break" text
 doesn't say where the page break is caused.  You'd want to specify the
 interaction with page-break-*:avoid, including giving attention to the
 case where the 'avoid' constraint isn't feasible regardless.

 More generally, what if making it inline results in an awkward break
 somewhere other than immediately before the maybe-float?  How should
 unless-room maybe-floats interact with each other, i.e. what if placing
 something in-flow doesn't require a page break near that maybe-float but
 does mean that three other maybe-floats need to be floated?

 On the other hand, what if making it in-flow causes a non-awkward break?

 I don't think that "cause" can be part of the condition to put in the spec,
 because that probably depends not just on whether there's a page break in
 the chosen layout, but also on whether there "would" be a page break in
 some other layout with the alternative in-flow-or-float decision, and that
 leaves the question of which layout(s).

 My own answer to these questions would be that 'unless-room' merely
 indicates a preference that user agents can do with as they wish; and that
 the test suite would at most have "should"-level tests for the feature.
 UAs that care enough about layout to do non-first-fit line-breaking and
 page-breaking would similarly treat the float-or-not question as part of
 the pagination optimization problem.]

Received on Wednesday, 15 August 2012 12:42:50 UTC