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

Also sprach Peter Moulder:

 > > 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.

 > 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;

It was removed as I thought -- and still think -- that 'snap' is better because:

 1) it uses a simpler syntax (one keyword rather than two). In the WD,
    you could say:

      .figure { float: top unless-fit }

    while the ED lets you say:

      .figure { float: snap }

 2) it covers all realistic use cases than "unless-room" (or
    "unless-fit" as some prefer) supports, with less need for physical
    guidance; there is no need to specify "top" or "bottom". This also
    means that one cannot push elements to the bottom of the next
    pages, as one could before:

     .figure { float: bottom unless-fit }

    This is not possible with 'snap', but it doesn't seem common to
    push figures to that location, no? Unless one has a general policy
    of not showing figures/tables etc. on the top of pages. Real-world
    examples could convince me otherwise.

 3) it covers more use cases: the snapping of elements towards page
    breaks. The basic premise for listing this as a benefit is that if
    (say) a figure is somewhat flexible in its placement, one would
    want to (a) avoid large white space before page breaks (which is
    what 'unless-space' does), AND (b) avoid isolated one- or
    two-liners above or below figures/tables (which is added by
    'snap'). As such, 'snap' is a combo solution. 

    One should always be cautious of combo solutions. Perhaps some
    authors would like to do one and not the other? In this case,
    however, I can't think of anything reasonable. An author, I'd love
    to just state:

       table, .figure { float: snap }

    And be done with it.

 > 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.

Yes, I think this is one bridge too far for CSS. A JavaScript-based solution
for a somewhat similar problem is discussed here:

  http://printingcss.com/?p=73

 >   - 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.

This was discussed at the F2F in Hamburg. The solution the WG came up
with (proposed by fantasai) allows authors to specify the magnetic field of snap:

    table, .figure { float: snap(3em) }
  
    http://lists.w3.org/Archives/Public/www-style/2012May/0538.html

This is more flexible than using orphans/widows (as the draft has suggested
suggested). I still think it should be possible to just say:

    table, .figure { float: snap }

Or, perhaps:

    table, .figure { float: snap() }

and have a sensible -- perhaps implementation-specific -- value
applied, no?

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 16 August 2012 14:56:14 UTC