- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Dec 2015 19:33:45 -0500
- To: www-style@w3.org
Meetings on 23 and 30 December
------------------------------
- These meetings will not be held on 23 and 30 December unless
someone requests them on the internal mailing list.
Multiple Changes to CSS Align
-----------------------------
- RESOLVED: Accept all the changes:
1) justify-content: auto -> start / stretch (on grid /
flex items)
2) justify-content: stretch -> flex-start (on flex
items)
3) 'left' and 'right' -> 'start' (when operating in
the wrong axis)
4) 'flex-start' and 'flex-end' -> 'start' and 'end'
(on non-flex-items)
5) align/justify-items: auto -> start/stretch
(depending on 'display')
Flexbox
-------
- RESOLVED: Spec that the flex container must wrap around its
content in all cases, both the min-content and max-
content case.
- RESOLVED: Specify the heuristic as the behavior for multi-line
flex in min-content.
- RESOLVED: Spec both behaviors, put a note explaining
implementations are inconsistent, this can't be relied
on, the WG isn't happy on this and plans to drop one,
but can't decide which.
- RESOLVED: Change the spec to say you don't have to fit all the
flex items on the page, you have to just fit one in
regards to pagination.
- RESOLVED: Take Flexbox to CR
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2015Dec/0207.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Elika Etemad
Tony Graham
Jihye Hong
Dael Jackson
Philippe Le Hégaret
Chris Lilley
Peter Linss
Simon Pieters
Anton Prowse
Florian Rivoal
Lea Verou
Greg Whitworth
Regrets:
Angelo Cano
Tantek Çelik
Simon Fraser
Daniel Glazman
Brad Kemper
Alan Stearns
Ian Vollick
Zheng Xu
Scribe: dael
Meetings on 23 and 30 December
==============================
Rossen: Okay, it's about 5 past the hour. Let's get going.
Rossen: Any additional topics?
Florian: I was wondering if we could shuffle the agenda.
Rossen: No, it's arranged in that way for a purpose. I'm aware of
the time difference.
Rossen: Any additional items?
fantasai: I wanted to include all the open flexbox issues. There's
only 3.
Rossen: We have 5 items for flexbox on the agenda. If there's
additional we'll get through them. But flexbox is #1, then
grid, then round display.
Rossen: A quick reminder. There will be a lot of people traveling
in the next weeks. The current poll shows weak attendance
where we have 5 people for one meeting and 6 for the next
one.
Rossen: As stands we'll cancel those two meetings. If you really
want to have discussions, e-mail the private list and
we'll go from there.
Multiple Changes to CSS Align
=============================
Rossen: [read next few items]
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Sep/0097.html
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0327.html
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0280.html
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0061.html
fantasai: I think these are all a group. As we discussed last week
there was concerns about having values compute from one
to another so we went and made them not compute. So this
was asking for review and approval of those changes.
Rossen: We reviewed them on our end. We don't believe we'll have a
problem with the dependency changing. It would be great to
hear from dbaron or someone from Mozilla who raised
concerns.
Rossen: Do we have anyone from Mozilla?
dbaron: I'm here. I'm fine with the changes in general, though I
didn't review the actual edits.
Rossen: If that's the case, we can proceed with rubber stamping
all. dbaron if you find issues please raise them. Ideally
these should be good to go.
RESOLVED: Accept all the changes:
1) justify-content: auto -> start / stretch (on grid /
flex items)
2) justify-content: stretch -> flex-start (on flex items)
3) 'left' and 'right' -> 'start' (when operating in the
wrong axis)
4) 'flex-start' and 'flex-end' -> 'start' and 'end' (on
non-flex-items)
5) align/justify-items: auto -> start/stretch (depending
on 'display')
Flexbox
=======
Intrinsic Cross Size Definition Totally Wrong
---------------------------------------------
Heuristic for Shrink to Fit
- - - - - - - - - - - - - -
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0180.html
<fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514#issue-12
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3773
Rossen: I don't see resolution on the list for this so wanted to
see if we can resolve this.
Rossen: Do we have anyone from Blink?
<TabAtkins> I'll be in the call shortly, catching a bus right now.
fantasai: The first issue is how do you size each column in the
flexbox and the second is how do you size the flex
container.
fantasai: We have interop on the column, it's a kind of heuristic.
Basically for the minimum size you take the min-content
size of all the items (you can look at the test case).
Rossen: Is this min and max in the presence of a cross constraint,
or with no constraint?
fantasai: If no constraints are present you have a single column.
This is one that wraps.
Rossen: Okay. I wanted to make sure everyone was on the same page.
fantasai: The min-content size people are doing a heuristic which
makes sense.
fantasai: You find the largest min-content for all the items. You
lay out all the items into that as your column width.
fantasai: Whatever your results are, you make the column as wide
as the widest item.
fantasai: In the example we did a fix for that amount of space. We
didn't have more, so we have items in the first column
in the max-content. If I made the min-content thing
narrower, they might wrap. They won't get smaller than
the min-content. Once the layout is done we take the
largest of the sizes in that column.
fantasai: So is that heuristic what we want to put in the spec? Or
do we say you can do this or something more accurate? Or
something else?
<fantasai> 1. Spec this heuristic
<fantasai> 2. Spec this heuristic, say you can do better
<fantasai> 3. Something else
<fantasai> This is just about sizing the items and the cross-sizes
of the flex line s(columns)
<fantasai> Not about flex container sizing around the columns --
that's 2nd issue
Rossen: My preference would be to have interoperability for this,
regardless of what we arrive at. #2 opens the door for a
lot of non-interop.
Rossen: If I understand your proposed algorithm, you're saying
that you're going to base the...are you suggesting we do a
per column min-size as we go? Or that we assume there's
one column, find the min in that context and use it for
all the columns?
fantasai: Neither, kind of. You're finding the min-content
assuming everything is in a single column. You're just
looking at min-content. You go through every single item
and find the min-content. That's the available size for
a shrink to fit. You shrink to fit all the items.
fantasai: If an item is smaller, it won't wrap. If it's wider it
will wrap. But any item could be smaller than the min or
up to the min, but not larger.
fantasai: Once you've laid out you break them into lines. You see
in a line what is the widest. If it's smaller than the
min-content it will be smaller or it will be that size.
Not bigger. So you make it as small as possible.
Rossen: So I think you're describing the algorithm we've had. Per
line min-content based on the min-content of the line.
What I'm trying to say is the difference from the
multi-col algorithm where we distribute the size to be the
same which is why we prefer the largest min-content, that
would leave empty space in other columns.
fantasai: The difference between this and multi-col is multi-col
they all have to be the same size. Here if the max-
content is smaller than the min-content, the column will
be smaller than the min-content.
fantasai: If you load the test case that's what you'll see.
fantasai: So option 1, 2, or 3?
gregwhitworth: I do prefer IE 11 implementation better. Edge,
Chrome, FF we all overflow
fantasai: That's a separate issue.
Rossen: That's the flex container.
fantasai: There's two behaviors of concern. How do you find the
size of the column and the other is size of flex
container.
Rossen: As an implementor I favor #1, but I want to hear from
Mozilla and Blink.
fantasai: Mozilla, do you have an opinion?
dbaron: You'd have to ask dholbert.
Rossen: And is TabAtkins on?
fantasai: I don't know if he's on yet.
<TabAtkins> calling in *right now*
fantasai: Okay. Let's come back to this with TabAtkins
Size of Flex Container
- - - - - - - - - - -
fantasai: So the size of the flex container. Once we've found the
size of the columns, how big is the flex container? We
don't have interop...or at least no good answer. Firefox
and Blink size to the size of the largest min-content.
So more than one column overflows your flex container.
Which doesn't make sense.
Rossen: I agree. That's what we did for interop some times during
Windows 10 development. We did the min-content compromise
and we have better behavior for the max-content where we
wrap around the columns. I'll second gregwhitworth and
favor the behavior where the flex container wraps all
lines, not the widest. But that would be good to hear from
other implementors.
Rossen: Looks like TabAtkins is on.
TabAtkins: I'm not sure what the behavior is.
<Rossen> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3773
fantasai: We're discussing right now the flex container sized
around all the columns or an arbitrary size.
TabAtkins: Obviously it's wrap all columns. Christian is against
it, but Shane is for it.
fantasai: So the flex container should contain all the columns in
the spec.
<dbaron> I'm concerned about speed of intrinsic width computations
in flexbox, though, and also about having dependencies on
layout.
Rossen: So when we do shrink-to-fit we shrink around what we're
fitting and not overflow by default.
TabAtkins: The current Blink always overflows with +1 column and
it's stupid.
Rossen: That's what we did in min case, but we'd be happy to revert.
gregwhitworth: Are you guys open to discussing what we do with
regular block?
TabAtkins: It's not the problem, right?
gregwhitworth: We brought it to TPAc 2 years ago.
fantasai: That was different. That was a case of content could be
bigger.
<fantasai> but wasn't overflowing
gregwhitworth: I'm happy with flex doing this. It's two sides of
the same coin.
TabAtkins: I have vague memories of the issue, but it's not the
same.
Rossen: It's you can have load next to a non-BFC which is related
to max-size.
TabAtkins: But it's not directly related to what we're discussing.
This is you can't float a multi-col flexbox because it
will have wrong size.
fantasai: So a flex container must fit all the columns in a shrink
to fit in it. Objections?
dbaron: Is this introducing more dependencies on layout?
TabAtkins: It is. It's either layout dependency or wrong behavior.
dbaron: I'm unhappy about more layout dependencies. Also, we need
to stop fiddling with this at some point.
fantasai: This wasn't specced.
Rossen: We do want to keep flex same as soon as we can. That's why
we front loaded these issues. But I'm in favor with
TabAtkins where we want the same behavior with layout
primitives. There aren't any presentation systems that
would default to this weird behavior. We should strive not
to allow this. I hear you and yes the is a dependency in
layout, there's no way around it.
<TabAtkins> <div style="display:flex; flex-flow: column wrap;
float: left;"> will break *every single time* if you
have >1 line. Absolutely, unarguably wrong behavior.
<TabAtkins> (In Chrome's current behavior.)
<TabAtkins> (Current chrome behavior is that it will overflow the
float no matter what you do, if you're relying on auto
sizing.)
Rossen: Back to the call of objections...and dbaron if you have a
different option to solve it, I'd like to hear it.
dbaron: At some point some of the odd combo of features has to be
use cases we're not concerned about.
TabAtkins: Yes, but Shane yesterday brought this to me yesterday,
this exact case. It's easy to run into.
Rossen: We ran into this in early stages of Windows 8 when we were
working on flexbox. At the time a lot of the paradigm
dependencies were on overflow in the horizontal space for
apps. So dependency on your cross size with the height
expecting your content would fit into the horizontal
stretch. Unless you have the same algorithm for wrapping,
you have odd overflow by default.
dbaron: So we're proposing to spec something that would change
behavior for all engines.
TabAtkins: Edge is correct.
Rossen: And IE. IE is more correct because we don't have a quirk
for min-size. We can back out the quirk happily.
dbaron: I guess I'm okay with it then.
Rossen: Okay, so the proposed is to spec that the flex container
must wrap around its content in all cases, both the min
constraining and no constraint case.
Rossen: Any objections?
RESOLVED: Spec that the flex container must wrap around its
content in all cases, both the min-content and
max-content case.
Heuristic for Shrink to Fit
- - - - - - - - - - - - - -
fantasai: Back to the first half of the issue, sizing the columns
in the box. Should we spec the heuristic which is
interoperable?
Rossen: So dbaron defers to dholbert and we wanted to hear from
TabAtkins.
TabAtkins: I'm fine with the heuristic.
Rossen: The proposal is to spec the heuristic without allowing
other interpretations.
TabAtkins: I don't know why we'd request better because it's
insanely expensive.
Rossen: Can we resolve, wait for dholbert, resolve conditionally
for dholbert?
<dbaron> I'm lost on which message we're talking about
<dbaron> We just resolved on
https://lists.w3.org/Archives/Public/www-style/2015Dec/0055.html ?
Rossen: We're talking about the algorithm to resolve the min-size
in a multi-line flex.
Rossen: dbaron this was the topic where you said you'd defer to
dholbert.
dbaron: Still some part of 0055.html?
fantasai: Yes, there's 2 issues. The first issue is how do you
size the flex items and the flex columns.
dbaron: I'm trying to convey these to dholbert. I don't see this
in 0055.html
<fantasai> Current browsers perform an approximation of this,
finding the
<fantasai> largest intrinsic cross-size among *all* items and then
<fantasai> shrink-to-fit sizing each flex item into that much
available space.
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0180.html
Rossen: This should have the issue ^
<TabAtkins> is also confused - he thought we were already done
with the min-size stuff.
dbaron: I guess don't worry about me. I won't understand this
during the call.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3773
<fantasai> ^ this test case demonstrates what happens
Rossen: Let me summarize. The idea is in the case of multi-line
flex which has a constraint in the cross size, the min
preferred size is calculated per line. So first we
calculate the min-size across all the items in the flex.
That gives you start of a line.
dbaron: Is this specific to...
Rossen: To flexbox and differs from multi-col where there we have
to keep all columns same size. That's why we prefer taking
the largest and distributing.
dbaron: So the main issue was for one orientation and not the
other, in the message. Is this the main size matching the
block direction?
Rossen: The issue is only when the cross size has a constraint.
When you have to have multi-lines..
dbaron: The main size has a constraint?
Rossen: Yes.
Rossen: When the main size is constrained, yes.
Rossen: In this case the cross size is what is driving the minimum
content.
Rossen: So proposed heuristic is we will do a similar algorithm to
multi-col but instead of leaving them the size of the
largest, we shrink the ones without the maximum item.
dbaron: So this is for intrinsic size computation. You're placing
items into columns to give them different sizes.
Rossen: Because the column height is constrained. Right.
<fantasai> TabAtkins, we're discussing how flex items and flex
lines are sized under a min-content constraint for a
multi-line column flexbox
<fantasai> TabAtkins, the question is, should we spec the
heuristic that is what the impls do
TabAtkins: Oh! Easier way to talk about this. You've got a height
set, a column flex box, you have min-content. Figure
out the largest min-content, assume that width. Layout
and if they don't use all the space let the line shrink
to that size.
dbaron: So which implementation does this match?
fantasai: All.
TabAtkins: Everyone does this. It's just not specified.
TabAtkins: There's a more correct way to do it that requires
iterative layouts.
dbaron: Okay. Then I'm okay with it.
Rossen: Objections?
Rossen: To specifying the heuristic as the behavior for multi-line
flex in min-content?
RESOLVED: Specify the heuristic as the behavior for multi-line
flex in min-content.
Percent Margin Issue
--------------------
fantasai: Two more flexbox issues.
fantasai: First is the percent margin issue. We don't seem to be
able to get consensus. I asked Ralph, who manages CR
transition, what do we do and he says spec both and note
that there is not interoperable or in agreement.
fantasai: I think we should do that so we can get flex republished.
So you resolve vertical percentages against whatever
direction you feel like until we decide.
Rossen: So we can have text that describes resolving against width
or height or just say nothing?
fantasai: We say you can resolve against width or height, but
nothing else.
Rossen: We'd be okay with specifying both in the spec.
fantasai: Is that okay with everyone else?
<Bert> +1 (if that gets the spec out...)
dbaron: I'm worried it'll be permanent.
TabAtkins: It won't get any faster by blocking flexbox spec.
Rossen: I'd prefer to be as specific as possible, but I'd like to
get flexbox out the door. After all this time talking back
and forth and putting out arguments, it sounds like
there's too many people on both sides. The proposed way
out sounds sane.
Rossen: If there's objections to this, please let us know a better
proposal to get out of this.
<gregwhitworth> that's the current state yes
SteveZ: What I'm hearing sounds like you're going to leave the
state where a user is not sure which context the
percentage will be implemented in terms of. It seems to me
over the long run if it persists no one can trust percent
value. That seems a bad thing to bake in. Didn't we talk
about adding a parameter allowing you to say which one you
want?
TabAtkins: We never agreed on anything. I don't want to block
flexbox based on us having a solution. We want to get
out a spec that describes these two options. It's not
great. no one likes it, but it's better than what's out
there.
SteveZ: I don't disagree. I raised the question because if we
don't decide we think percentages aren't useful.
fantasai: We should continue working on this.
TabAtkins: That is a fact. We're making sure they don't get worse
with a third behavior.
SteveZ: I think you should put that note in.
TabAtkins: Yes.
dbaron: Spec currently says percentage relative to the relevant
size.
fantasai: Yes.
Rossen: That was before Blink re-opened the topic.
dbaron: Can the spec say there's not consensus without changing
that that's the current resolution?
TabAtkins: I think it's more accurate to tell authors 'hey, either
of these work'.
TabAtkins: I want a strong note that this is bad and we should fix
it. But I don't think it serves to pretend that we have
one behavior with different details when it's two.
Rossen: So Firefox, IE and Edge implement the spec as written.
Blink implements the dependency on cross size. Speccing
both would enable the spec to move forward. But as SteveZ
points out it leaves the confusion and as dbaron says it
might bake it in.
TabAtkins: Specs aren't reality. The describe things...what is
written is a guide to authors and implementors. Putting
something in doesn't lock it in any more than not
putting it does. We're describing reality.
TabAtkins: If this is resolved next week we'll republish.
Rossen: I would like to hear from anyone else. This sounds like a
good way forward. I'm personally biased to the issue and
don't want to tip the conversation.
SteveZ: I think documenting what is happening is better than not
saying anything. And IDing that this is not a good
situation is good. So I agree with TabAtkins' assessment
that we ought to document what is and say it's not
wonderful.
SteveZ: Rossen, you made the point it should be as specified as
possible to avoid other interpretations.
Rossen: And is anyone using this? The answer is pretty much no.
Rossen: At least in the context of flexbox.
Rossen: If we leave the spec in this situation, do you think it's
a good idea to add a note saying what this means to
authors?
fantasai: I'm happy to add whatever notes people want to have. I
want to give to Ralph something he can publish as CR
without objections.
<gregwhitworth> agreed, let's get this published :) +1
Rossen: So do we have objections to the revised spec that will
spec both behaviors with a note explaining what it means
to authors?
<Bert> (Need to mark the options "at risk", otherwise a later
republication will be a substantive change.)
Rossen: I don't think this is at risk, Bert
Bert: I was wondering about what TabAtkins said about when we
decide what it should be, the easiest to republish is to
remove an at risk. Otherwise it requires more review.
fantasai: I think that's fine.
ChrisL: You don't have to do that anymore. It is possible to
publish an updated CR if you show you got good review.
Bert: Needs director approval?
ChrisL: It doesn't need transition call.
<ChrisL> the updated CR of css writing modes was done like that
fantasai: Proposal: spec both behaviors, put a note explaining
implementations are inconsistent, this can't be relied
on, the WG isn't happy on this and plans to drop one, but
can't decide which.
fantasai: Can we resolve on that?
Rossen: Objections?
<ChrisL> +1
RESOLVED: Spec both behaviors, put a note explaining
implementations are inconsistent, this can't be relied
on, the WG isn't happy on this and plans to drop one,
but can't decide which.
Pagination
----------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0163.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0165.html
fantasai: This issue. There is an error in the Flexbox spec for
fragmentation. We're causing the flexbox to have a break-
inside: avoid behavior. I think it's wrong, Florian
reviewed and agrees it's broken.
fantasai: The specific rule says [reads].
fantasai: It needs to say that you don't have to fit all the flex
items on the page, you have to just fit one.
Florian: And you can opt back into the current behavior by adding
break-inside: avoid
Rossen: How do you guarantee progress?
fantasai: This is only if flex container is not at top of page.
Rossen: Okay.
Rossen: That sounds reasonable.
Florian: As part of checking the current behavior, I looked at
different browsers doing flex fragmentation and it's all
over the place.
Florian: I have a simple text case in the e-mail reply. If you
look in different browsers you have different things.
Firefox doesn't break, Webkit just does the border.
fantasai: Can we focus on this issue and resolve on it? It's just
an error.
Rossen: Objections?
RESOLVED: Change the spec to say you don't have to fit all the
flex items on the page, you have to just fit one in
regards to Pagination.
Rossen: fantasai make the change and we can re-raise the issue.
<Florian> Rossen: look at this in different browsers:
http://output.jsbin.com/hezica/ it's all over the place
CR Publication
--------------
<fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514
fantasai: That's the whole DoC. Can we go to CR?
<gregwhitworth> YES YES YES
Rossen: Absolutely :)
Rossen: Objections?
RESOLVED: Take Flexbox to CR
Rossen: We have 5 topics still on the list for the call. A few
grid and round-display. Since we don't have enough
participation for the next two weeks, those issues will
need to continue on the ML. Or please start raising your
hand on the private list and we'll go from there. As
stands we'll cancel the next two weeks.
Rossen: Happy holidays, safe travels, and if we don't hear from
people on the list I'll talk to you in the new year.
<gregwhitworth> Happy Holidays everyone!!
<dauwhe> happy holidays!
<jihye> happy holidays! : )
<fantasai> Bert, ChrisL: Which one of you wants to handle the CR
transition ? :)
<Bert> I can, but I'm back from holiday only on the 11th.
<Florian> dbaron, could you look into this mail thread
https://lists.w3.org/Archives/Public/www-style/2015Dec/0096.html
and particularly this reply I made
https://lists.w3.org/Archives/Public/www-style/2015Dec/0106.html
<dbaron> Florian, maybe sometime after 3pm
<Florian> Thanks, that'd be great. I think we're one reply on the
ML away from closing what was point 11 on the agenda
today
<dbaron> Florian, although I'd note that 'polar-angle: 0' isn't
valid because the unitless 0 rule is only for lengths
<dbaron> Florian, although we may well have to change that for Web
compat if WebKit/blink don't fix it
<Florian> Noted, I'll be more careful about that in the future.
That's just a syntax error on my part though, orthogonal
to the issue being discussed.
<SimonSapin> unitless zero for angles doesn’t sound too bad
<SimonSapin> if we manage interop
<TabAtkins> linear-gradient() used to require distinguishing, but
not anymore.
<TabAtkins> But I'm unhappy with how ambiguous 'flex' gets just
with zero lengths, and I'd prefer not spreading that
crap further.
Received on Thursday, 17 December 2015 00:34:49 UTC