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

[CSSWG] Minutes Seoul F2F 2014-05-19 Part I: Flexbox

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 8 Jun 2014 19:30:19 -0400
Message-ID: <CADhPm3sGynR54XNjV45QSptY6M0yt9qDUBQYd9hNBkXUzDJBsw@mail.gmail.com>
To: www-style@w3.org

  - RESOLVED: Close issue on whether 'flex-basis: auto' should resolve
              at computed value time. Clarify that the flex-basis auto
              flips to width/height at used value time.

  - The flex resolution algorithm has been redrafted since the LCWD to
    be closer to the structure of the earlier CR draft while preserving
    the changes to handle flex values continuously approaching zero.
    (Various technical errors reported in the LCWD have also been fixed.)
    The editors are requesting review from those interested.

  - Some concerns about handling the static positions of absolutely-positioned
    child of were discussed:
      - The group basically agreed to switch the flexbox/grid static position
        model to match a 0x0 static position placeholder box, but then also
        define that, depending on the alignment properties, the abspos child
        aligns relative to its static position differently.
      - This should give the same layout results as what's in the spec
right now.
      - A final resolution was held off until a decision could be made if the
        start point should be a box or a point.


  Bruno Abinader
  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Adenilson Cavalcanti
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Dongwoo Joshua Im
  Koji Ishii
  Dael Jackson
  Philippe Le Hegaret
  Chris Lilley
  Peter Linss
  Shinyu Murakami
  Edward O'Connor
  Simon Pieters
  Liam Quin (phone only)
  Andrey Rybka
  Simon Sapin (phone only)
  Dirk Schulze (phone only)
  Alan Stearns
  Shane Stevens
  Jet Villegas
  Steve Zilles (phone only)
  5 observers in the back

  Anton Prowse
  Lea Verou

Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: Dael


  This discussion to set the agenda held no technical details.
  Please see the IRC log for full minutes:


  glazou: Let's start with flexbox
  TabAtkins: Okay.
  <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325

  TabAtkins: So fantasai do we have anything except auto?
  fantasai: We got a few comments this week, but they're editorial.
  fantasai: We can't do CR right now, but we do have the issue of
            the computation of auto.
  TabAtkins: Let's do that one quick.
  <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-13
  <TabAtkins> http://dev.w3.org/csswg/css-flexbox/#flex-basis-property

  TabAtkins: 'flex-basis: auto' is confusing right now.
  TabAtkins: If auto is the specified value of flex-basis it means you
             use the size property (width/height) in that dimension.
             Question is when it turns into that value because it needs
             to do that to compute.
  TabAtkins: Right now it's not very clear.
  TabAtkins: I proposed we should change so it transforms at computed
             value time.
  TabAtkins: So a 'flex-basis: auto' would become the appropriate
             width/height value, but the confusing bit is that that
             could also be 'auto'.

  fantasai: We discussed this two years ago.
  fantasai: We concluded that because auto means two things, if flex-basis
            is inherited we get odd behavior.
  fantasai: If you inherit the 'auto' keyword from your parent,
            you don't necessarily get 'auto' behavior -- you get whatever
            is specified for your width/height property.
  fantasai: But 'flex-basis' is a non-inherited property. Practically no one
            except QA is going to inherit 'flex-basis'.
  fantasai: So in theory confusing, but the lack of resolution for
            getComputedStyle is probably more confusing.

  dbaron: Does resolution of inheritance happen prior to the computation phase?
  TabAtkins: Yes. Similar to cascade.
  dbaron: I've always thought that was wrong and it's not how we implemented.
  fantasai: So do we need to fix cascade?
  dbaron: I think that while there are two ways to explain it, it doesn't
          matter as long as any computed value computed to itself.
  dbaron: Now we're making that not true. So now location in cascade
          matters, which means implementations might not match since they
          assumed equivalence.
  TabAtkins: So you're saying you processed at value computation.
  dbaron: Yes. I don't know if that's what other implementors do and
          I don't know how to test for it in a black box.
  TabAtkins: Shane says he thinks they have the same implementation.
  TabAtkins: We can change cascade.

  dbaron: Testing is worthwhile.
  TabAtkins: But you say it's not detectable except with flex.
  dbaron: Implementors might have to change their cascade to deal
          with it.
  fantasai: Before we have a used value of flex-basis.
  TabAtkins: It wasn't stated, but implied.
  TabAtkins: We want to do it at computed time so it's right.
  TabAtkins: We can still decide this independently.

  dbaron: It's odd for other reasons.
  TabAtkins: You can't feed GCS into style immediately
  TabAtkins: But we can't change that now. I made that mistake years
  fantasai: Or we leave things as is.
  TabAtkins: Once we get usedStyle...

  TabAtkins: So are we okay with that weirdness of setting to
             computed value?
  dbaron: I'd prefer a used value time thing.
  TabAtkins: Is it okay for use to resolve to an end value?
  dbaron: How would that happen?
  TabAtkins: I guess it would resolve to used value of width
  TabAtkins: That's probably ok.
  zcorpan: I didn't follow what you said
  TabAtkins: We can't change the name of flex-basis auto value
  zcorpan: But you can change behavior.
  TabAtkins: Yes.
  TabAtkins: I was wanting to keep things that went to length to be
             at computed value time, but it's not huge.

  fantasai: So close no change?
  TabAtkins: Well, close and actually specify that flex-basis is
             resolved at used value time.
  fantasai: Close, clarify, no change.
  TabAtkins: Yep.
  TabAtkins: That's acceptable to me.
  TabAtkins: We're good. So the proposed resolution would be close
             this, spec properly that the flex-basis auto flips to
             width/height at used value time.
  glazou: Any objections?

  RESOLVED: Close issue, spec properly that the flex-basis auto
            flips to width/height at used value time

  glazou: Next issue?

  fantasai: There's one from Greg Whitworth that we have to think
  fantasai: The rest is editorial.
  TabAtkins: Greg posted one that we didn't get to that we'll have
             to work on tonight.

  TabAtkins: I'd like to discuss the algorithm changes.
  TabAtkins: The only major change since CR was...I said at last F2F
             I wanted to change the algorithm so that as the value
             approached 0 it was nice.
  TabAtkins: It ended up being a bit of a rewrite, and recently
             dholbert came up with a way to have the same effect,
            but in a way that's closer to the original language.
  TabAtkins: I think it's right, but if anyone is interested in
             algorithms please make sure that it maintains proper
  TabAtkins: That's the only issue left. I have both versions in
             spec and flagged. We're trying to switch to the CR
  TabAtkins: It looks like the old one, but approaches 0 properly.
  fantasai: We folded the changes from the LC comments into both versions.

  dbaron: This confuses me because you're talking about CR predating
  TabAtkins: We're trying to go for 9.7.2, it should be equivalent
             to 9.7.1
  TabAtkins: We need to address Greg's issue tonight and make
             editorial changes. I think we can ask for CR tomorrow.
  TabAtkins: I think that's all on Flexbox right now.
  glazou: Okay.
  glazou: We'll move to transitions.

  Rossen: One question. Where did we leave auto for absolutes?
  TabAtkins: Would you like to discuss that? It's no change.
  Rossen: It's still open on the list. We can do it now or just us
          discuss it later.
  TabAtkins: Let's do it here.

  TabAtkins: Right now we have spec that grid and flex are similar
             for static positions of absolutely positioned child of
  TabAtkins: The model now is you act as if the abspos is the only
             child, and where it goes according to the alignment
             properties is the static position.
  TabAtkins: If you set self-justify: center you'll have a thing
             where the abspos is centered in the flex container.
  TabAtkins: Rossen said that was confusing since you're not
             getting size from the flex container.
  TabAtkins: He thinks that should only apply if the flex container
             is the containing block for the abspos.
  TabAtkins: I don't have strong option, but I'm okay if we make
             this work in the containing block case, but I also
             don't have the problem with the existing.

  fantasai: I prefer that the static position be the same calculation
            for all children of the flex container, regardless of whether
            their containing block is the flex container or some other
  fantasai: Everywhere else if you compute static position of an abspos,
            that's the position regardless of containing block.
  fantasai: I want the static position of the item to not depend on
            what its containing block is (like everywhere else).
  fantasai: If we do this, we have to calculate different ways, depending.
  fantasai: I don't think that's a good inconsistency.

  Rossen: I agree. I don't want something different based on the
          containing block.
  Rossen: This is what was introduced in grid first. When we did it
          we wanted to align grid items in grid.
  Rossen: However, that was only abspos items in the grid, with the
          grid as the containing block.
  Rossen: That kind of violated the rule fantasai stated.
  Rossen: Basically, the problem is with abspos layout, you compute
          the static position where the element's natural position
          would have been.
  Rossen: Then the participation of the element is done and you
          don't need to reconsider its hypothetical position.
  Rossen: Once you're in the abspos's containing block, you figure
          out where the item will be and then you size the item.
  Rossen: The problem with the way we have spec'ed auto position,
          you have to go back and fudge with static position to
          make it work so item appears centered in the flex box.
  Rossen: Even though the position between flex and the item is
  Rossen: What we wanted to propose is to not find the static
          position, but to find where the static position applies.
  Rossen: So instead of static as the origin you can say it in
          relation to the box.
  Rossen: So you can work around the static position and center
          around it.
  Rossen: Instead of, after you've computed, reverse engineering
          the position.
  Rossen: When I mentioned this on the mailing list, I said we
          should do this in position spec.

  fantasai: So, you (Rossen) conceive of static position as a point
            to which the abspos start, start corner is attached.
  Rossen: Isn't it?
  fantasai: In the other models you don't do it that way. It's a box,
            not a point.
  fantasai: So you say static position is start, start and you have
            a small abspos wrt its container. It's aligned inside the
            box in the start-start corner. Fine.
  fantasai: But if you align the item to the center, it won't be centered;
            and if you align it to the end it will hang outside the box.
            This is asymmetric and won't be useful.
  fantasai: It would be better if alignment kept the item inside the

  dbaron: I think Rossen is describing a different way to get the
          same result.
  dbaron: I'm skeptical about this in the whole, and want to know
          about use cases.
  TabAtkins: Largely it's so that you can achieve centering with
  TabAtkins: Treating static more naively, it seems dumb. It's not
             what you would want in any case.
  TabAtkins: If you say just container center and it only uses that
             and goes to the side, it sounds stupid
  TabAtkins: In terms of author expectations, this is better.

  <dbaron> I'd be happy with just start, start corner.
  fantasai: If we want to do dumb, then just use the start, start corner.
  fantasai: This is trying to make it smarter, but ends up weird and not useful.
  fantasai: Either we should do something useful, or we should do
            something dumb and predictably useless.
  fantasai: Trying to make it kinda smart but failing to be useful,
            is not useful.

  dbaron: I'm okay with start, start corner.
  dbaron: This is a lot of code, but right now you have the flexbox
          model and you can escape into the old model, oh, and you
          can overlap your content.
  TabAtkins: Okay.
  dbaron: Is the disagreement the way to formulate?
  TabAtkins: I think so. I think his code assumes a simpler order.
             Rossen's ultimate model let's us position static
             naively and end in the right place
  dbaron: You may see static pos computation as a separate thing
          that can happen later.
  dbaron: I'm happy with Rossen's since it might be easier to
  TabAtkins: The only things that play off are realpos, which isn't
             a thing.
  TabAtkins: It shouldn't have any detectable differences...
  dbaron: Famous last words.

  fantasai: I think if you want to compute static position, that if
            you store it, instead of a point, store as a box.
  Rossen: What's the relation between that and the box?
  fantasai: You store as a rectangle so in the case of most things
            it's a 0 height, but depending on if you are, it'll be
            that or the size of the 0 height.
  fantasai: Then it'll happen at the time of positioning. For flex
            it would be a flex container.
  dbaron: I don't think it makes sense as a rectangle
  dbaron: To fit into existing method you want an x coordinate and
          left-right-center alignment and a y coordinate with top-
          center-bottom alignment.
  Rossen: Which is what we did in grid.

  TabAtkins: Was this originally in grid and we changed it?
  TabAtkins: Are we okay with reformulating in those terms, assuming
             positioning will do this process later and better?
  fantasai: Can we discuss the rectangle later, with a white board?
  TabAtkins: Yes.

  Rossen: When you start counting all the modes you'll have fun
          with a rectangle. As an implementor I promise that a
          point will be conceptually easier.
  Rossen: I'm sure with a white board we can solve this in a few

  TabAtkins: So for now let's resolve for what Rossen said.
  fantasai: I don't want center and off to the side stuff.
  Rossen: Let me repeat.
  TabAtkins: Rossen wants identical behavior in a different way.
  TabAtkins: Let me write out this resolution.
  <TabAtkins> Proposed resolution: Switch the flexbox/grid abspos
              model to be more naive, just positioning a 0x0 box as
              currently specified, but then also define that, based
              on alignment, the abspos child aligns relative to its
              static position differently. Same layout results
              should be achieved.
  <TabAtkins> Such that "justify-content: center" puts the static
              pos in the center of the flexbox, and the abspos
              aligns its *center* with the static pos, rather than
              its start edge.
  TabAtkins: Okay.
  TabAtkins: Rossen is that right?
  Rossen: Yep.

  fantasai: So maybe we have both models in the spec, one as a note
            so people can think about it.
  fantasai: I think for authors it would be easier to talk about
            aligning the abspos within the box, but for implementors
            we can formulate in terms of static position point.
  TabAtkins: So. That sound fine for now?
  Rossen: For now. I think we're going in the right direction.
  TabAtkins: Now we can do transforms.
Received on Sunday, 8 June 2014 23:30:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:43 UTC