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

Also sprach Liam R E Quin:

 > >  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?
 > 
 > With the Modular Grid (the design methodology, not the CSS grid) it's
 > actually very common to snap particular kinds of content to particular
 > positions on the page, e.g. "the images go at the 1/3rd line and the
 > tables float to the bottom" seems not uncommon to me - you might see
 > this in the Financial Times although I haven't checked.

Yes, this is common. This can also be achieved with float as described
in GCPM:

  http://dev.w3.org/csswg/css3-gcpm/#the-float-offset-property

 > It's true that the most common rule is to move figures and tables to the
 > top or bottom of the current page if there's room for them in the "float
 > zone", rather like footnotes.

Right, that's the issue; is there a need to say "if this figure
doesn't fit on the current page, move it to the bottom of the next
page". If that's considered necessary, we can reintroduce the
'unless-room'/'unless-fit' construct.

(But we would also need to say how to achieve intra-page snapping.)

 > Within a magazine or newspaper, of course, one moves figures to the top
 > or bottom of the column.
 > 
 > >  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. 
 > 
 > The one-or-two line restriction is related to widow and orphan control,
 > and should be considered separately from floats. Yes, they're 100%
 > orthogonal (although yes they interact).

Are you saying the we should not consider this to be floating?
That the current widows/orphans properties should (be extended to)
describe this?

 > >  >   - 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
 > 
 > I think it's 100% in scope for CSS. It's something people want from Web
 > browsers when they pres Print - a table of contents, for example, with
 > page numbers, or a running header with the current section name in it.

I think people want it. And I've tried to spec TOC generation in CSS
in the past:

  http://www.w3.org/TR/2006/WD-css3-gcpm-20060612/#generated

But it's stretching the declarative model. JavaScript seems to offer
the required escape hatch for these cases. Or, how would you spec this
output in CSS:

  The figure is on this page.
  The figure is on the next page.
  The figure is on the previous page.
  The figure is on page 6.

>From this HTML code:

  The figure is <a href=#figure>here</a>.

 > Renumbering figures based on the order they appear in the output might
 > be too hard to do, although if you can generate the figure numbers
 > automatically then I don't really see the problem.
 > 
 > Coalescing figures is no harder than coalescing footnotes. Which doesn't
 > make it easy, admittedly, but you really don't have a good print
 > solution without footnotes, even if they are not so often used on the
 > screen. I think in the future we'll see more demand for footnotes on the
 > screen, though.

Yes, I think pages will dominate screen-based presentations in the future.

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

Received on Thursday, 16 August 2012 16:16:22 UTC