W3C home > Mailing lists > Public > www-style@w3.org > May 2018

Minutes Berlin F2F 2018-04-12 Thu Part II: Multicol

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 29 May 2018 15:58:48 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <ebaa89cc-4f33-7958-b329-28d87728a0ba@inkedblade.net>
=========================================
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.
=========================================


MultiCol
--------

   - RESOLVED: Have rachelandrew make the change to refer to
               fragmentation in general instead of paged media
               specifically. (Issue #1746)
   - RESOLVED: Move this issue (Add switch to avoid generating empty
               column boxes?) to L2. (Issue #1565)
   - RESOLVED: Won't change [in reference to height of column rule]
               (Issue #2309)
   - RESOLVED: No change to L1 [for spanning elements late in the
               content], refiled against L2 to think about in context of
               n-spanners (Issue #2448)
   - RESOLVED: Go with option 1 in this sizing issue - overflow columns
               affect the multicol container's height. (Issue #1745)
   - RESOLVED: Accept the proposed text in https://github.com/w3c/csswg-drafts/issues/2549
               [In continuous media, this property (balancing) does not
               have any effect when there are overflow columns]
   - RESOLVED: Publish a new working draft of multicol

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael

MultiCol
========

   rachelandrew: I've got a few issues. I'd like to after we take edits
                 from here do a new WD

Add switch to avoid generating empty column boxes?
--------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1565

   fantasai: I think your issue is wrong
   TabAtkins: Possibly.
   fantasai: I think you're confused about what dbaron said and your
             issue doesn't make sense.
   <TabAtkins> Ahhh, I understand my issue now.
   <TabAtkins> I was just misreading it. It's a feature request (with
               details), not a bug report.
   <fantasai> TabAtkins, I think that should be tagged against L2 then
              :)

References to Paged media
-------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1746

   rachelandrew: There's a bunch of references about paged vs continuous
                  media which should be fragmented vs continuous contexts.
                  There was a suggested text change, but I don't think it
                  was edited in.
   rachelandrew: I wanted to check if it was still suitable.
   florian: I suppose it implies difference in behavior when nesting
            multi-columns. Is this desired?
   dbaron: I think some of the wording is because there's stuff we do
           different when you're multicol and self doesn't fragment.
           You fill up columns on that page when you won't fit and then
           move to the next page.
   florian: Right, if you're in a big multicol with tiny col... yes it's
            desirable.
   rachelandrew: Add the text in the 2013 email?
   dbaron: I suspect fantasai may have better wording since stuff has
           changed in the last 5 years.
   rachelandrew: If we agree this is desirable I can draft some text
                 and we can bikeshed.
   astearns: We can resolve to have you make the change to refer to
             fragmentation in general instead of paged media
             specifically.
   rachelandrew: Cool.
   astearns: Sound good Rossen?
   Rossen: Yes.
   Rossen: Obj?

   RESOLVED: Have rachelandrew make the change to refer to
             fragmentation in general instead of paged media
             specifically.

Add switch to avoid generating empty column boxes? (continued)
--------------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1565

   TabAtkins: dbaron raises not making columns if they would be empty
              in another issue. I don't think it can be automatic, so
              suggestion was to add a switch to auto-drop empty cols which
              can then be handled by justify-content. Bottom of the
              description is how justify-content would handle that.
   fantasai: Defer to multicol L2?
   TabAtkins: Yep. I'll rephrase the issue to make it less confusing.
   Rossen: Objections to move to L2?

   RESOLVED: Move this issue to L2.

Column rules should only be drawn to the height of the column contents
----------------------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2309

   rachelandrew: We wanted feedback from designers. A couple of people
                 commented on the thread.
   rachelandrew: 3 options:
                 1) create user controls so people can explicitly
                    control column rules
                 2) keep current spec
                 3) change spec so height of column rule is content
                    height
   florian: When it's column height if two adjacent columns are different
            you pick the longer one?
   rachelandrew: Yes.
   rachelandrew: Generally people I spoke to, if there was a height they
                 would expect the rules to go to the height. That's
                 current spec. So it's if we want to add a switch to
                 allow content height which is option 1.
   florian: I'm not opposed but I'd rather this in L2. I'd be opposed
            to this in L1.

   rachelandrew: Have L1 remain as is which is height on container.
   fantasai: Makes sense because you can always get the content height
             option by wrapping the multi col.
   rachelandrew: I haven't seen many use cases for content height.
   myles: Why would anyone want it?
   rachelandrew: I haven't seen many use cases.
   myles: If one is never valuable don't make a switch. Close it.
   fantasai: If people want it we can open a new issue with their use cases.
   Rossen: I think we resolve this as don't change and move on.
   rachelandrew: Happy with that.
   Rossen: Objections?

   RESOLVED: won't change

   astearns: I do think adding a comment to the issue telling people
             that have commented that they can open an issue on level 2.

