- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 19 Sep 2013 01:27:51 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Multi-column Layout
-------------------
- Discussed layering order of column rules
- RESOLVED: Columns do not clip anything. (As if ::column just had
overflow:visible by default.)
- RESOLVED: Remove the restriction about overflow columns only being in
continuous media in the statement that column-fill has no
effect on overflow columns
- RESOLVED: Have two keywords for balancing - "balance" and either
"balance-last" or "balance-all", depending on what
implementations (including Prince and AH) do by default.
- RESOLVED: To balance columns, you just make the row as short as possible
(honoring breaking controls, sizes, etc.), then flow normally
into that height. No explicit "balancing" occurs (but it's a
common effect).
- RESOLVED: Håkon to create a public, editable, full list of issues with
source, response and resolution ; format up to him
====== Full minutes below ======
Multicol
--------
ScribeNick: TabAtkins
howcome: Quote: "the stylesheet business quickly devolves into something
where each person claims to be Napoleon, while asserting all
others are pretenders".
howcome: So if this turns into a shouting match, remember that I'm Napoleon.
howcome: We're very close to finishing.
howcome: We had a test suite go from submitted to approved.
howcome: Gerard has been working on this.
* sgalineau napoleon-complex: auto;
howcome: Three remaining issues.
<astearns> http://lists.w3.org/Archives/Public/www-style/2013Sep/0164.html
howcome: In any case we'll have to go back to LC, so we'll have to add
new options.
glazou: The issues are listed in some tracker?
howcome: The list of issues is this email.
howcome: First issue is about z-order of column rules.
howcome: Maybe the spec already specifies what we want?
Rossen: First came up during Tucson f2f.
Rossen: Spec at the time required that column rules are painted below
the inline content, and above backgrounds.
Rossen: Which made things inconsistent.
Rossen: So we'd need another layer to make that happen.
Rossen: Which nobody wants.
Rossen: For that reason we decided to draw column rules as part of the
inline content layer.
Rossen: Håkon is saying that, in addition to that, people thought that
column rules should paint on top of the multicol's border.
Rossen: I responded that this should happen automatically for
overflow:visible.
Rossen: For overflow:hidden or scroll, they'll be clipped anyway,
so we don't need to specify anything unless we do something
extra crazy.
Rossen: So I think we can just drop issue 3.
szilles: If I overflow the column, does the text paint above or below
the rule?
Rossen: Over the rules.
szilles: I think you need to add that to the spec.
ACTION rossen to add spec text to multicol specifying that text draws
over column rules.
<trackbot> Created ACTION-578
Bert: Are you sure that the spec doesn't already specify that?
Bert: It says that all text is on top of the rule.
Bert: Already has examples about a very wide rule.
Rossen: The way it was specified at the time, column rules were supposed
to be treated as part of the background layer.
Rossen: But you need to scroll them, so they're not part of the
background layer.
Rossen: And if they're on the column layer, do they interact with z-index?
<sgalineau> spec only says 'column rules are drawn just above the background'
<Rossen> Steve: the current text is already good for your issue
"Column rules are painted in the inline content layer,
but below all inline content inside the multicol element."
howcome: Next issue, clipping issue.
howcome: We currently say that flowing content that extends into column
gaps is clipped in the middle of the gap.
howcome: I think this makes sense in most cases, but it's weird that if
the long content is in the last column, it'll just overflow
outside of the element without clipping.
howcome: Someone asked for multicol to just always clip strongly.
szilles: Can't you just use 'overflow'?
howcome: That's my thought too.
howcome: Related, if you have an image that overflows across a column
*and* below the multicol, the spec doesn't say what to do with
the section outside of the multicol - do you still clip down,
or make it non-rectangular?
szilles: Guess it depends on the model - if I have opaque columns,
I can say that it's because the column overpaints it, so you
should expose the bottom corner.
zcorpan: But you can have transparent columns, so that doesn't hold.
szilles: Can I object to the clipping altogether?
szilles: Unless you put in an ellipsis or something indicating the
clipping is happening, you've changed the meaning of the content.
howcome: Should we honor 'overflow'?
Rossen: If we could target columns, yeah.
Rossen: But we can't, so we should just take the static position that
all columns are overflow:visible or overflow:hidden by default.
Rossen: So do you want to lose the content, or overlap it somehow?
I think losing the content is always worse.
glazou: [yeah, you can lose content]
TabAtkins: Yeah, I think the column clipping is inconsistent with the
eventual future of individually-addressable columns anyway.
howcome: Sounds okay.
howcome: So should we see if people want the clipping?
dbaron: I'm fine with dropping this. I'm much more fine with dropping
the clipping than being unclear about what's clipped and where.
RESOLVED: Columns do not clip anything. (As if ::column just had
overflow:visible by default.)
Regarding previous topic:
n/m
howcome: Last issue.
howcome: The CR says that column-fill will only be used (in continuous
media) if the column height is constrained.
howcome: There is a case to be made that we should consult this in all
cases, even if it's unconstrained.
howcome: So even if you have infinite space, we should still do column
balancing.
Rossen: So this is saying "do you want to auto-balance or not?", and
if you're already specifying with column breaks [...]
howcome: ???
szilles: So you have three columns. Put a break in the first column.
Are the last two balanced?
Rossen: If you don't have that property, you have to consider every
section of content between breaks as a balanceable unit.
Rossen: After you're done, ???
plinss: Theoretically, you could balance columns with breaks.
plinss: You could balance several columns with breaks.
dbaron: For example, if you have 10 columns and one column break
somewhere in the middle, you can decide whether that break
is between 3rd and 4th, or 4th and 5th, whatever, to
achieve maximum balance.
dbaron: Another hard thing is when your container has explicit height
versus not explicit.
dbaron: If your container has an explicit height and is paginated...
dbaron: And for extra fun, I think the model of pagination is that
you don't do balancing on any but the last page.
<dbaron> I think there was another hard case here but I've forgotten
what it was.
<dbaron> Oh, the other case is if you have overflowing columns
glazou: An issue with balancing and wysywig.
glazou: Say you have three columns without breaks.
glazou: At some point, author introduces a column break.
glazou: Remaining content is balanced in the other columns, which
increases the height of the entire container.
glazou: So I suggest to balance not in height, but in number of columns,
or else it'll be visually broken.
ChrisL: There are two cases. 1, the author wants a set amount of text
at the top of the column, a break, and the rest everywhere else.
ChrisL: 2, they want a particular gap at the bottom, and they care about
the gap being a particular size.
ChrisL: And we can't tell them apart.
fantasai: If you want some minimum amount of space, you do a margin.
If you want some space *and* nothing after it, you use a
column break.
Rossen: In your case, is the number of columns specified?
howcome: Yes, otherwise it'll just be 1.
howcome: So if it's set to 3, and balancing is turned off, all of it
should go to the first column, with the other two empty.
plinss: ???
howcome: So it sounds like we have agreement that we should honor
column-fill even in unconstrained environments.
dbaron: I remembered my other hard case.
dbaron: What happens when your container has a specified height, and
what is auto is your column count.
dbaron: You're producing columns of a certain width, and just filling
in columns as needed.
dbaron: I think the spec is clear that you want to balance if you
haven't overflowed, but what about if you have overflowed?
howcome: The spec is clear about this now - the property has no effect
in overflow columns.
<dbaron> commenting on "In continuous media, this property does not
have any effect in overflow columns (see below). "
quote from http://dev.w3.org/csswg/css-multicol/#column-fill
fantasai: There's a statement about continuous media, but you can have
overflow columns in print media.
fantasai: I don't see why the statement needs to be specific to continuous.
fantasai: [draws her example]
fantasai: You have a fixed-height box in a paged context. The box is
multicol with too much content. That content just plain overflows.
szilles: In principle, you could just generate more boxes, rather than
overflowing.
dbaron: I think that is just something this spec doesn't do.
fantasai: That's what dbaron's overflow spec is for.
RESOLVED: Remove the restriction about overflow columns only being in
continuous media in the statement that column-fill has no
effect on overflow columns
howcome: Back to the issue. Do we specify the interaction between column
breaks and balancing?
szilles: Yes, but it's hard.
plinss: So, columns are only balanced on the last page?
howcome: No. Roc argued that balancing should apply on pages with hard
page breaks.
plinss: So we make it generic, and balance just between breaks.
dbaron: So between hard page breaks, and anything but a soft column break?
dbaron: Like between a soft page break and a hard page break?
<dbaron> Q is what to do about soft page breaks
fantasai: I think it makes most sense to balance within a given column
row. I don't think it makes sense to balance between, say,
the start of the mutlicol and hard break, when there are more
columns in the row.
fantasai: That gives you different-height columns, which goes against
the point of balancing in the first place.
howcome: So what's the suggestion?
fantasai: When you hit a hard column break, turn off balancing for that
row.
howcome: For continuous media, that'll do bad things. In infinite height,
you'll get a really long column if you turn off balancing
entirely due to a column break.
plinss: I think that within a column row, you'll do your best to balance
between the column breaks.
plinss: And then you take the longest column, and that's the column height
for that row.
howcome: Given a very long paragraph followed by a very short one, with
hard breaks between them, the best strategy is to balance the
long paragraph first, then balance the last.
howcome: I think it's bad to simply not balance.
dbaron: I think you'd get that by balancing across the breaks as well -
run the balancing algorithm *with* breaks involved.
dbaron: For example, if the second paragraph is a bit larger, at some
point you can decide between placing the break between 3rd and
4th column, or between 2nd and 3rd column.
(much drawing of column boxes)
dbaron: This also makes a difference if we're in a situation where we
have two columns for each.
dbaron: Say first paragraph is 60% of the text, second paragraph is 40%.
Break goes between 2/3 column.
dbaron: Do you balance the first two columns, then draw the third column
down to the same height, and have the last column just the
leftover (not balanced)?
dbaron: Or balance the first two, then balance the second two independently?
dbaron: I think the first is preferable.
plinss: Agreed.
howcome: Isn't this multipass?
dbaron: No more than existing balancing, I think.
fantasai: I think that's right.
Bert: The goal is that each column row should be as short as possible
when balanced, yes?
howcome: Yeah.
dbaron: Right. The page break controls how much content is on a page.
fantasai: In Gecko, we try to find the soft-break column height that
is the shortest we can have without causing overflow
<dbaron> I think we were starting to get consensus on the idea that we
do balancing for each "row" of columns, whether or not it has
hard column-breaks in the middle of it, but never do balancing
across different rows of columns.
Bert: A page can get a lot shorter if you allow balancing between soft
breaks, if the last thing was a non-breakable paragraph that gets
shifted to the next page.
<dbaron> But Bert seems to disagree
plinss: When laying out a book, they generally don't rely on fully
automatic layout anyway. So if column balancing ends up with
a short page, they'll probably violate the non-breaking rule
for that page.
howcome: Right, but the goal is still to be balanced.
Bert: ???
Bert: I think filling comes before balancing.
<dbaron> I have a suggestion that's an alternative to another property
<Bert> (My '??' were trying to say that a page that is not the last
page of a chapter should preferably be full-height, even if
that means unbalanced columns. I agree with Steve that a
designer might want to have the choice.)
szilles: I think controlling that might be a switch between between
"last only" (or rather, only between soft and hard breaks) or
"balance between every page break".
fantasai: Lea, you've been working with paged media recently.
leaverou: I've not had experience with multicol in my book so far -
the pages are single-col.
fantasai: [explains to Lea]
fantasai: What if you have an unbreakable thing near the bottom of
the second-to-last page, so it gets pushed.
fantasai: There's a gap now, a soft break.
fantasai: Do you want to go back and balance those two columns, or
leave that gap there?
fantasai: Assuming the author is already balancing the last page.
leaverou: I think it's clear that the author indicating no gaps means
they want it all the time.
leaverou: I can't think what happens in most books.
fantasai: Most books don't have large things floating around in their
content, so they don't see it.
fantasai: Or they manually adjust things to avoid such gaps
SimonSapin: I've heard of systems, maybe not with CSS, that balance
across pages so that if you have an image that goes across
the page, that gap gets distributed across several prior
pages.
SimonSapin: I'm saying that in Paged Media, for page breaks, we decided
to leave that to impls.
fantasai: I think we should definitely define this.
<dbaron> column-fill: auto | balance-last | balance-all (or name one
of them balance rather than balance-...)
dbaron: There was a brief discussion about a control for this.
dbaron: There's not necessarily a need for a new property - we could
just have a new value.
dbaron: One called "balance" and one called something else, with one
of them doing the preferred default behavior and the other
doing the other thing.
plinss: balance-last would take effect at the end, and any set of
columns where you have a hard break.
dbaron: Not sure about that - you can have a hard column break in the
middle of a row.
plinss: lf you have a ???
fantasai: Moz's algo is that you have a row of columns.
fantasai: The column height (how high your column rules are) is
consistent for the entire row.
fantasai: And you pick the shortest height that doesn't overflow,
while honoring the column breaks.
plinss: I'm not sure if that's accurate.
TabAtkins: I think it is - balancing isn't really about getting
equal-height columns (that's just a usual result). It's
about getting a minimum height.
plinss: If you have a break in the second column, it shouldn't move
from that column.
fantasai: No, it should be able to move the break around. It won't
move text across pages, though.
TabAtkins: Yeah, you can move text or breaks around *in a given row*,
but nothing gets shifted to other rows due to balancing.
szilles: Would the minimum height violate widows/orphans?
fantasai: No, it's the minimum achievable height, *honoring all the
other properties*.
howcome: We still need to decide between one or two balancing keywords.
fantasai: I think balance-all and balance-last are great, but we
already have "balance".
howcome: but people are using 'balance', so we should keep it and add
one of the others for the other meaning
fantasai: So we need to decide which behavior gets named "balance".
howcome: I think "balance-last" is a good keyword.
TabAtkins: So "balance" does the all-balancing?
howcome: Yeah.
TabAtkins: So this controls behavior for all non-column breaks?
TabAtkins: Like between soft region breaks?
howcome: yes.
fantasai: So what's implementations here?
howcome: Weird.
Rossen: In IE, we balance without the column break.
Rossen: If the column break comes very late, the error accumulation
gets large, and we push things around.
Rossen: I'd prefer "balance" to mean "balance-all".
Bert and plinss seem to prefer balance == balance-last.
TabAtkins: I think when I've seen this in books, they balance the page,
so balance == balance-all.
howcome: I suggest we flip a coin.
RESOLVED: Have two keywords for balancing - "balance" and either
"balance-last" or "balance-all", depending on what
implementations (including Prince and AH) do by default.
<dbaron> We don't have a resolution on any of the discussion about
how balancing works.
RESOLVED: To balance columns, you just make the row as short as possible
(honoring breaking controls, sizes, etc.), then flow normally
into that height. No explicit "balancing" occurs (but it's a
common effect).
RESOLVED: Håkon to create a public, editable, full list of issues with
source, response and resolution ; format up to him
Received on Thursday, 19 September 2013 08:28:25 UTC