RE: [css3-page][css3-multicol] margins at page or column breaks

Steve, I first have to say I admire your approach to every issue, where you bring together all points of view
(and no bias) to get to the best decision.

With this issue, I tend to agree that CSS3 adds enough complexity to make it desirable to control margin behavior on breaks, especially in columns (where @page rules don't apply, at least now). A property to control what happens to a margin after a page break makes perfect sense. I would call it

        margin-before-at-break: discard | retain

(which is a preference to adding keywords to margin-*)

For CSS2.1, don't we have enough functionality already to make it happen? Wouldn't this work for sections?

        .section { margin-top:1in; }

        @media print
        {
                .section { page-break-before:always; padding-top:1in; }
        }

I realize that this wouldn't perfectly handle the case when page break is not forced, but it does handle the major use case, doesn't it?

The proposal here is making CSS2.1 less specific -- not sure that would achieve anything... If there is an implementation that picks up this new functionality, that implementation will most certainly implement elements of CSS3 wouldn't it? Even pretending I'm unbiased, I can't think of a case otherwise :)

Alex

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Stephen Zilles
Sent: Monday, January 19, 2009 9:07 PM
To: MURAKAMI Shinyu; Hakon Wium Lie
Cc: www-style@w3.org
Subject: RE: [css3-page][css3-multicol] margins at page or column breaks


Since I expressed some concern about the direction being proposed for CSS2.1 with respect to margins at the top (and bottom) of pages and columns, I would like to summarize the discussion as it has occurred on this list and during the CSS WG meeting.

The current state of affairs
============================
The CSS2.1 specification says that margins at the top (or bottom) of a page are set to zero; that is, they have not affect.

13.3.3 Allowed page breaks
In the normal flow, page breaks can occur at the following places:
1. In the vertical margin between block boxes. When a page break occurs here, the used values [p. 92] of the relevant 'margin-top' and 'margin-bottom' properties are set to '0'.

The justification for this rule, stated by Håkon in his first post, is that margins are to keep blocks separated, but if the "adjacent" blocks in the normal flow are on two separate pages, then there is no need for margins to separate the blocks.

Moving toward a revision of CSS 2.1
===================================
The discussion in this thread has been about whether this is the correct choice, for CSS 2.1 and for CSS 3.

The consensus seems to be forming around the principle that this is not the right choice for CSS 2.1 and that something (to be discussed below) should be done for CSS 3. (There is a separate discussion about whether a solution for pages should apply to columns; again more below.)

The something to be done for CSS 2.1, let's call it "behavior *", is to distinguish page breaks caused by user action (the first page or page-breaks triggered by page-break-before) from page-breaks caused by normal formatting. If the page-break is caused  by normal formatting, then 13.3.3, item 1. Applies and the relevant 'margin-top' and 'margin-bottom' properties are set to '0'. If the page-break is caused by user (stylesheet) action, then 13.3.3., item 1. Does not apply and the 'margin-top' property is honored.

(There does not seem to be a similar case for the 'margin-bottom' property; even if the page-break is caused by user action, there are (currently) no use cases identified to justify special handling in this case.)

Proposed Change to CSS 2.1:
===========================
It is viewed as being too late to have "behavior *" become the required behavior for CSS 2.1. So, the proposal for CSS 2.1 is to say that either 13.3.3, item 1 or "behavior *" is acceptable in a conformant implementation of CSS 2.1.

The reason for this change is that often (but not always) the insertion of a page-break by user action signals the start of a new section. It seems clear that authors will want their 'margin-tip' honored at the start of a new section.

Note, however, that there are other reasons for using 'page-break-before' other than starting a new section. Consider the case of a table that will just fit on a page. In this case, the author may use 'page-break-before' to place the table on new page. Since this is not a new section, but just a continuation with a large object, the author would not expect the margin that his/her stylesheet assigned to tables in the normal flow to be honored. If "behavior *" is adopted, then it would be. But, it has been noted that the stylesheet author can, in this case, specify both that there should be a 'page-break-before' and 'margin-top: 0'.  Without "behavior *" it is not possible, using 13.3.3., item 1, to apply a property that says "honor the 'margin-top'".

Even with the analysis of the previous paragraph, it seems to me (and this was my original objection to "behavior *") that having a special case handling for the first page and pages caused by 'page-break-before' is bad system architecture. I still think that it is bad system architecture because only one of the reasons for using 'page-break-before' (to start a new section) needs "behavior *". It is, however, too late to come up with a good solution for CSS 2.1 so we may have to accept "behavior *".

Note that 'page-break-after' was (intentionally) left out of the specification of "behavior *". This is because this property is applied to the block that proceeds the block which may or may not want its margin honored. For that reason, it does not make sense to change the behavior of 'page-break-after' because adding this property to a block does not give the stylesheet designer a chance to change the margin properties on the following block. (And, no use case for preserving the margin on new page has been identified for this case. Note that although a new page always starts at the top of the page, only the UA formatting the last page knows how much space is available on that page so the 'margin-bottom' may or may not fit on that page and the author cannot really tell which will be the case.)

Proposed Changes to CSS 3:
==========================
Several people have suggested (both on this thread and in the CSS WG discussion) that there needs to be a new property (or modifications to an existing property) to correctly identify the authors intent with respect to honoring the "margin-top" (and 'margin-bottom') of blocks at the beginning (or end) of a page. The reason for considering a new property (or modification of an old one) is that there is no uniform rule that seems to work for the two use cases cited above ("beginning a section" and "putting a table on a new page").

The key thing to note in designing such a property is that it is intended to control the interaction between content (a normal flow) that is being flowed into a sequence of containers (pages in the discussion above). The relationship between the content and the containers is only partially determined by the author (using explicit page-breaks); the remaining page-breaks are determined by the UA (formatter). Thus, any new property must be designed to control this relationship. Murakami-san, in the message below, proposes two new enumerated values to be added to the 'margin' values in addition to the length value for the 'margin'. I will not repeat his discussion because I think it is clear. I think that this is a good way to indicate, for any particular margin value, whether it is to be (necessarily) honored at a page-break or it may (conditionaly) be set to zero at a page-break.

If Murakami-san's proposal is adopted, and it is agreed that "behavior *" is desirable, then a third value, 'auto' is needed to perpetuate "behavior *"; that is, 'auto' is equivalent to 'discard' except on the first page or any page caused by a 'page-break-before'.

Multi-columns
=============

The whole discussion above is in terms of pages (because that is all that is in CSS 2.1). But, CSS 3 has multiple columns. Having noted that, it seems clear that columns are as much a container that should trigger the special behavior (of margin suppression or honoring) in the same way that pages are handled. If a UA does not implement columns, then the column containment will be ignored and the user should expect that he get the same behavior (as he would have expected for columns) on the pages that are created. Clearly if not columns or pages are created (the typical browser case) than all of this discussion is moot.

So, I support both adding "behavior *" as an option to CSS 2.1 and using Murakami-san's suggestion below with the addition of an "auto" value to reflect the addition of "behavior *".

Steve Zilles
Adobe Systems Incorporated.

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of MURAKAMI Shinyu
> Sent: Sunday, January 11, 2009 12:31 AM
> To: Hakon Wium Lie
> Cc: www-style@w3.org
> Subject: Re: [css3-page][css3-multicol] margins at page or column breaks
>
>
> MURAKAMI Shinyu <murakami@antenna.co.jp> wrote on 2009/01/10 2:17:38
> >
> > Håkon Wium Lie <howcome@opera.com> wrote on 2009/01/09 23:09:50
> > >
> > > Also sprach MURAKAMI Shinyu:
> > >
> > >  > I think we need new properties such as the following:
> > >  >
> > >  > Name: margin-before-conditionality, margin-after-conditionality
> > >  > Value: discard-at-break | discard | retain
> > >  > Initial: discard-at-break
> > >  > Inherited: no
> > >  > Applies to: block-level elements
> > >  >
> > >  > The 'margin-before-conditionality' affects the leading margin
> > >  > (margin-top if block-progression is top-to-bottom) and the
> > >  > 'margin-after-conditionality' affects the trailing margin
> > >  > (margin-bottom if block-progression is top-to-bottom).
> > >> > > This looks complex, and I don't really like inter-dependent
> properties.
> ...
> > I think still 'margin-before-conditionality: retain' (or something
> > better) is needed here.
>
>
> What if the margin-* properties themselves have optional keywords?
> This will avoid inter-dependent problem.
>
> Name: margin-top, margin-right, margin-bottom, margin-left
> Value: <margin-width> [discard | retain]?
>
>
> --
> Shinyu Murakami
> http://www.antennahouse.com
> Antenna House Formatter
> http://www.antenna.co.jp/AHF/en/
>

Received on Tuesday, 20 January 2009 06:10:22 UTC