- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 05 Dec 2011 23:51:54 +0100
- To: "www-style@w3.org" <www-style@w3.org>
- CC: Håkon Wium Lie <howcome@opera.com>
On 04/12/2011 01:48, Håkon Wium Lie wrote:
>> Issue 1:
>>
>> Section 2 (The multi-column model) describes column boxes. They are not
>> described as establishing new block formatting contexts; only the
>> multicol box does that. I think this is flawed. If columns don't form
>> BFCs then we have to worry about lots of things including margin
>> collapsing between column content and columns and the scope of clearing
>> elements. Note that this section says:
>>
>> # Floats that appear inside multi-column layouts are positioned with
>> regard to the column
>> # box where the float appears.
>>
>> so either the column establishes a BFC or else a column box has a
>> property that has not appeared to date in CSS.
>
> I'm not sure that columns should establish BFCs. One reason for not
> doing so is intrusions -- I believe we want floats to be able to
> intrude from one column to another in the future:
>
> http://www.w3.org/TR/css3-gcpm/#multi-column-float-intrusion
>
> If we make columns BFCs, we cannot add intrusions this way, can we?
Thinking on this use case a while, I think it's persuasive. Rather than
being flow roots (BFCs), columns are something similar which I'll call
"flow containers" for now. Aside from page boxes (which I'm unclear
about), the set of flow roots coincides with the set of flow containers
in CSS21. However, whilst a flow root is always a flow container, in
CSS3 there are flow containers which are not flow roots; columns are an
example.
There has been discussion recently about trying to unify columns, pages
and regions so that they share a common model for flow and
fragmentation. I think it's a promising idea. I think the situation
would be that all three types of box are "flow containers", but columns
are not flow roots whereas regions are (currently defined as) flow
roots. Page boxes are unclear to me; they're not currently specified as
flow roots.
Float intrusions would be possible inside flow containers but not inside
flow roots.
I said that if columns don't form BFCs then we have to worry about lots
of things. Indeed we do, and the following issues still stand:
>> Issue 2:
>>
>> Related to Issue 1 above, if columns provide scope for floats and yet are not BFCs, do they also provide scope for clears?
I expect we want clears to be scoped by an individual column. A wider
scope doesn't make much sense to me.
>> Issue 3:
>>
>> Related to Issue 1 above, if columns provide scope for floats are yet are not BFCs, are they allowed to "bleed" out of the bottom of short columns?
What do you feel about this?
>> Issue 4:
>>
>> Section 2 (The multi-column model) says:
>>
>> # Column boxes act as the containing block for their content.
>>
>> Various specs use similar wording, but it's always clumsy. Obviously
>> they only act as the containing block for descendants for whom they are
>> the containing block.
>
> The main point that the sentence makes is that column boxes act as
> containing blocks. The last part, "for their content" can probably be
> dropped, but I don't really see what harm it does.
The harm is that it's only approximately true ;-). Although of course
the reader will understand the intended point. I feel that we should
try to put the imprecision that characterizes CSS21 behind us and
tighten up the prose in the CSS3 modules.
>> We could say something like "Column boxes
>> participate in the tree of containing blocks", but there's currently no
>> such concept described anywhere (despite existing conceptually), so
>> instead I suggest we just say:
>>
>> | Column boxes are block container boxes.
>>
>> Then the fact that they form part of the tree of containing blocks falls
>> out naturally and doesn't need explicitly stating.
>
> Hmm. I don't see anything wrong with stating that columns are
> containing blocks for their content, and I don't see how your proposed
> text improves the spec.
I think it's essential to state what type of a box a column box is, even
aside from the containing block issue above. Otherwise, a new type of
box has been introduced that is not well-defined. It's OK for the
outside-display of a column box to be a new type of box (simply called
"column box" for example; c.f. table box whose inside-display is
special), but the inside-display of a column box either needs to be the
same as an existing type or else precisely defined how it works. It
seems to be implicit from the spec that a column box is a block
container box; this must be stated explicitly.
>> Issue 5:
>>
>> The 'column-width' and 'column-count' (and hence 'columns') properties
>> are given as applying to "non-replaced block-level elements (except
>> table elements), table cells, and inline-block elements".
>>
>> At the very least, "table elements" should be "internal table elements"
>> since I guess there's no reason why a table caption shouldn't be a
>> multicol element.
>
> Internal table elements are defined to mean:
>
> "internal table element is one that produces a row, row group,
> column, column group, or cell."
>
> http://www.w3.org/TR/CSS2/tables.html#tables-intro
>
> So, the definition of an 'internal table element' excludes tables (as
> in<table>).
You're right. "Internal table elements" doesn't solve the problem.
> When the multicol spec refers to 'table elements', I
> believe it means<table> elements with and not the CSS 2.1 definition
> of "table elements", which is:
>
> In this specification, the term /table element/ refers to any element
> involved in the creation of a table.
>
> I'm not sure I like the CSS 2.1 definition as it leaves us without a term for
> referring to<table> elements.
Indeed. On the other hand a table _box_ is specifically what we want
here. (And in general, the CSS specs should be talking about boxes not
elements in many places; the over-use of "element" is another CSS21 bad
practice.)
>
> Also, "internal table elements" include table cells, which the
> properties specifically applies to.
(true, although they are not block-level so wouldn't have matched the
clause)
> I agree that the properties should apply to table captions, though.
Great. So what we really want here is "non-replaced block-level
elements except table boxes [notwithstanding the fact that this doesn't
make much grammatical sense], table-cells and inline-block elements".
This is precisely the block containers in CSS21. Which makes complete
sense, since the kind of box whose inside-display is apt for splitting
into columns is exactly a block container. And the current wording
potentially incorrectly excludes other types of CSS3 box (just as it
would have been wrong for table boxes had they not been explicitly
excluded) since it's not the outside-display that's important (ie
block-level) but the inside-display, just as tables demonstrate.
>> Better still, this sentence should be replaced with "block containers",
>> as per many other properties in CSS21 that were updated prior to PR.
I stand by this, for the reasons above.
> I only see 'overflow' and 'text-align' applying to 'block containers'
> in CSS 2.1; 'widows' and 'orphans' apply to 'block container elements'.
>
> Is this difference intentional?
A "block container element" isn't actually defined, but it's implicit
that a block container element is one whose principal block box is a
block container box (a term which /is/ defined in CSS21). This needs
to be fixed in CSS3, but the issue isn't something specific to the
multicol spec and we wouldn't want it holding multicol up. (Hence using
"block containers" is win-win for the multicol spec; the impreciseness
can be used to its advantage.)
(In general, CSS21 is a complete mess when it comes to the separation of
elements from boxes. This is a long-time and well-known issue.)
> And, where is the definition of "block containers"? It doens't appear
> in the CSS 2.1 index.
Sounds like a bug. I'll ensure it gets filed for CSS21 errata. (The
definition is in 9.2.1
[http://www.w3.org/TR/CSS21/visuren.html#block-boxes].)
> Given all this, perhaps you could come up with a revised proposal?
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.
>> Issue 6:
>>
>> 3.1 ('column-width') says:
>>
>> # To set an exact column width, all length values (in horizontal text these are: 'width',
>> # 'column-width', 'column-gap', and 'column-rule-width') must be specified.
>>
>> This sentence, which appears in a note, contradicts the following
>> sentence from the note in 3.4 (Pseudo-algorithm):
>>
>> # However, both ‘column-width’ and ‘column-count’ are honored when the width of the
>> # element has not been determined.
>
> Let's see.
>
> The first quote states that, if you want to set *exact* dimesions, you
> need to specify all length values.
>
> The second quote states conditions when two properties are *honored*.
>
> Now, honoring "column-width" is not the same as setting the column
> width exactly to the value given. The definition of 'column-width'
> states that the value is the optimal column width, but that the actual
> column width may be different. So, 'column-width' is *honored* even if
> the column width is not *exactly* equal to the length given.
OK, that works for me.
>> That the earlier sentence is false is also evident from the
>> pseudo-algorithm.
>
> How so?
Please ignore this; I had not distinguished between "setting exact" and
"being honoured".
>> Moreover, another problem with the earlier sentence is that it's
>> possible to "get lucky" and have the specified non-auto column width
>> turn out to be the used width depending on the state of the other
>> properties, so the sentence isn't quite true.
>
> I don't follow you here. Could you expand on this?
I was getting at the fact that you could specify a column-width and end
up with exactly that column width even if you hadn't set other
properties (either through luck or judgement).
>> Hence the earlier sentence needs revising.
>
> The note is meant to be helpful. And I believe it to be true. However,
> if it's more confusing than helpful, it may be best to remove it. Is
> that your suggestion?
No, now that you've explained the difference between the two sentences I
agree that both are useful. I didn't pick up on the difference
originally, so perhaps the first sentence could be clarified somehow;
but given that it's a note I don't think we should worry too much about it.
>> 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.
>> 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.)
>> Issue 8:
>>
>> 4 (Column gaps and rules) says:
>>
>> # Column rules are painted just above the background of the multicol
>> element. This allows
>> # child elements with ‘z-index’ values to be on top of column rules.
>>
>> s/allows child elements with ‘z-index’ values to be/ensures child
>> elements are always painted/
>> since every element has z-index (albeit sometimes auto) so it's not
>> necessary to mention it. My impression is that the intention of the
>> sentence is to point out that there's no way of putting a child element
>> below the column rule.
>
> I agree that the current text:
>
> (a) This allows child elements with ‘z-index’ values to be on top of column rules.
>
> is misleading, for the reasons you give. However, your proposed text:
>
> (b) ensures child elements are always painted
>
> is also misleading: one can never ensure anything in CSS, and elements
> are clipped in the middle of the column gap.
Touché ;-)
> I suggest we remove (a) and do not replace it with anything.
OK, I agree.
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.
>> However, my proposal does assumes that the multicol element establishes
>> a new stacking context. This seems reasonable, and it should be stated
>> if that's indeed the case. The quoted sentence remains true if
>> multicols don't establish new stacking contexts, but the result is
>> rather unexpected and the quoted sentence should be changed to make the
>> possible renderings more explicit in that case.
>
> What do implementors think -- do multicol elements establish new
> stacking contexts?
After thinking on this some more, I retract my comment. I don't think
it's theoretically necessary or expected after all. Implementers should
comment on whether it may be practically necessary though.
>> Issue 9:
>>
>> Section 5 (Column breaks) fails to describe how content is split from
>> one column to the next, and does not make reference to such a
>> description in any other spec. It does state:
>>
>> # The problem of breaking content into columns is similar to breaking
>> content into pages.
>>
>> This isn't really good enough, although I accept that there isn't yet a
>> definitive place which describes breaking behaviour but that it's
>> generally preferred that specs which rely on such behaviour do not try
>> to define it themselves. IMO this section certainly needs to reference
>> /something/; currently the most suitable candidate is 13.3.3 (Allowed
>> page breaks) of CSS21.[1] Such a reference might be implied from the
>> wording in Section 5, but it should be explicitly given.
>
> That's fine, we can add that.
OK.
>> Issue 10:
>>
>> 6.1 ('column-span') states that the 'column-span' property applies to
>> "block-level elements, except floating and absolutely positioned
>> elements". This should be replaced with the equivalent and more
>> succinct "in-flow block-level elements".
>
> Yes.
OK.
>> Issue 11:
>>
>> 6.1 ('column-span') implies that any block-level descendent of a column
>> box can be a spanner. Such an unrestricted model doesn't make much
>> sense to me. Surely only elements which participate in the block
>> formatting context of one of the columns should be allowed to span. What
>> are the use cases for allowing spanning from within a nested BFC such as
>> an inline-block, an overflow-scroll element, a float or an abspos element?
>
> I agree that is should be restricted. It should probably be expressed
> in the prose. Perphaps we could change this:
>
> The element spans across all columns.
>
> to
>
> The element spans across all columns of the nearest multicol
> ancestor of the same block formatting context.
Possibly s/ancestor of/ancestor in/ but OK.
>> Issue 12:
>>
>> 6.1 ('column-span') and 7.1 ('column-fill') define the computed value of
>> the respective properties to be "as specified". This is the vague
>> terminology of CSS 2.1 and I think that the level 3 specs should avoid
>> it. Does it mean "the specified value" as per the properties defined in
>> 5.1 for example, or does it mean "as described in the prose"?
>
> It means "specified value" and should probably be changed to just that.
OK. Let's do that.
>> Issue 13:
>>
>> 6.1 ('column-span'), Example XX contains a typo: "the first sentence in
>> the fourth sentence".
>
> Indeed, it should read "... after the fourth sentence ...".
This doesn't make any more sense to me! I think it should be "in the
fourth A-z string" or somesuch. (Some of the A-z strings are subdivided
into two sentences.) Or possibly:
s/after the first sentence in the fourth sentence/after the sixth sentence/
>> Issue 14:
>>
>> 6.1 ('column-span'), Example XXI demonstrates how UAs may choose not to
>> make an element spanning if there is "no room" to do so. However, the
>> example shows the "obvious" case; it would be more enlightening if it
>> showed the less obvious case in which the columns do not need to
>> overflow when the heading (possibly initiated in the first or second
>> column) is non-spanning but where the columns would overflow were the
>> heading allowed to span.
>
> I see your point. I'd like to keep the current example (which will
> happen more often than the case you are describing) but we could add
> another example.
OK great.
>> 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.)
> 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.
>> Issue 16:
>>
>> 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)? 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)? 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?
Let's return to reworking 8.2 once I'm clearer about the behaviour above.
[Note that the word "continuous" is spelt incorrectly twice in 8.2, as I
noticed when pasting into this e-mail!]
>> Issue 17:
>>
>> # Columns that appear outside the multicol element in continuous media are called
>> # overflow columns.
>>
>> Is it true that a column is either entirely outside of the multicol
>> element or entirely inside it? (Quite possibly this falls out of the
>> pseudo-algorithm, but I haven't checked in detail.)
>
> Yes, columns widths are elastic enough to fill all available space.
> (The concept of a minimal column width could possibly extend columns
> halfways outside the multicol element, but those were discussed and
> rejected in February.)
OK.
Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Monday, 5 December 2011 22:52:41 UTC