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

On Thu, 2012-08-16 at 16:55 +0200, Håkon Wium Lie wrote:

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

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.

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

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

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.

Best,

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Co-author, 5th edition of "Beginning XML", Wrox, 2012

Received on Thursday, 16 August 2012 15:54:58 UTC