- From: Håkon Wium Lie <howcome@opera.com>
- Date: Mon, 15 Apr 2013 18:58:45 +0200
- To: Anton Prowse <prowse@moonhenge.net>
- Cc: "www-style\@w3.org" <www-style@w3.org>
Anton Prowse wrote, on 11 Jan 2012:
> [Issue 4:]
>
> >> I think "block containers" is the tidiest option, and the one most
> >> likely to be correct when other specs introduce new box types that are
> >> apt for being multicol boxes.
> >
> > The editor's draft has now replaced:
> >
> > "Column boxes act as the containing block for their content."
> >
> > with:
> >
> > "Column boxes are block container boxes."
> >
> > This is what you suggested, right?
>
> Yes, that's great.
>
> > Also, the subsequent text has been
> > changed to match the new wording:
> >
> > Column boxes are block container boxes. That
> > is, column boxes behave like block-level, table cell, and inline-block
> > boxes as per CSS 2.1, section 10.1, item 2 [[!CSS21]]. However, column
> > boxes do not establish block container boxes for elements with ''position:
> > fixed'' or ''position: absolute''.
> >
> > Is this correct?
>
> I feel strongly that the second sentence should be omitted. (But by all
> means put a link back to CSS21 9.2.1 to remind people what a block
> container box.) I don't know why I didn't pick up on it the first time
> around. I don't even know what it's trying to say exactly, but I'm
> pretty sure it's trying to summarize behaviour that's defined in CSS21.
I think it's trying to anchor column boxes to somthing that
implementors presumably know (CSS21). Do you still feel strongly about
this? I think the first sentence says it all and the the second can be
removed, but implementors may think otherwise.
> This is a dangerous thing to do and our fingers already have been
> burnt many times due to making unfaithful summaries in normative text
> (most notably between different sections of the CSS21 spec!).
>
> Ditto with the third sentence. (I'm presuming that you do want CSS21
> behaviour, so if it does become possible to position a column box in
> future then a positioned column box will in fact establish the
> containing block for its absolutely positioned children.)
>
> Deleting these sentences would mean that the notion of containing block
> isn't even mentioned in the spec. Far from that being a problem, it's
> exactly what's required. Leave it to CSS21 and CSS3-box to describe
> what containing blocks are all about.
I also think the third sentence can be removed, yes.
Any objections?
> >>>> Issue 7:
> >>>>
> >>>> 3.5 (Stacking context) says:
> >>>>
> >>>> # All column boxes in a multi-column element are in the same stacking
> >>>> context and the
> >>>> # drawing order of their contents is as specified in CSS 2.1.
> >>>>
> >>>> This isn't quite good enough since the outward behaviour of a column box
> >>>> isn't explicitly defined (albeit that the description in Section 2 is
> >>>> intended to be a sufficient summary of their behaviour). The painting
> >>>> model specified in CSS 2.1 only describes the behaviour of box types
> >>>> known to CSS 2.1; new box types need to "fitted in" to the painting
> >>>> model explicitly. Happily CSS 2.1 makes this as easy as possible for
> >>>> typical new box types: they merely need to be defined as
> >>>> "non-inline-level" (see CSS 2.1, 9.1.1, painting layer 3). This
> >>>> information /does/ need to be provided in specs that define new boxes,
> >>>> though, even though it might be "obvious".
> >>>
> >>> So, what's your proposed change?
> >>
> >> The third paragraph of Section 2 begins:
> >>
> >> # Column boxes in a multi-column element are arranged into rows.
> >>
> >> I would prepend the following sentence:
> >>
> >> | A column box is a non inline-level block container box.
> >>
> >> An alternative is to state in 3.5 that column boxes are painted on the
> >> layer for "in-flow non inline-level non-positioned boxes" [CSS21,
> >> 9.2.1]; but of course that's only true if the column box is indeed
> >> in-flow and non-positioned, something which is necessarily true right
> >> now but who knows in future. Hence this alternative is more error-prone.
> >
> > Hm. Wouldn't it be better to describe this in the "Stacking context"
> > section?
>
> If we were going to adopt the latter solution, then yes. But to be
> honest, I much prefer the former solution.
Which is this sentence: "A column box is a non inline-level block
container box." Hard to parse. Any other suggestions on how to resolve
this?
> > And, while it's true that we may want to make columns more
> > powerful in the future, shouldn't we try to keep this specification as
> > simple as possible while remaining interally consistent?
>
> I think it very much depends on the context. In the context of the
> fundamental building blocks of CSS (box model, formatting model,
> painting model) I think all CSS3 specs should use the foundations
> provided by CSS21. I know that a thin layer of abstraction was added to
> CSS21 very late in its life cycle, so we're still quite unfamiliar with
> the terms "block container box", "painting layer" etc. But that will
> change as more and more Level 3 specs progress. The advantage of using
> this foundation is obvious: we'll get stuff for free when CSS evolves
> further, and it costs very little, if anything, right now. On the other
> hand, the hassle it would cause future spec editors if we /didn't/ do
> this would be substantial since they would have to do a lot of retrofitting.
>
> It's an unfamiliar approach, and up until now it's only really been you
> who has had to deal with this. But that's because your spec has the
> fortune to be the first formatting model spec to reach CR! Many others
> will follow, and they will all have to go through the same process of
> considering whether things are block containers, BFCs, stacking
> contexts, containing blocks, regions, ...).
>
> >>>> Also, it seems to be the intention that column boxes do not necessarily
> >>>> establish new stacking contexts; this needs to be stated explicitly.
> >>
> >> Is this the intention? (It seems reasonable.)
> >
> > Any objection from implementors? I've added this to the editor's draft:
> >
> > Column boxes do not establish new stacking contexts.
> >
> > If we later decide to make columns more powerful (e.g., by positioning
> > them) this is not necessarily true anymore. But I think we can worry
> > about that later.
>
> This is an example of a problem that many specs will run into. What we
> want to say is that these boxes don't necessarily establish new stacking
> contexts, where "necessarily" means that other properties applied to the
> box might cause it to establish a stacking context but the status of
> being a column box doesn't cause that in and of itself.
>
> Hmm. Perhaps the easiest way to solve that is *not* to say anything
> about establishing new stacking contexts.
>
> Or perhaps:
>
> | Column boxes do not inherently establish new stacking contexts.
>
> This looks a bit weird right now, but quite possibly it will seem more
> natural if various other specs use exactly the same terminology.
How about:
Column boxes, as described in this specification, do not establish new stacking contexts.
> [Issue 8:]
>
> >> Another small nit: The sentence that precedes (a) is
> >>
> >> # If a column rule is wider than its gap, the column rule will
> >> # overlap adjacent column boxes, and possibly extend outside the box
> >> # of the multicol element.
> >>
> >> I'm not sure that "overlap" is a good choice of word given that the
> >> column rules lie under the column boxes as currently specified. Perhaps
> >> we could turn that clause around:
> >>
> >> | If a column rule is wider than its gap, the adjacent column boxes
> >> | will overlap the rule, and the rule may possibly extend outside the
> >> | box of the multicol element.
> >
> > Good, inserted.
>
> Great.
>
>
> >>>> Issue 9:
> [...]
> > Added.
> >
> >>>> Issue 10:
> [...]
> > Done.
> >
> >>>> Issue 11:
> [...]
> > Done.
> >
> >>>> Issue 12:
> [...]
> > Done.
> >
> >>>> Issue 13:
> [...]
> > Fixed.
> >
> >>>> Issue 14:
> [...]
> > Added [Example 22].
>
> All great.
>
> > I've also added an example that shows how spanners are kept in paged mode.
>
> Great idea, but the specific example isn't very enlightening. (I
> wouldn't have expected any other rendering than the one shown.) Much
> more interesting would be to show what would happen if the new Example
> 22 above were showing paged media instead of continuous; imagine that
> the multicol box shown is not a constrained one but merely one which
> occupies the full height of a (very short) page. The overflow column
> wouldn't exist, of course; it would be on the next page. But what about
> the spanner...?
I've added an example 23 for this.
> >>>> Issue 15:
> >>>>
> >>>> What is the relationship between the 'column-fill' property (7.1) and
> >>>> the break properties (5) for example as demonstrated in 8.2 Example
> >>>> XXIV? Presumably balance is disrupted in the presence of an explicit
> >>>> break, but how exactly?
> >>>
> >>> Explicit column breaks are honored, even if 'column-fill: balance' is
> >>> specified. Just like 'widows', 'orphans', margins, padding, borders
> >>> etc. are honored, even if this can disrupt balance.
> >>>
> >>> So, setting 'column-fill: balance' is more about choosing one of two
> >>> possible strategies when adding content, than to get exactly the same
> >>> column lengths. This is expressed in the paragraph:
> >>>
> >>> There are two strategies for filling columns: columns can either be
> >>> balanced, or not. If columns are balanced, UAs should minimize the
> >>> variation in column length. Otherwise, columns are filled
> >>> sequentially and some columns may end up partially filled, or with
> >>> no content at all. In any case, the user agent should try to honor
> >>> the widows and orphans properties.
> >>>
> >>> One may argue that column breaks etc. should be added to the last
> >>> sentence.
> >>
> >> I do think it would be useful to mention them:
> >>
> >> | In any case, the user agent must honor forced breaks and forced
> >> | break avoidance, and should try to honor the widows and orphans
> >> | properties.
> >>
> >> (Note that the spec wording makes it seem like forced column breaks and
> >> forced break avoidance are mandatory. If that's not the case then the
> >> spec needs to say so and the proposed sentence above obviously needs
> >> tweaking.)
> >
> > I don't think we can mandate forced break avoidance. A very long
> > paragraph with 'break-inside: avoid' must be broken at some point.
> >
> > I've reworded the sentence to say:
> >
> > In any case, user agents must honor forced page breaks and should
> > try to honor 'widows', 'orphans' and other properties that may
> > affect column lengths.
>
> OK.
>
> >>> But I don't see how we can make the spec more specific.
> >>>
> >>> There is also a separate discussion on the last part of 7.1.
> >>>
> >>> http://lists.w3.org/Archives/Public/www-style/2011Dec/0100.html
> >>
> >> OK, I agree that "If columns are balanced, UAs should minimize the
> >> variation in column length." is pretty clear about the intent. But is
> >> it true that reducing the number of overflow columns wins over the need
> >> for balance (and in particular no balancing is attempted whatsoever if
> >> the number of column breaks in an unconstrained multicol in continuous
> >> media contains a number of column breaks equal or greater than one fewer
> >> than the number of non-overflow columns)?
> >>
> >> I think that the spec should modify the sentence just mentioned to
> >> achieve something like the following:
> >>
> >> | If columns are balanced, UAs should minimize the variation in
> >> | column length subject to avoiding overflow columns if possible and
> >> | minimizing the content in overflow columns otherwise.
> >>
> >> Another issue though: "variation in column length" isn't the right
> >> phrase, because columns in the same row are always of equal length. It's
> >> the content height that can vary.
> >
> > Yes. Hmm. I suggest:
> >
> > If columns are balanced, user agents should try to fill all columns
> > in a row so that the columns appear to have the same amount of
> > content, while also trying to minimize the overflow content.
>
> But that doesn't actually indicate which constraint wins. Perhaps
> that's intentional on your part (to give UAs freedom to innovate here).
> If so, a sentence which states that the spec consciously doesn't
> specify exactly how the two constraints compete would be welcome. But
> if you do have a preference then I think it should be specified.
There is now a preference in the ED:
In any case, user agents must honor forced breaks and should
try to honor ‘widows’, ‘orphans’ and other properties that may
affect column lengths.
That is, forced breaks are strong constraints. Other constraints are
not ordered; trying to order them would limit implementations, make
the specificaiton much more complicated, without ever being able to
fully describe how content is broken into columns.
> Also I'm not won over by "appear to have"; it makes it sound like some
> sort of visual trick can be employed. I preferred "minimize the variation".
How about changing this:
If columns are balanced, user agents should try to fill all columns
in a row so that the columns appear to have the same amount of
content, while also trying to minimize the overflow content.
to
If columns are balanced, user agents should try to minimize the
variation in content between columns, while also trying to minimize
the overflow content.
Does that seem better?
> >>>> Issue 16:
>
> Note: in this section, I refer several times to a multicol box being
> eligible (or not) for splitting onto a new page. I was referring to a
> multicol with constrained height, believing that such a multicol
> overflows in the inline direction rather than splits to a new page.
>
> You wrote:
>
> > Overflow in the inline direction only happens in continuous
> > media; in paged media overflow column go onto the next page(s)
> > instead. This is described by this text:
> >
> > # .. additional column boxes are created in the inline
> > # direction for continous media, and additional column boxes are
> > # moved to the next page(s) for paged media.
>
> I disagree that this text justifies your claim! The text describes a
> specific case: that of explicit column breaks. Yet the first case in
> the three-case list from which you draw your quote explicitly says that
> additional column boxes are created in the inline direction (in the case
> of a constrained height). If you wish the spec to honour your claim then
> the first case needs rewording.
I see your point. I propose to change:
A multicol element can have more columns than it has room for due to:
- a declaration that constrains the column height (e.g., using
‘height’ or ‘max-height’). In this case, additional column boxes
are created in the inline direction
- the size of the page. In this case, additional column boxes are moved to the next page(s).
- explicit column breaks. In this case, additional column boxes are
created in the inline direction for continuous media, and
additional column boxes are moved to the next page(s) for paged
media.
Columns that appear outside the multicol element in continuous media
are called overflow columns.
into:
A multicol element can have more columns than it has room for due to:
- a declaration that constrains the column height (e.g., using
‘height’ or ‘max-height’)
- the size of the page (in paged media)
- explicit column breaks
In continous media, additional column boxes are created in the
inline direction; columns that appear outside the multicol element
in continuous media are called overflow columns.
In paged media, additional column boxes are moved to the next page(s).
> This leads us to an interesting question: if a multicol with a
> constrained height appears on page 1 and doesn't occupy the full height
> of the page, what precisely happens to an overflow column? You claim it
> should move to the next page; presumably then the remainder of the first
> page stay empty.
Yes.
> And what about the multicol box fragment on the second
> page... is it constrained by the same height constraint as the multicol
> box fragment on the first page, or is this "overflow" fragment allowed
> to be as tall as the page will let it?
I don't see any reasons why it shouldn't be constrained by the same height.
> (Another way to think of this
> is, do you see a constrained multicol element as containing arbitrarily
> many columns of the same constrained height, and that in continuous
> media these columns overflow in the inline direction but in paged media
> the multicol box is split into equal-height fragments on as many pages
> as necessary to absorb all the columns (ie the overflow is paginated?)
Yes.
> >>>> 8.2 (Pagination and overflow outside multicol elements) says:
> >>>>
> >>>> # Content and column rules that extend outside column boxes at the edges of the multi-
> >>>> # column element are clipped according to the overflow property.
> >>>> #
> >>>> # A multicol element can have more columns than it has room for due to:
> >>>> #
> >>>> # * a declaration that constrains the column height (e.g., using height or max-height ).
> >>>> # In this case, additional column boxes are created in the inline direction
> >>>> # * the size of the page. In this case, additional column boxes are moved to the next
> >>>> # page(s).
> >>>> # * explicit column breaks. In this case, additional column boxes are created in the inline
> >>>> # direction for continuous media, and additional column boxes are moved to the next
> >>>> # page(s) for paged media.
> >>>>
> >>>> In the second case, presumably the multicol element itself is split
> >>>> across pages, so it's not clear to me that this case is relevant to the
> >>>> situation of a multicol element having "more columns than it has room for".
> >>>
> >>> I see your argument. This would also be the case for #3: column that
> >>> end up on the next page du to explicit column break are not outside
> >>> the multicol element either.
> >>>
> >>> Perhaps we could resolve both by changing:
> >>>
> >>> "A multicol element can have more columns than it has room for due to:"
> >>>
> >>> to
> >>>
> >>> "A multicol element can have more columns than its first box has
> >>> room for due to:"
> >>>
> >>> although the term "first box" may not be ideal -- ":before"
> >>> pseudo-elements could get in the way. Hmm, suggestions?
> >>
> >> I think we may need to rewrite this section a little. I was about to
> >> suggest a rewording when I realized that I'm not clear about the
> >> behaviour of column breaks in paged media. Example XXV is useful, but I
> >> can't tell if it shows a special case in which content reaches the
> >> bottom of the first page in the second column box or whether there's an
> >> empty vertical space in the page box below that column box. That is,
> >> what happens if the multicol element is at the top of the first page but
> >> is eligible for splitting to the second page? Would there be three
> >> columns of page box height on the first page, each only partially full,
> >> with more column boxes on the next page (possibly overflowing if the
> >> multicol isn't eligible for splitting onto a further page)?
> >
> > In paged mode, there are always more pages available so content would
> > never overflow like in Example XXIII or Example XXIV.
> >
> > So, yes, there would be three columns on the first page, each only
> > partially full (due to forced column breaks) with more column boxes on
> > the next page (and subsequent pages.)
> >
> >> Or would
> >> the multicol be allowed to split onto the second page after the first
> >> three column breaks, leaving a blank vertical space below the first
> >> fragment of the multicol box on the first page, with more column boxes
> >> on the next page (possibly overflowing if the multicol isn't eligible
> >> for splitting onto a further page)?
> >
> > Yes. I don't see the difference between your first option and the
> > second option. Both seem correct to me.
>
> In the first option the column boxes are the full height of the page,
> despite all being only partially full. In the second option, the column
> boxes and indeed the multicol box fragment that encloses them are
> shorter than the page height, meaning that the page contains empty
> vertical space. Judging from the "each only partially full" in your
> penultimate response, I'm assuming that it's the first option that holds.
Yes.
> >> Or would the multicol be allowed to
> >> overflow in the inline direction on the first page? I get the
> >> impression that the latter is only permitted when the multicol is
> >> constrained, but what if the constraint is such that the multicol may
> >> still split across pages: is it only the last multicol box fragment
> >> (that appears on the last page) that may overflow in the inline direction?
> >
> > Overflow in the inline direction only happens in continuous
> > media; in paged media overflow column go onto the next page(s)
> > instead.
>
> See above. (The very last situation that I'm describing above is a
> multicol that begins near the bottom of a page, and which has a
> constrained height let's say an explicitly-specified 'height' that's
> larger than the remaining space on the page. Can you describe the
> resulting rendering, assuming a very large quantity of overflow?)
The result should be the same as whether the element with an explicit
height is multicol or not. I would think most implementation honor the
explicit height and moves the element to the next page, but I think
this is outside the scope of the multicol spec (and perhaps all CSS
specs).
> >> Let's return to reworking 8.2 once I'm clearer about the behaviour above.
> >
> > Ok, let me know if you have suggestions.
>
> More clarifications needed first!
>
>
> > When reviewing this, I have revised Example XXV slightly: columns are
> > balanced by default, so it's better to show three columns with content
> > on the second page.
>
> Good catch.
>
> > Also I've added more examples.
>
> Yes. Example 26. This example would be a lot more interesting if it
> borrowed the CSS from Example 25 and not just the content, and if it
> also assumed a page of height much greater than 5em. (It would then
> correspond to one of the options that I'm talking about above.)
I see what you mean. We could add and example with the constrained
height on a page, one that shows that the constraint remains on the
second (and subsequent) pages. That's what you are requesting, right?
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net
Cheers,
-h&kon
Håkon Wium Lie CTO °þe®ª
howcome@opera.com http://people.opera.com/howcome
Received on Monday, 15 April 2013 16:59:29 UTC