W3C home > Mailing lists > Public > www-style@w3.org > September 2013

[CSSWG] Minutes Paris F2F 2013-09-11 Wed IV: Multicol

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 19 Sep 2013 01:27:51 -0700
Message-ID: <523AB587.1020307@inkedblade.net>
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

This archive was generated by hypermail 2.3.1 : Thursday, 19 September 2013 08:28:26 UTC