W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: [css3-multicol] page-break-inside and columns

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 08 Apr 2009 11:50:42 -0700
Message-ID: <49DCF202.3080108@inkedblade.net>
To: Håkon Wium Lie <howcome@opera.com>
CC: www-style@w3.org
Melinda asked me to forward bits of our conversation on splitting
out the properties into page-break-* and column-break-*.

My main concern here is that /usually/, you want to set both
page-break-* and column-break-* to the same thing. And unless
this is the easier thing to do, very often it won't happen and
your settings get out-of-sync. And whether you would want them
different or the same, it's easy to set one and forget the other.

As a result, you might get a bunch of page-breaking rules cascade
in from one source and a bunch of column-breaking rules cascade in
from another, clashing into something that makes no sense.
An author excited about multicol sets column-break-* carefully,
but their page-breaking story is still a mess because we can't
leverage their interest in columns to get better printing. Etc.

If we weren't very concerned about backwards compat, you could
address the above concern by creating a shorthand:

   1. Introduce column-break-* as parallels to page-break-*.
   2. Introduce break-* as shorthands that set both page-break-*
      and column-break-*.

You get your split out controls for all combinations, and
it's easy to set both at the same time so authors are more
likely to keep them in sync.

But, there are disadvantages:

   - No way to distinguish between weighting page breaks and
     column breaks as equally bad vs. weighting page breaks
     as worse -- this is Alex's point in

   - No way forward for a control to "avoid page turns, but
     breaks between facing pages ok"
       [Melinda suggests page-break-*: avoid-turn]

   - No meaningful resolution of contradictory settings like
     page-break-before: always; column-break-before: avoid;

   - Overhead from lots of properties that don't need to
     cascade independently and should always be set together

Received on Wednesday, 8 April 2009 18:51:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:35 UTC