- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 May 2018 15:58:48 -0400
- To: "www-style@w3.org" <www-style@w3.org>
=========================================
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