W3C home > Mailing lists > Public > www-style@w3.org > October 2014

[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-10 Part III: Flexbox

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Oct 2014 14:50:03 -0400
Message-ID: <CADhPm3tz7cnjMhzjCY2QgZrDa4_CrPWF5PKh6X9zo3_7+VfHnQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:25 UTC