Spanning elements late in the content, treated as column-span: none
-------------------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2448

   rachelandrew: You've got a spanner that's late enough that there
                 isn't space to span. UA may treat it as if none has
                 been set. I raised this as an issue against Chrome. FF
                 doesn't span yet. There's an example code pen in the
                 issue from the spec.
   rachelandrew: Chrome's behavior isn't particularly useful.
   rachelandrew: There wasn't interest in implementing the behavior
                 allowed in the spec and they thought authors should
                 refrain from this. Is it useful to have in the spec?

   florian: Chrome behavior is terrible so we shouldn't allow that.
   rachelandrew: Yes, but their point was they didn't think this was
                 useful to have in the spec.
   florian: If we have a good behavior it's worth a may in the spec. Is
            there an alternative to the may?
   fantasai: Can't think of anything.

   rachelandrew: What will you do with them?
   dbaron: This is column spanning elements in a multi col with a fixed
           height?
   florian: Yeah.
   dbaron: Model of column spanning elements if you split the multicol
           into multiple multicol and you can only apply the fixed
           height on the last. So you get to it and you've gone past
           the max height and what should you have done earlier to make
           it fit?
   fantasai: I guess alternative is overflow downwards instead of
             creating more columns.
   dbaron: Normally multicol with fixed height make more columns but
           you can't do that here unless you go back.
   florian: Overflow to extra columns and span that?
   fantasai: Don't know number of columns.
   fantasai: [whiteboards] when you make a spanner it breaks into
             multiple sets of spanner columns.
   fantasai: [draws a row with 3 small boxes and then a row with one
             long box and then several other rows] when you have one
             set of columns and run out of space it generates more
             columns. Your spanner goes down. [draws a row with 5
             columns/boxes] you overflow here and make more columns.
             It's not awesome but it's another possibility of what you
             can do.
   [whiteboard picture: https://lists.w3.org/Archives/Public/www-style/2018Apr/0009.html ]
   Rossen: I see how you draw that but introducing breaks in columns is
           nuts.
   florian: You have the spanner and the contents before you basically
            end up in a 2 pass thing.

   dbaron: I could make a no-more multipass suggestion which is that if
           you have a multicol with col-spans you never overflow by
           making more columns. Instead any sets of columns before a
           column span are auto height. That's always true. You fill
           the height you need. Then you have to fill the height you
           need.
   dbaron: Basically you ignore the height when you're generating sets
           of columns before the span and then you ignore when
           generating the span itself. Then you get to the last set of
           columns and you honor the height if it means making it
           taller. If it makes it shorter you do auto-height again.
           It's all overflow going down.
   florian: I think okay.
   dbaron: Only thing you'd do to honor the height is make the last set
           of columns taller to fix. Pretty different from what
           multicol does otherwise, but seems not completely crazy.
   florian: Are you suggesting you keep the may and allow either what's
            in the spec or this or just this?
   dbaron: I'd like to spec one behavior. We can try and spec something
           sane for the other. But if you start to allow column spans
           in some cases you get a bottom column that's shorter and
           shorter.
   florian: And then all the sudden it pops out of the spanner
   fantasai: So dbaron your method is a mode switch depending on if you
             contain spans?
   dbaron: You should know if you have spans up front.
   florian: Depends on if it spans the entire multicol or the current
            fragment of the multicol. If it's the second you still have
            to do layout.
   dbaron: I feel like fragments in the multicol aren't that different
           from [missed]
   florian: That's true.  If you're in a non-fragmented multicol you
            trigger on presence of spanners and if you're in fragmented
            multicol you always do this and only place you have to
            start worrying is the last one.

   fantasai: Seems to me we should make the behavior undefined.
   rachelandrew: That results in...well...
   florian: Chrome does something bad.
   astearns: What we have isn't what Chrome does.
   fantasai: They're filling the content then there's a spanner and it
             has to go below.
   florian: You don't layout your columns and then find out there's a
            spanner, you find out first there's a spanner.
   Rossen: Also when we want to have variable column count spanners it
           becomes hokey. Triggering breaks and switching overflow in
           what direction. Multicol is simple and elegant in what it
           does. Overflow columns are always in one direction and spans
           always span the columns. You're not really creating rows and
           trying to use those rows...
   fantasai: I think if you have a spanner you don't want column rules
             underneath. Conceptually you have rows of column boxes.
             Going forward we should not have a model of column boxes
             through the spanners.
   rachelandrew: I think that's right.

   rachelandrew: Do we want to try and resolve or to go away and think?
   Rossen: L1 or L2?
   rachelandrew: The may is in L1. Edge does spec behavior.
   Rossen: And chrome has a bug they can fix
   florian: Bug allowed by spec.
   rachelandrew: If this is what we want we should remove the may.
   florian: And if we want to do the thing dbaron suggests it shouldn't
            do one or the other. Author should choose.
   fantasai: What bothers me about dbaron's model is for all content
             before the spanner I add content, get one behavior and as
             soon as there's a spanner i get different behavior and
             that's weird. What if you want the other behavior anyways?
             Add an empty spanner?
   dbaron: If you want continuity you should get that going from end of
           multicol not start. If you want the thing with the spanner
           to be the same as without one way is to try and make it so
           the bit after the last spanner behaves same as no spanners.
   dbaron: Still hard.
   <rego> this example looks bad in Chromium: https://codepen.io/mrego/pen/GxLQJm
   florian: If you try for that you're past max height so you have no
            space left and an infinite number of 0 height columns.
   dbaron: I'm thinking that way because balancing for the bit after
           the last span is the thing that honors things like column
           fill.
   fantasai: Right. I still think it's... if you as an author wanted
             that I'll still have a 0 height spanner at the bottom. I
             don't think that's great. Interesting way to have a mode
             switch.
   florian: If you don't set a height we don't have the problem in the
            first place.

   florian: If you combine that with Rossen's comment that eventually
            we want to span n columns instead of all.
   Rossen: That's been a request since we into multi col.
   <dbaron> I think one of the prior mistakes here was probably
            allowing column-spanning elements anywhere within a
            multicol rather than just at the start...many things would
            have been simpler if they could only be at the start.

   Rossen: Let's try and move forward. There's more work to be done if
           we want to move forward with this. And it's in L2. Let's
           resolve on L1.
   Rossen: Choices:
           1) continue with the may
           2) change to an undefined
           3) may changes to must
   florian: 3.
   Rossen: And we'll add continuation in L2
   fantasai: I vote 1 or 2 because as we try to figure out how n column
             spanners work we may have a better idea of how this should
             work.
   florian: Which allows chrome to fix themselves.
   astearns: But you shouldn't expect that to happen.
   fantasai: I think that rethinking this once there's a model for n
             spanners it'll give us a clearer way forward. Rather then
             prematurely deciding this case.
   Rossen: Would chrome people have a problem with this as a must?
   eae: It's very hard for us to implement that behavior. We know
        current isn't great.
   Rossen: Outside of test cases I haven't seen compat problems.
   rachelandrew: It's edge case-y.
   Rossen: I propose we stay with the may for L1. If give Chrome the
           ability to continue but validates the other model Edge uses.
           In L2 we think more.
   rachelandrew: I'll raise this against L2.
   fantasai: And I'd mark to rediscuss after we figure out n columns.
   florian: Well, while we do n columns.

   Rossen: Do we need resolution?
   fantasai: Prop: No change to L1 refiled against L2 to think about in
             context of n-spanners
   Rossen: Opinions or Objections?

   RESOLVED: No change to L1. Refiled against L2 to think about in
             context of n-spanners

