RE: page-break-* and columns

 
Intercalated...

Melinda

> -----Original Message-----
> From: fantasai [mailto:fantasai@inkedblade.net] 
> Sent: Tuesday, April 07, 2009 4:23 PM
> To: Linss, Peter
> Cc: Grant, Melinda; www-archive@w3.org
> Subject: page-break-* and columns
> 
> Linss, Peter wrote:
> > fantasai likes to avoid breaking properties out so that fallback 
> > support works better on older browsers. Consider ...
> 
> My concern here isn't so much older implementations. It's 
> 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.
> 
> 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.
> 
> And then there are combinations that make no sense, like
>    page-break-before: always; column-break-before: avoid; or
>    page-break-before: avoid; column-break-before: always;

There are a number of combinations that don't make much sense, and we'd have to define those away if we want separate properties.  Your first eg above is one (I'd say that page-break-before: always takes precedence, just like it does over 'page-break-inside: avoid'), but the second eg isn't necessarily non-sensical.  It should mean, "I want this at the top of a column, but not the first column of the page."  So the implementation would pull the content of the preceding column to the next page to satisfy both constraints.

> If we don't care about that, and we lower the priority of 
> backwards compatibility, this could work:
> 
>    Introduce column-break-* as parallels to page-break-*.
>    Introduce break-* as shorthands that set both page-break-*
>    and column-break-* to the same values.
> 
> 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.

Sound like a win-win (flexibility and ease-of-use).  I think this is the best suggestion yet.

> But, there are disadvantages:
>    - no way to distinguish between weighting page breaks and
>      column breaks as equally bad vs. weighting page breaks
>      as worse (Alex's point)
!important?
>    - no way forward for a control to "avoid page turns, but
>      breaks between facing pages ok"
Add 'avoid-turn' to the page-breaking props?
>    - as mentioned, no meaningful resolution of contradictory
>      settings
Yep, we'd have to spec the conflicts.  The spreadsheet I did last week should point out the conflicts we'd need to address.

> ~fantasai
>

Received on Wednesday, 8 April 2009 03:54:51 UTC