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

Re: [css3-multicol] Column Model Underdefined

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 26 Feb 2009 11:41:10 -0800
Message-ID: <49A6F056.40300@inkedblade.net>
To: "Grant, Melinda" <melinda.grant@hp.com>
CC: Håkon Wium Lie <howcome@opera.com>, WWW Style <www-style@w3.org>
Grant, Melinda wrote:
> Håkon said:
>>  > I'd like to see Alex's point about page-break-* addressed
>> I agree that we should close this before LC'ing the draft.
>> I've added it as an issue. I'm ok with changing it -- it 
>> makes the draft simpler while retaining the same 
>> functionality. Are there any opposing votes?
> I haven't had a chance to think it through sufficiently, but caution signs are
> flashing in the back of my head.  
> Like, what if I want to avoid a page break within an element, but I don't care
> if it breaks across columns, because all the associated info would still be
> visible at once.  Presumably, as now, 'page-break-inside: avoid' would accomplish
> that use case.  
> Now what if I *don't* want the element to break across columns?  How would I
> indicate that?  Add a new value? 'page-break-inside: avoid-column'?  Or are you
> thinking we would just omit this control?
> Similar questions come to mind wrt page-break-before and -after.  The 'always',
> 'right', and 'left' values seem ok (they would continue to cause a page break)
> and adding 'column' to trigger the column break is fine, but 'avoid' again
> seems problematic.  It seems we would need to add column-avoid or some such to
> all the page-breaking properties to make overloading these properties workable,
> or else not provide the author with the ability to try to constrain content to
> a single column.

I think "page-break-inside: avoid" should avoid any kind of pagination break,
including column breaks. If we need a separate control for avoiding page breaks
but not column breaks, then we can add "page-break-inside: avoid-page-break".
If the author really wants the column and page pagination behavior to be different,
then he should have to really think about it and not get that behavior by accident.
That's another reason why I don't want these to be separate properties (aside from
the tangled-up cascade effect): if there are two properties, the author is likely
to forget to set either one or the other.

There is a similar argument with facing pages, btw. Do we need an "avoid-page-turn"
value for CSS4 Paged Media?

> I'm with Håkon, the clumsy naming is really ugly.  Does CSS have any history of
> adding synonyms as properties?  Introduce 'break-before', etc. as synonyms for
> page-break-before, etc.?

No. We can't do that.

Received on Thursday, 26 February 2009 19:41:58 UTC

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