Can overflow content influence column height?
---------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1745

   rachelandrew: This one...[reads]
   [
     (1) the multicol element is made high enough to fit all columns.
         In this case, there will be three columns: two with one line
         each, and a third column -- outside the multicol element --
         with 10 lines. The yellow box will be high enough to fit the
         third column, even if it shown outside the multicol element.
     (2) the multicol element is made high enough to fit all columns
         that end up inside the box. So there will be two columns with
         one line of text each inside the multicol element, and then
         there will be 10 overflow columns outside.
   ]
   rachelandrew: There's an example in the comment.
   [
     Consider a multicol element with two columns, and column breaks
       after each paragraph:
           article { columns: 2; background: yellow }
           p { break-after: column }
     Then you pour three p elements into the article: two one-liners
       and then one long paragraph (say, 10 lines). What's the
       resulting height of the article? 1 or 10 lines (disregarding
       padding for a moment).
   ]
   rachelandrew: What's the result 1 or 10 lines? Multicol is high
                 enough to fit all so it's 3 columns with one column
                 outside or it's made high enough to stay inside and
                 there's 2 columns.
   rachelandrew: Seemed to agree on second option, but I didn't know if
                 anyone else had comments.

   fantasai: Prefer 1.
   fantasai: Conceptually there's a row of column boxes and I'd like it
             high enough to contain all.
   TabAtkins: astearns comment points out balancing only happens in the
              specified columns.
   TabAtkins: I agree 1 is better overall but because balancing we
              should be consistent and ignore overflows.
   dbaron: When are you in a balancing situation with overflow columns
           and no column break
   TabAtkins: You have 2 1/2 columns with or data and you have a column
              break you balance across the columns.
   astearns: It's easy with explicit breaks. not sure without. Maybe a
             monolithic column that doesn't fit?
   fantasai: I think the reason balancing doesn't consider overflow
             columns is that you have too much content to balance when
             there's overflow. So it gives up at that point.
   florian: Monolithic thing and the thing before is 1.5 columns of
            content and then you have content after monolith and you
            balance before that?
   fantasai: Balancing doesn't balance the columns that aren't there?
   astearns: The ones not in the multicol element.
   florian: So you get 2 columns of .75 width, then a monolith and then
            content after that that overflows?

   fantasai: Need a test case.
   fantasai: What's a case that would trigger this?
   fantasai: If you have a bunch of text and it breaks. You have 3
             columns, you fill the first 2 and 10% of third and then a
             giant image that's too big, so moves to the fourth (overflow)
             column. The three columns then rebalance. Does anyone
             implement that?
   florian: [whiteboards] [there's a 1st column that's filled with
            text, a second column with a bit of text and a large image.
            It then goes into 2 columns of balanced text and then the
            image is in an overflow to the right.]
   fantasai: I don't think anyone implements that.
   florian: Do we agree spec says that?
   TabAtkins: That's what astearns said and I'm believing him.
   astearns: 4 years ago it did.
   fantasai: [reads] [no effect in overflow columns]
   fantasai: I think it should say no effect *when there are* overflow
             columns.

   Rossen: Test case?
   fantasai: Trying to write one.
   astearns: It's just that one sentence afaict
   florian: Performance wise it seems preferable to not do this.
   florian: Design-wise...?
   astearns: I think my reply is just the interpretation of that
             ambiguous sentence.
   fremy: If my test case is right I don't think we do it.
   fantasai: Mozilla does not rebalance.
   <fremy> https://wptest.center/#/0gcmv9
   <fremy> ^ my test case in case this is correct
   [fantasai works with test case more]
   <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5904
   fantasai: Chrome rebalances all of them. It does the overflow and
             the regular.
   astearns: So not following spec differently.
   Rossen: We're rebalancing as well.

   florian: Is break-inside:avoid impl by everyone?
   fantasai: If you didn't you wouldn't get everything
   fantasai: That's why I used page-break-inside
   fremy: That's for page.

   astearns: Back to the issue. People prefer taking into account the
             height of the overflow columns in determining height of
             multicol container.
   astearns: I think I still find that weird when you have
             overflow:hidden and you can have unfilled columns
   fantasai: But if you have overflow:scroll you want to scroll.
   astearns: I don't mind option 1.
   florian: More sense to me.
   rachelandrew: Yeah.
   astearns: Resolve on option 1 or still working on test cases?

   fremy: My test case shows edge is not rebalancing.
   [fantasai goes to look at fremy test case]
   [arguing over test cases]
   fremy: FF does not rebalance I think.
   <rego> this is using break-after: https://codepen.io/mrego/pen/GxLQJm
   <rego> in Chromium the size of the multicol container is 2 lines, in
          WebKit it's 1 line (in my example ^)
   fantasai: fremy in my test case if you remove the word columns.
   fantasai: nevermind.
   Rossen: Do we have enough to resolve? Should we come back later so
           people can play with test case?
   fantasai: It's clear we're not doing that line in the spec
   <rego> and in Edge my example has a bigger height

   astearns: I think we can resolve on this issue and add a new issue
             for balancing in overflow columns.
   Rossen: This is L1?
   rachelandrew: Yeah.
   Rossen: Okay
   astearns: Prop: Go with option 1 in this sizing issue- overflow
             columns affect the multicol container's height
   Rossen: Other opinions or objections?
   Rossen: Overflow columns effect container height is the proposal
   florian: Support.
   rachelandrew: Support as well.

   RESOLVED: Go with option 1 in this sizing issue- overflow columns
             affect the multicol container's height

