- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Oct 2014 14:50:03 -0400
- To: www-style@w3.org
Flexbox
-------
- RESOLVED: Accept current solution for issue 20 (keyword for auto
flex basis), with issue for waiting on compatibility
feedback, and explaining alternate solution.
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-20
- RESOLVED: Accept proposed resolution for issue 21
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-21
- RESOLVED: Ignore the potential effects of an intrinsic min/max
size when resolving percentages
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-27
- RESOLVED: Accept issue 39
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-39
- RESOLVED: Rejected due to misunderstanding of the spec for
issue 22
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-22
- RESOLVED: Rejected due to out of scope on issue 23
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-23
- RESOLVED: We like flex-wrap: balance idea but are deferring it
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-25
- RESOLVED: No-change on issue 35
http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-35
- RESOLVED: Republish as LC when the edits are done
===== FULL MINUTES BELOW ======
Scribe: SimonSapin
Flexbox
-------
<TabAtkins> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325
TabAtkins: The last call issues list
TabAtkins: Please check the open issues box so we can go through
just the 5 open ones.
<dbaron> (12, 20, 21, 27, 39)
fantasai: Skip 12, we talked with Rossen.
TabAtkins: You can consider it closed.
TabAtkins: Issue 20. New keyword other than auto for flex bases
TabAtkins: "main-size" would work, but did poll of authors, ??
responses.
TabAtkins: 21 in favor of "main-size", [...]. Options were:
<TabAtkins> axis-size
<TabAtkins> flex-main-size
<TabAtkins> initial-size
<TabAtkins> main-size
<TabAtkins> use-size
TabAtkins: First 3 options received one vote each, use-size had 4.
TabAtkins: Firefox already has the new value as main size.
TabAtkins: It seems fine for now for compatibility issues.
fantasai: We're confirming on the name, and whether we need to
back out and do something different.
fantasai: The next publication is LC anyway. We can mark it as an
issue "waiting for back compatibility data".
TabAtkins: Can we resolve to take this value, pending further
issue reports?
Rossen: So, no 'auto' at all?
TabAtkins: You can use 'auto', it means same as usual.
fantasai: Right now 'auto' just passes through from width/height,
there's no way to flex.
fantasai: We can either rename 'auto', or come up with a different
keyword for automatic behavior.
fantasai: That is, you looked at width/height and got auto.
fantasai: So calling it 'auto' makes sense, but we could rename if
compatibility is an issue.
gregwhitworth: Why not leave auto and add a new value?
TabAtkins: It's weird to have 'auto' and it to have a different
meaning as in width/height, while other values are the
same.
fantasai: [draws an example] 'flex-basis: auto' looks at the width
property.
fantasai: We need value A look at width, and value B is automagic
fantasai: For A, if width is auto, you get automagic.
Rossen: The current behavior seems good.
fantasai: Disadvantage is that some existing content relies on the
earlier meaning.
TabAtkins: 'main-size' does what auto used to do and now auto does
what it does in width.
TabAtkins: Previously, you could not specify auto in flex-basis
without setting width as well.
TabAtkins: The new keyword does not collide with width values.
fantasai: The options are, first: The auto keyword continues to
look at width and do just that. There's no compatibility
issue, and we need a new keyword for the automagic.
fantasai: The other option is the one that we're trying to
achieve: the magic is called 'auto' and the "look at my
size property" is called 'main-size'
TabAtkins: That option is what Firefox implemented. There's minor
compatibility issues.
dbaron: The one existing issue was pretty major, on Google search,
but you fixed it.
TabAtkins: Another issue is not likely, we state in the spec to
use some patterns.
TabAtkins: The tutorials use the flex shorthand, which is fine.
dbaron: This stuff is pretty new.
TabAtkins: The Google search issue was because of a tool.
fantasai: The other issue- shorthand 'flex: auto' means main-size,
not auto.
fantasai: For the main-size solution we have flex-basis: auto and
width: auto match, but a small backwards-compatibility
issue. Not huge, but we don't know how trivial. Also
flex: auto means flex: main-size, which is inconsistent.
To preserve compatibility it has to stay, but it's kinda
awkward.
fantasai: The disadvantage of the magic solution is that
flex-basis: auto does not match width: auto, but there's
no backwards-compatibility issue and the flex shorthand
is consistent.
fantasai: I'm leaning toward doing the keyword for magic instead.
TabAtkins: No, let's not change what we have unless forced by
compatibility problems.
TabAtkins: Things are dumb no matter what.
fantasai: Comments?
dbaron: I don't wanna keep changing stuff
fantasai: I was surprised that Mozilla implemented so quickly.
* fantasai was hoping for it to get reviewed immediately, not
implemented immediately :)
dbaron: You should have said it was not ready.
SteveZ: The point is that the meaning of a size keeps the same
meaning.
SteveZ: Why not call it "use something"?
TabAtkins: Because the poll says people don't like it.
TabAtkins: "main" is a term of art in flexbox.
SteveZ: I'm not objecting.
TabAtkins: The name isn’t great, we could do better.
TabAtkins: Does anyone object? There’s a small possibility of
finding a compatibility issue.
fantasai: I'm concerned about this.
fantasai: Auto often means do a special case.
TabAtkins: But that complicates the grammar.
dbaron: Grammar is more than syntactic, it also defines meaning.
fantasai: I’d prefer the grammar was just the grammar.
TabAtkins: I don’t want to say <'width'> in grammar if auto has a
different meaning.
gregwhitworth: I’d rather stick with what we have.
Rossen: Is that in nightly?
dbaron: It's in aurora now
Rossen: I want to see compatibility on mobile. Do you get numbers
on desktop mostly?
dbaron: We do get bug reports from users.
Rossen: Mobile usage of flexbox is way higher. If we're not
capturing mobile, we're understating compatibility issues.
fantasai: Put this (below) in the spec, mark it as an issue.
<fantasai> flex: auto; expands to flex-basis: main-size;
TabAtkins: This is what I would do it we start from scratch.
TabAtkins: 'flex: auto' meaning something strange is the only
thing I'd do differently.
Bert: No objection, but you mentioned current-size as one option?
TabAtkins: No.
Bert: We have currentcolor, so current* would make sense.
fantasai: I wish we had this idea 3 months ago.
dbaron: Is it really the current size, in the middle of the
process, not the one you end up with? Feels weird.
TabAtkins: Sounds like no objections.
fantasai: As long as we mark it as an issue because we're waiting
for compatibility feedback. Would love to hear from
Microsoft on that. We already know what to do if it's an
issue.
RESOLVED: Accept proposed solution for issue 20, with issue for
waiting on compatibility feedback explaining alternate
solution.
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-21
fantasai: Issue 21. We're waiting for review from Rossen or
anybody else interested. It's about cross-side of
stretch items being definite.
Rossen: Yes, this is fine. Accept proposal.
RESOLVED: Accept proposed resolution for issue 21
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-27
TabAtkins: Issue 27: implications of adding min-content
max-content to min/max-width/height properties.
TabAtkins: Previously, min/max were always definite.
TabAtkins: They resolved to 0 or something. Now, you can say min-
width:min-content, which is not definite. Can't use
that for clamping.
fantasai: The issue is percentage sized child is trying to
resolved against your height. Say you have a definite
height, but the min-height is indefinite. What does the
child resolve against? Could end up at different height
than specified.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0009.html
[fantasai explains what's in the email]
fantasai: Three proposed options [...]
<fantasai> What should happen in such a situation?
<fantasai> A. Have the percentage child size as for 'auto', as for
intrinsic. 'width/height' values on the parent. (This
means that, by default, percentage heights will never
work on children of flex items, since flex items have a
default min-size calculation involving the min-content
height.)
<fantasai> B. Ignore the potential effects of the min/max size
when resolving the percentage (This means the child may
underflow/overflow the flex item.)
<fantasai> C. Do a two-pass layout. (We already do this in some
cases, like percentage cross-sizes resolved against an
indefinite flex container. But note that stacked 2-pass
layouts are O(n^2).)
<fantasai> D. Something else?
TabAtkins: A is not great, percentages won’t work most of the
time, B not great because you can overflow or
underflow, C is not great because it's expensive.
dbaron: [explains a corner case]
<dbaron> I think we already hit this with <div id="A" computing
intrinsic width on this><div id="B" style="width: 600px;
min-width: 50%"><div id="C" style="width: 50%" need to
figure out intrinsic width of this></div></div></div> ...
though maybe the behavior here is undetectable.
TabAtkins: Okay, we can have indefinite always be ignored for the
purpose of percentages.
dbaron: The behavior may be undetectable in that case.
dbaron: My intuition is B.
TabAtkins: B is also my preferred one. It's the least disruptive
while maintaining some usefulness.
fantasai: Seems reasonable.
TabAtkins: 2-pass layout is exponential when you stack flex boxes.
Rossen: In windows apps, the level of nesting gets deep pretty
quickly. 9 levels is not uncommon.
Rossen: There are ways to avoid it being exponential.
dbaron: Intrinsic widths are not right anyway unless we do
percentage reversing.
dbaron: You divide non-percentages by one minus percentages.
gregwhitworth: C would allow authors to declare these to work as
expected?
TabAtkins: Yeah.
TabAtkins: However, dealing with multi-pass layout getting stacked
causes significant performance problems.
* fantasai is scared of C
TabAtkins: It's already possible to invoke at least a second
layout per flexbox.
TabAtkins: You can do up to 4. It's not great.
Rossen: Should we straw poll?
dbaron: What do you mean by multi-pass? We want to keep intrinsic
widths from layout.
TabAtkins: The first pass figures out min-content, so the second
can clamp. This is layout affecting intrinsic sizes.
Rossen: So, an unclamped pass to figure out min-content, then use
that to get the main size?
TabAtkins: Yes.
Rossen: Theoretically you can still do one pass only.
TabAtkins: It's possible to do a trick to avoid exponential, but
you still need multiple passes
<fantasai> [The more I think about
http://dev.w3.org/csswg/css-flexbox/#valdef-flex-auto
the more I think it is weird]
TabAtkins: I wanna go with B, it's simple.
Rossen: Let’s poll. Does anyone want A? Let's toss it out.
Rossen: We can narrow down to B and C.
SimonSapin: Intrinsic requiring layout sounds very bad.
SimonSapin: It sounds very bad if intrinsic size requires layout.
SteveZ: How often does this happen?
TabAtkins: All the time, one of the default values in flexbox
involves intrinsic sizing.
fantasai: We at least want to avoid dependency cycles.
TabAtkins: Vertical text has percentage against the height that is
infinite, resolve to 100vh.
fantasai: So we do a straw poll?
TabAtkins: Of B vs. C
fantasai: Issue is: width:600px, min-width: min-content
(potentially bigger than 600px). Percentage-sized child.
What does % refer to?
fantasai: B: Ignore the clamping for percentages
SimonSapin: Only flexbox or in general?
fantasai: In general
florian: So ignore min/max always, or only if it it’s not
definite?
fantasai: The latter.
dbaron: The normal thing is ignore things that require information
from the parent.
fantasai: Option C is to do multi-pass layout to try to figure out
min-content, and decide which size the % should refer to.
[poll results]
astearns: C
shans: B
TabAtkins: B
zcorpan: B
gregwhitworth: C
Rossen: C
dbaron: B
fantasai: not sure
SimonSapin: B
13 abstentions
Bert: In CSS 2.1 percentages don't require two passes, we should
keep that.
Bert: But we still want to have same-sized things.
fantasai: 'flex: 1'
fantasai: B seems simpler; I'm happy with that.
SteveZ: If you want to, you can fix it later. Lots of implementers
in the room, not many users.
dbaron: Users would expect the percentage thing anyway, intrinsic
sizes are already meaning less anyway
fantasai: A is gonna make users unhappy.
SteveZ: Picking B now seems safer, authors can complain and we can
do better later.
zcorpan: There's still a compatibility problem.
fantasai: It's unlikely that authors expect min-width to trigger.
It's more of a safety
Rossen: Even though I'm in favor of C, I feel we can be more
interoperable with B.
fantasai: I’m solidly on B at this point.
RESOLVED: Behavior B - Ignore the potential effects of the min/max
size when resolving the percentage
<TabAtkins> <br type=lunch>
Scribe: gregwhitworth
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-39
fantasai: This is about the max-content definition in the previous
spec which is wrong.
dbaron: Does this account for the flex basis?
TabAtkins: Yes.
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/#intrinsic-sizes
fantasai: We would like a WG resolution on this issue.
dbaron: Sounds fine to me.
RESOLVED: Accept issue 39
fantasai: There are a couple more issues that need to be
officially accepted by the WG.
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-22
florian: Is it very clear since it got mis-understood?
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/#order-accessibility
RESOLVED: Rejected due to misunderstanding of the spec for
issue 22
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-23
RESOLVED: Rejected due to out of scope on issue 23
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-25
RESOLVED: We like this idea but are deferring it for issue 25
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-35
RESOLVED: Rejected for no-change on issue 35
fantasai: I think that's it for Flexbox, I think it should be
published.
TabAtkins: This had major changes so we need to do a LC.
fantasai: We do want to have a feedback period for these changes.
fantasai: Do people want to approve the changes before we publish?
Bert: As long as nothing else is changed, I'm fine with this.
plinss: How much reworking?
fantasai: There's an edge case so we may have some behavioral
changes.
fantasai: Do you want us to publish after we do the edits, or
after a telecon?
RESOLVED: Republish as LC when the edits are done
fantasai: We still have the LC period for people to give feedback
Received on Wednesday, 15 October 2014 18:50:30 UTC