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

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

From: Håkon Wium Lie <howcome@opera.com>
Date: Fri, 24 Aug 2012 01:27:53 +0200
Message-ID: <20534.48249.377485.194617@gargle.gargle.HOWL>
To: liam@w3.org
Cc: Peter Moulder <peter.moulder@monash.edu>, www-style@w3.org, Michel Onoff <michel.onoff@web.de>
Also sprach Liam R E Quin:

 > On Thu, 2012-08-16 at 18:15 +0200, Håkon Wium Lie wrote:
 > >  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".

 > Yes, in the case that publication rules say all figures are to be
 > floated to the bottom of their page.

I think we can address this use case by adding another argument to snap(). E.g.:

  .figure { float: snap(3em, bottom) }

So, if the figure appears near the top or bottom (the field of
attraction is 3em), it will float to the bottom. Normally snap floats to the closest:

  .figure { float: snap(3em, near) }

 > >  > 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?
 > If you have a rule that you don't want a single line of text (say), but
 > only two or more, in your paragraph, then you probably don't want
 > floated figures to cause a paragraph break that leaves only one line of
 > text...

Right. 'widows' and 'orphans' can express this. But they can't say
what to do with figures. I think we need 'float' for that.

 > Cameron's suggestion might suffer from the exponential explosion of
 > rules also present in XSL-FO with page masters - you tend to need one
 > rule (or page master) for every combination of conditions... e.g.
 > suppose you generate "figure", "chart" or "table" depending on a class
 > value, so
 > See also table 1.6 (page 17, opposite)
 > See also figure 1.6 (page 18, overleaf)
 > See also chart 1.6 (page 16, previous page)
 > If you choose to put "page N" there only if the page is not the previous
 > or next one, now you have an extra axis to multiply your rules. Of
 > course, a preprocessor could help.

Yes, you'd get a few like these:

  .chart:target-layout(attr(href url), opposite) { content: "See also chart " target-counters(attr(href url), section, ".")  "(page " target-counter(attr(href url), page) ", opposite)" }

 > A declarative alternative might be a way to express alternatives based
 > on conditionals,
 > a.xref {
 >     content:
 >       /* chapter number, figure number, here, then... */,
 >       when(target.nextpage, "see next page")
 >       when(target.pagenumber = pagenumber, "(this page)")
 >      ;
 > }

Interesting idea. It's beginning to look like a programming language. Hmm.

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Thursday, 23 August 2012 23:28:36 UTC

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