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

Also sprach Stephen Zilles:

 > 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.

(Actually, the spec only says something about page breaks, which means
-- at least in my interpretation -- that the top of the first page and
the bottom of the last page is excluded)

 > 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.

Right.

 > 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.

Right. Should we call them "natural" and "forced" page breaks?

 > (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.)

Yes. I'd be happy to always ignore margin-bottom at the bottom of
pages (even the last).

 > 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'".

Yes.

 > 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 *".

I think it's sound architechture -- by default you provide the
solution that works best in most cases, and then you allow other
behaviors to be specified.

 > 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.)

I wouldn't distinguish between properties. To me, it's the fact that a
page break is forced which triggers a certain behavior. Forced page
breaks can also occur from settings on the 'page' property.

When I write style sheet, it's fairly arbitrary if I use
page-break-before or page-break-after.

 > 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").

I disagree. I think we have a perfectly fine solution in behavior *,
you just have to write two declarations instead of one:

  table.alone {
    page: separate;
    margin: 0;
  }

If you add a new property, you still have to write two declarations.

 > 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'.

This, in effect, would make the margin-* properties shorthand properties. 
That would turn 'margin' into short-short-hand? :)

I don't support changing the margin properties -- we have
interoperability now, and adding new values will complicate things.

 > 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 *".

I agree to adding behavior * to CSS 2.1 now. 

Perhaps we could discuss the best solution for CSS3 on a white-board
in Tokyo?

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Wednesday, 21 January 2009 16:43:23 UTC