Publication
-----------

   rachelandrew: I'd like to publish a new WD after today's edits are
                 made. I've got everything out of the archives.
   Rossen: Yes please.

   RESOLVED: Publish a new working draft of multicol

   <br type="15min">

   <rego> screenshots of my example: https://i.imgur.com/rK3lWWb.png
         (edge on the left, webkit on top right, and chromium on the
         bottom right)
   <fantasai> fremy: try
   <fantasai> 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22columns%3A%202%3B%20border%3A%20solid%20silver%3B%20height%3A%204em%3B%20width%3A%2020em%22%3E%0A%3Cdiv%20style%3D%22width%3A%200%22%3E%0AHere%20is%20some%20text%20%3Cdiv%20style%3D%22page-break-inside%3A%20avoid%3B%20overflow%3A%20scroll%3B%20border%3A%20solid%20orange%22%3Ethat%27s%20in%0Aseveral%20columns%3C%2Fdiv%3E%0A 
?
   <fantasai> fremy: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5905
   <florian> test case: https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5906
   <fantasai> rachelandrew, I filed https://github.com/w3c/csswg-drafts/issues/2549
              on the testcase issue we were looking at
   <rego> using widows:1 and orphans:1 in my example, make that both
          Chromium and WebKit shows just 1 line height multicol
          container

   fantasai: That test case issue is in multicol L1. Should we resolve
             before we forget?

Balancing and overflow columns
------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2549

   fantasai: There's proposed text in the issue.
   florian: Approve.
   rachelandrew: Makes sense.
   florian: Matches implementation.
   fantasai: At least 2.
   Rossen: That would be in time to make WD.
   <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5904
   Rossen: Objections?

   RESOLVED: Accept the proposed text in https://github.com/w3c/csswg-drafts/issues/2549
Received on Tuesday, 29 May 2018 19:59:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 May 2018 19:59:18 UTC