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

TJ said:
> At the moment, all of the options that have been brought up 
> form a strict hierarchy.  If you allow page breaks, you 
> automatically allow facing-page breaks and column breaks.  If 
> you allow facing-page breaks (but avoid other page breaks), 
> you automatically allow column breaks.
> It doesn't make sense, frex, to avoid column breaks but allow 
> page breaks, as a page-break is automatically a column-break as well.
> 
> So, at the moment, we don't need to support multiple flags.  
> I have no idea if there's a useful break mode that doesn't 
> fit into this strict hierarchy.  Can you think of any?

Assuming something like the following for overloading page-breaking to handle column-breaking:
page-break-before
     auto | column | always | right | left | avoid | avoid-page | avoid-right | avoid-left

page-break-after
     auto | column | always | right | left | avoid | avoid-page | avoid-right | avoid-left

page-break-inside
     auto | avoid | avoid-page | avoid-right | avoid-left

(...avoid-right and avoid-left could be replaced by avoid-turn...)

There are some semantics that separate properties or values would enable that merging properties would not:
1. page-break-before: auto; column-break-before: avoid;
	==> Content should not occur at the top of any column except the first.
2. page-break-after: avoid; column-break-after: always;
	==> Content is always the last in a column, but should not occur in the last column of a page.
3. page-break-before: avoid; column-break-before: always;
	==> Content is always at the top of a column, but should not occur in the first column of a page.
4. page-break-after: avoid; column-break-after: always; page-break-before: avoid; column-break-before: always;
	==> Content should not be in either the first or last column of the page.

I don't personally find any of these particularly compelling, but maybe I'm missing something.

I feel that overloading the page-breaking properties results in such counter-intuitive naming that that in and of itself justifies looking for another solution.

I like the idea of separate properties with a unifying shorthand.  But at this point in time, it seems questionable that the extra implementation effort to enable cases like the ones called out above is really justified.  (Proponents???)

But Hakim's example of using a small matrix to clarify interactions would enable (at least temporary) simplification of the more complex semantics, and this seems the best way forward to me given the better usability of the proposed shorthand.

Best wishes,

Melinda

Received on Friday, 10 April 2009 03:19:59 UTC