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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 8 Apr 2009 19:37:42 -0500
Message-ID: <dd0fbad0904081737jcc6ac43xe951fae77b57a2b1@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, Apr 8, 2009 at 7:03 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>>At this point I support the logic behind doing this solely through
>>values, rather than properties.  My only opposition is doing it within
>>the page-break-* properties, but that may be unavoidable at this point
>>due to backwards compat.  I'd prefer a simple break-* set of
>>properties which accepted these values.
>>I would prefer we unify whether we phrase the values as allow-* or
>>avoid-*.  This would that, for page-break-inside, we'd either have
>>"auto | avoid-page | avoid-turn | avoid-column" (in ascending order of
>>strictness) or "auto | allow-column | allow-facing | allow-none".  I
>>prefer the former, as phrasing it in terms of avoiding page breaks
>>seems more natural.
> Yes to the naming consistency. But wouldn't the author still want to combine some of these 'flags' together e.g.
> page-break-inside: avoid-column, avoid-page;
> Such multivalue expressions would of course not be backward compatible but the other options currently on the table are not either afaik.

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?

Received on Thursday, 9 April 2009 00:38:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:25 UTC