W3C home > Mailing lists > Public > www-style@w3.org > May 2012

[CSSWG] Minutes and Resolutions Hamburg F2F 2012-05-10 Part I: Flexbox

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 15 May 2012 07:07:55 -0700
Message-ID: <4FB2633B.5050703@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Flexbox: Box Construction

   - RESOLVED: Don't create anonymous flexbox items that are only whitespace.
   - RESOLVED: 'visibility: collapse' flex-item stays in box tree, but has
               special layout: Do layout once normally, then collapse it to
               a strut of its line's cross size and lay out again. (This
               keeps the cross-size stable if the flexbox is single-line or
               a single line of multi-line.)

Flexbox: Flex Property

   - RESOLVED: Split flex into flex-grow/flex-shrink/flex-basis
   - RESOLVED: box-sizing affects flex-basis
   - RESOLVED: use flex-basis for sizing flex items, even inflexible ones
   - RESOLVED: flex items are flexible by default
   - RESOLVED: on flex items flex-basis of 'auto' computes to computed
               width/height (as appropriate); on elements that are not
               flex-items, it always computes to 'auto'

Flexbox: Flex/Cross Sizing

   - RESOLVED: accept Alex's new formulation for negative flexibility
   - RESOLVED: Negative flexibility is 1 by default
   - RESOLVED: add 'auto' keyword as initial value of min-width/height;
               on CSS2.1 display types it computes to zero;
               on flex items it is treated as min-content
   - RESOLVED: For cross-sizing of a flex line, adopt proposal C in

Flexbox: Pagination

   - RESOLVED: break-before/after: always triggers a flex-line break,
               and all values that trigger fragmentation on an item in
               a row flexbox get propagated to the flex line
   - RESOLVED: make page-breaking algorithms for flexbox informative,
               as an example; UAs can do better

Flexbox: Terminology

   - RESOLVED: rename display:flexbox to display:flex
   - RESOLVED: change spec terminology from "flexbox" to "flex container",
               and "flexbox item" to "flex item"

====== Full minutes below ======

   Glenn Adams
   Ren Ando
   Tab Atkins
   David Baron
   Bert Bos
   Rik Cabanier
   John Daggett
   Alex Danilo
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Arno Gourdol
   Vincent Hardy
   Daniel Holbert (Mozilla) (morning, via phone + IRC)
   Koji Ishii
   Håkon Wium Lie
   Peter Linss
   Alex Mogilevsky (morning, via phone + IRC)
   Edward O'Connor
   Florian Rivoal
   Dirk Schulze
   Alan Stearns
   Shane Stevens
   Liam Quin (W3C)
   Jet Villegas
   Steve Zilles

Flexbox: Box Construction
Scribe: dbaron

   <fantasai> http://wiki.csswg.org/spec/css3-flexbox
   fantasai: I broke this up into topics.
   fantasai: First topic is box construction for flexboxes.

   fantasai: First issue is whether pre white-space is preserved or ignored
             between elements.
   <fantasai> http://www.w3.org/mid/4F6ACDF3.1030706@mozilla.com
   fantasai: Similar to issue with tables: do we do wrapping for preserved
             whitespace between cells?
   fantasai: Wasn't too much of a conclusion from www-style thread.
   tab: Brad said he might have wanted to preserve whitespace; then I
        explained how that was kind of crazy.
   tab: I think we should do what tables do: if there's significant preserved
        whitespace, then it's wrapped in an inline and wrapped in a cell.
   fantasai: No, it goes away.
   tab: Oh, right, tables always drop the whitespace.
   <fantasai> http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes
   tab: Kenny says a stretch of whitespace should never generate an anonymous
        flexbox item, and this is consistent w/ how tables work.
   (quoting www-style/2012Mar/0521.html)
   <fantasai> http://www.w3.org/mid/4F6ACDF3.1030706@mozilla.com
   <alexmog> sounds fine
   tab: So if nobody objects to dropping ws that occurs between items...?
   dholbert: So dropping ws between items is a little different from what spec
             now says:  only drop if it's all whitespace, but follow normal
             rules at the edges of flexbox items if they're not all whitespace.
   tab: Yeah, that's what the spec currently recommends.
   <fantasai> "If a box B is an anonymous inline containing only white space,
               and is between two immediate siblings each of which is either
               an internal table box or a 'table-caption' box then B is treated
               as if it had 'display: none'. "
   <fantasai> -- CSS2.1
   RESOLVED: Don't create anonymous flexbox items that are only whitespace.

   fantasai: Next issue is magic behavior of display:inline elements
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0250.html
   fantasai: Spec now says anonymous flex item is wrapped around non-atomic
             inline content.
   tab: replaced elements don't get wrapped
   fantasai: so you can have an element that is display:inline that becomes
             a flexbox item on its own because it's replaced
   fantasai: Advantage is that the parent of a bunch of buttons or images
             is a flexbox, all children are individual items.
   fantasai: Disadvantage is that you can't tell from computed values whether
             something will be a replaced element. (e.g., img, object)
   fantasai: This has an impact on "can we compute various values?", e.g.,
             a display-outside property computing to flexbox-item.  Can't do
             that if it depends on if you loaded content.
   fantasai: Other problem is on the usability side:  with a bunch of images,
             if the images don't load, you end up with one big item instead
   SteveZ: Since the intent was a replaced item, and it didn't load for some
           reason -- why not have it just keep behaving like a replaced item
           and have the fallback be text?
   fantasai: Experience reader should get is that you get the fallback content
             and not notice there's something missing.
   Florian: I think it should only depend on what the display value is.
   SteveZ: If I'm doing fallbacks for a11y, I'd like the buttons to still be
   Tab: But by default buttons are display:inline
   Tab: We should have made a bunch of these things display:inline-block by
        default in the HTML style sheet, but didn't.
   * fantasai actually disagrees on that point
   Tab: I don't think replaced-ness is a thing we can look at.
   Tab: Making it stay an atomic inline means that in some of the fallback
        cases, you won't get text wrapping across lines (e.g., of alt text).
   dbaron: I guess I'm not that worried about dependency on replacedness
           from technical perspective
   dbaron: more worried about weirdness of .. difference in behavior btw
           having an image in the middle of some text
   dbaron: vs. an inline in the middle of some text
   Tab: if you're trying to guess, like we are right now
   Tab: if you had a flexbox with 3 items: text, image, text, you get 3
        flexbox items
   Tab: if we're not smart about it, then you get one item
   Tab: But then if you fill the flexbox with buttons or images, they won't flex
   Tab: If you fill the flexbox with text directly, that's not really a good
        use case
   Alex: I'd like to get back to reason for this rule.
   Alex: We have this rule because buttons (e.g.) not being flexbox items
         is a really big problem.
   Alex: Whatever happens to ... inlines, should ... for anonymous flexbox items.
   Alex: We're trying to do something reasonable for ... markup so people
         won't lose content.
   Alex: We're not going to optimize for anonymous inline-level content in flexbox.
   Alex: We're trying to come up with a reasonable rule that makes controls
         flexbox items and not be too special.
   fantasai: So the basic problem Alex describes is that when an author puts a
             flexbox around a bunch of buttons or images, they expect those
             things to flex.
   fantasai: So the goal of this magic behavior for replaced elements is to
             deal with that surprise.
   Alex: ... compromise that we got.
   Alex: Anything with display:inline-block ... not ... value of properties...
         including images and controls.  These should be flexbox items.
   tab: Still reasonable for images and buttons to work as they do now.
   fantasai: I think the behavior is reasonable, except in the case where
             the element is no longer replaced.
   tab: So we want to track replacedness.
   fantasai: No, we should track whether the author expected it to be replaced.
   fantasai: That's a lot of magic.
   dbaron: I think I'm a little worried about that sort of magic in the case
           that maybe certain specs like HTML get extended in such a way that
           a lot of elements could potentially be a replaced element
   szilles: So why not list the elements that should behave that way
   glazou: 'content' can turn anything into a replaced element
   tab: I wouldn't be sad if an inline with 'content' worked wrong in flexbox --
        you should need to set it to inline-block
   sgalineau: ... shadow dom ...?
   sgalineau: If you make your own control with the shadow dom?
   tab: Set it to inline-block.

   Bert: how I *do* get an IMG to be inline:
         <DIV.flexbox><DIV.flexbox>...inline... <IMG>... inline</></>
   Bert: How can I avoid this?
   tab: wrap it in a span
   fantasai: In most cases you're not going to take a bunch of inline content
             and use flexbox.
   Bert: Say I have table markup and want to lay it out with flexbox instead.
   Bert: So I make the table, tr, td flexbox
   fantasai: Just make the table and tr flexbox containers, but *don't* make
             the td flexbox container; it becomes a flexbox item.
   Tab: Just make it display:block or display:inline-block
   Tab: You want table, tr { display: flexbox } td { display: block }
   Tab: Your row is the flexbox, the cells become items, anything inside
        the cells is irrelevant.
   SteveZ: The children of a flexbox are items.
   fantasai: Anything with display != inline automatically gets an effective
   Bert: We're missing something to turn something into a flex-item
   Tab: There aren't use cases for having that value
   glazou: Not only that, there's no concept of having a child of a flexbox
           container not being a flexbox item.  It's not meaningful.
   Bert: Why isn't the block being wrapped in anonymous flexbox item?
   SteveZ: You want the flexing on the block to flex.
   Tab: [explains model again]
   glazou: So, Bert, what do you want if first two cells are set to
           display:flex-item and third is display:block?
   Bert: Then the third gets wrapped in an anonymous flex item.
   Bert: <div> flexbox
   If I turn span from inline into block, I still want this stuff to be
      a single item.
   Tab: That's not doable.
   Bert: If this were a table and a cell, I could do this.
   vhardy: I can see Bert's point that we have a different behavior between
           flexboxes and tables.
   Tab: If we did flexbox-item, then the default case wouldn't work well.
   SteveZ: Tables require a td, this doesn't require a flexbox item.
   SteveZ: Typical use case for flexbox wants to not require equivalent of td.
   fantasai: ...
   Bert: You can just use display: flexbox for both
   fantasai, steve, glazou: no, you can't, container and item are different

   fantasai: Flexbox automatically promotes other values into
             display-outside: flex-item.  I think that's fine.
             The only thing I have a problem with is behavior of things
             like img or object depending on whether the resource loads.
   Tab: Eventually we can solve Bert's case with an ability to wrap arbitrary
        things with a pseudo-element.
   Bert: What's the difference between a flexbox with a single item and a block?
   Tab: I'm confused about what we're still talking about.
   Bert: ... don't need special behavior for images
   Tab: People expect to be able to fill a flexbox with images.

   fantasai: [draws]
   fantasai: So the issue is <div flexbox> <img> <img> <img> </div>
   fantasai: When the images load I get 3 flex items, but if images don't load...
   fantasai: <div flexbox> <img alt=foo> <img alt=bar> <img alt=baz> </div>
   fantasai: I just get one item with "foo bar baz".
   Florian: Agree this is a problem.  Whether we pick the first always or
            second always is secondary.
   vhardy: Could we have a ... ?
   fantasai: Is an image an element that is replaced, or is an image an IMG
             element (special-case rules for HTML)?
   SteveZ: I thought modulo David's comment that we agree the intent is that
           if user intended it to be replaced, it should keep behaving like
           it's replaced.
   dbaron: Just say "if it's replaced or attempted to load a resource that
           would have caused it to be replaced"
   Tab: Just working around bug of display:inline rather than inline-block
   fantasai: You can get the behavior you want by setting 'display: inline-block'
              or 'display: block' on the items.
   glazou: [says something]
   SteveZ: I think there's a magic property attached to items that says it
           stays atomic if the alt text shows up.
   fantasai: That's display:inline-block
   SteveZ: No, more magic than that.
   SteveZ: If things in future of HTML get ...
   fantasai: Then default style sheet could make them display: inline-block
   fantasai: Right now img is display:inline
   SteveZ: Only want this to happen in the context of a flexbox
   fantasai: So you want 'display: inline-block-if-parent-is-flexbox'?
   Tab: We know what we want to do
   Tab: I think we should resolve that all HTML replaced elements work even
        if they don't load.
   fantasai: It matters how, we need to discuss this.
   Tab: If we can't figure it out tonight, we can bring it up again tomorrow.
   resolution???: We want replaced elements that are children of a flexbox
                  to always be flexbox items, even when the resource they're
                  trying to load doesn't load.

   glazou: Do you need ability to put first 2 images in one flex item and
           third in its own?
   dbaron: Put first 2 in a container?
   SteveZ: Could have a property called flex-atomic.
   Tab: And that's acceptable to do later.
   Bert: But it's easier to say inline elements don't turn into flex items.
   Tab: Bert, what you're objecting to is what most authors want based on
        existing usage.
   fantasai: Have all child elements turn into flex items?
   tab: I'd rather have text-inline-text not be broken
   <dholbert> fantasai, your proposal would make
              <div style="display:flexbox">text followed by <i>italics</i></div>
              weird (the <i> would become its own item)
   <fantasai> yeah, but the argument is that isn't a good use case
   Straw poll: (a) accept behavior Tab wants or (b) continue discussion
   <fantasai> I don't know what a) is, because "wanted to be a replaced
              element" is not defined
   vhardy: a
   alexd: a
   glenn: abstain
   jdaggett: abst
   dbaron: a
   ted: a
   arno: abst
   dirk: abst
   alan stearns: a
   fantasai: Tab's proposal isn't defined, how can I vote for or against it?
   shane: a
   sylvain: a
   ren: abst
   steve: a
   rik: abst
   glazou: a
   florian: a
   a a abstain abstain
   Bert: same as fantasai
   jet: a
   howcome: same as bert
   CONCLUSION: Let tab propose something and we'll discuss his proposal.

   Next Issue: What are expected display-inside/display-outside values
               for flex items, and does currently-defined behavior result
               in a sensible model when they are defined to exist?
   tab: Intention is that if we introduce display-inside/outside, intention
        is that when that happens flex items will get a computed
        display-outside of flex-item
   tab: This means that the serialized computed value of display will in
        future change for flex items from "block" to "flex-item block"
   tab: I think it'll probably be fine, so not something we need to worry
        about now.
   (Wanted to bring it up in case anyone had any concerns.)
   florian: fine by me
   vhardy: Is the plan to have computed value of display be display-inline,
           display-outside, or both?
   tab: serialization produces the old value when there's an old value that
        matches the pair
   dbaron: general rule that serialization produces shorter value
   Bert: So you're proposing value of display-outside depends on parent
   fantasai: We have a similar case for the root element.
   fantasai: We also do this for text-align: match-parent in css3-text
   fantasai: ...
   Bert: Ah, I think it's ok if only the computed value changes.

   Next Issue: Effect of 'visibility: collapse' on flex items.
     * Proposal A: Stays in box tree, but has special layout:
         Do layout once normally, then collapse it to a strut of its
         line's cross size and lay out again. (This keeps the cross-size
         stable if the flexbox is single-line or a single line of multi-line.)
     * Proposal B: Stays in box tree, but removes all impact on layout,
         period. (Just like display:none, but still generates boxes, so
         animations/counters/etc are unaffected.)
     * Proposal C: ???
   Tab: So, the effect of visibility:collapse on flex items.
   Tab: visibility:collapse is generally useless, but has special behavior
        for table rows/columns
   fantasai: The goal was to allow dynamic expansion/collapsing
   <alexmog> didn't we discuss and resolve this before?
   tab: without introducing relayout jitter
   <alexmog> as "collapse doesn't do anything special in flexbox"?
   fantasai: The goal is that thing with visibility:collapse should disappear
             from layout but still influence surrounding content
   fantasai: e.g., disclosure element
   fantasai: this is goal... visibility:collapse does bad job of solving this.
             A little weird inside tables, and outside tables behaves like
   fantasai: There was a thread on what collapse should do for flexbox.
   fantasai: I think could say it doesn't impact layout but still in the
             tree for animations/counters.
   fantasai: Could collapse in main axis but still affect cross size of
             flexbox. (A)
   SteveZ: So like having a strut in the cross direction
   fantasai: alternatively, like display:none but still in the box tree (B)
   tab: A better display:none that doesn't turn off animations
   fantasai: so timeline is still running while it's not displayed
   florian: question about having it still affect cross axis... can we
            always know without having it do layout in the other direction?
   fantasai: Would need to layout (a) once with all the elements there
             including those that are collapsed to figure out the strut
             sizes and (b) again with them gone
   Florian: Seems like keeping the cross-axis strut is more likely what
            you want, but haven't thought about it much
   Tab: You could, e.g. have a menu-bar across the top of the page, some
        items one line others two, don't want the height to jiggle when
        you collapse a two-line item
   dbaron: Not sure that works the way you want
   dbaron: you will get jiggling, because if you collapse a one-line item
           so there's enough room for 2-line to be 1-line, then it'll still
   Tab: No, the strut is the height as 2-line
   dbaron: ok
   dbaron: I don't think it's a good idea to introduce a general collapsing
           behavior for new layout modes
   dbaron: I'm ok with the strut thing
   dbaron: I think the no-strut-but-like-display-none is not something we
           should do in Flexbox, b/c if we want that mode we should have
           it for everything
   szilles: I understand how this works for a 1-line flexbox, don't see
            how to do a multiline flexbox
   Tab: Correct, we can't.
   Tab: thought about this
   Tab: Should work as intended for single-line multi-line flexbox
   Tab: Collapsing an element would change line-wrapping, otherwise
        with multi-line it can cause really bad behavior like completely
        empty lines, extra space
   Tab: It's still useful, take e.g. your toolbar at the top of the screen
   Tab: under normal screen widths it's a single line
   Tab: But you set wrap on it so that on narrow screens it's 2-line
   Tab: you lose the ability to have stable height, but it's compact
   fantasai: If you rewrap as result of a lot of stuff collapsing then
             it will collapse the height as well.
   Steve: Compute height of strut as if laid out all on one very long line.
   fantasai: Except now each line is independently sized
   fantasai: If flexbox had consistent height per line across entire
             flexbox then that would make sense.
   tab: That would be less than ideal... baseline alignment can produce
        different line-heights
   dbaron: Could mean that if you collapse something it increases height
           of line
   Steve: If became important, could introduce a property saying max, so
          collapsing behavior would do right thing.
   SteveZ: property would say use max height for all lines
   Tab: Seems like something we could do in future.
   <dholbert> yes
   Steve: possible desire for strut behavior
   Steve: known to only work well with single line
   Tab: As long as Alex and Daniel are ok with it I'd like to resolve on
        proposal (a) that collapsed items create a strut
   dholbert: sounds ok to me
   alexmog: seems expensive.  Do you really want that?
   tab: only if things are visibility:collapse
   alexmog: ...
   Tab: yes
   RESOLVED: 'visibility: collapse' flex-item stays in box tree, but has
             special layout: Do layout once normally, then collapse it to
             a strut of its line's cross size and lay out again. (This
             keeps the cross-size stable if the flexbox is single-line or
             a single line of multi-line.)
   <br duration="10m" />

Flexbox: Flex Property and Flex Sizing
Scribe: fantasai

   Next Issue: Split flex as shorthand of flex-grow/flex-shrink/flex-basis
   Tab: First issue is, Alex wanted to split flex property into a shorthand
   Tab: It took 3 components, now we have longhands for them
   dholbert: I haven't done that yet, but think it's reasonable
   Tab: We made flex-grow and flex-shrink default to 1, and flex-basis
        default to 'auto'
   Tab: But there's special behavior in the shorthand: if you leave out
        flex-basis, it defaults to '0px' rather than 'auto' (which is the
        initial value)
   Tab: This is so that flex: 1; continues to do absolute flex
   fantasai: Are we happy with splitting flex into the three properties?
   RESOLVED: Split flex into flex-grow/flex-shrink/flex-basis

   Next Issue: Does box-sizing affect flex-basis?
   fantasai: Next question on box-sizing, how does it interact with flex-basis?
   fantasai: If you set a 'width' or a 'height', 'box-sizing' indicates
             whether that's content-box, padding-box, or border-box.
   fantasai: Question is:  does that also affect flex-basis?
   fantasai, tab: I think it's clear it should be yes.
   dbaron: So flex-basis defaults to auto?
   Tab: initial value is auto, but in a lot of cases it will become zero
   RESOLVED: box-sizing affects flex-basis

   Next Issue: Applicability of flex-basis: is it used or ignored for flex == 0?
   fantasai: next issue is, if the flex item inflexible, do we still use
             flex-basis, or do we just use width/height
   Tab: Reason we defined flex-basis is b/c the direction you want is the
        main dimension, which could be either width or height
   Tab: There's an argument that if you're inflexible, you don't need to
        care about flex-basis
   szilles: Seems more confusing from user POV
   szilles: Seems it would be better if you always used basis when you're
            in a flex
   Alex: I don't see any reason for doing anything differently if flexibility
         is zero
   RESOLVED: use flex-basis, even when flexibility is zero

   Next Issue: Default flexibility of flex items: flexible or inflexible?
   Note: This decision sets the initial values of flex-grow and flex-shrink,
         which conventionally also implies their default values in the
         flex shorthand.
   Tab: default flexibility of flex items -- are they flexible or inflexible?
   Tab: Right now default says flexible and auto-sized (i.e. use width/height
        value as appropriate)
   Tab: I think this is the best option given how the shorthand works
   szilles: Why are you putting them in a flexbox if not to flex them?
   Tab: maybe you want reordering or alignment controls from flexbox
   dbaron: what's the default amount of flex?
   tab: 1
   dbaron: And flex takes floats?
   Tab: yes
   Bert: do you need more than one level of flex?
   Tab: There's only one right now, but you could add others later
   Bert: Why is it not a boolean?
   Tab: Oh, if you have 2 items and you have 1 and 2 flex values, the
        second will be twice as big as the first
   Bert: I would have kept ordinal group rather than flex
   Tab: could approximate wrt orders of magnitude
   Alex: I'm a little concerned about this, have some experience with not
         flexible by default
   Alex: Don't have any experience with flexible by default
   Alex: It's probably good
   fantasai: It's easy to turn off, just set "flex: none"
   fantasai: (Now default is "flex: auto")
   Alex: one point is that flexbox is even closer to other kinds of containers
   Alex: Everything gets max-content if they're size auto and flex is zero,
         and these are defaults
   Alex: our default is flex: 1, then content actually sizes to flexbox
   * fantasai confused
   Tab: so, is that objecting or agreeing?
   Alex: Have a concern, but no particular reason for the concern
   Alex: I am more default being flexible than not
   dbaron: I feel like there are a bunch of use cases where you want to use
           a flex box b/c want a bunch of things, and want one of them to
           flex and rest of them not to
   Tab: Just a bit more work, have to set flex: none on all the items
   dbaron: is it more common to do flexible or inflexible?
   depends on what you're doing
   dbaron: ... I'm ok with it
   RESOLVED: items are flexible by default

   alex: Issue - if you set 'flex: <number>', it sets negative flexibility
         to its default. Should it set both?
   fantasai: negative flexibility ... usually want item that grows fastest
             not to shrink fastest
   alex: ...
   Tab: Right now, because of shorthand behavior, negative flex defaults
        to one...
   alex: flex: 0 means positive flexibility of zero, but negative flex of one
   fantasai: yeah, that's odd, but you should just set 'flex: none', not
             'flex: 0'
   Tab: Given we have 'none', I'm ok with flex: 0;
   alex: flex: 0 100px will allow shrinking
   fantasai: let's return to this after talking about negative flex

   next issue -
   Tab: If you set flex-basis to auto, does it compute to the basis or does
        it just resolve at layout time?
   Tab: don't know what implementations do
   dholbert: For transitions and animations, I think it's best to compute
             to the actual length
   dholbert: though that's not how I implement it right now... but I think
             it's better to compute through
   Alex: what does it compute to for non flexbox-items?
   Tab, fantasai: hm, should compute to 'auto' on non flexbox-items
   Alex: Does it compute to the computed value or the used value of
   fantasai: CSS computed value, not DOM getComputedValue
   dholbert: One slightly odd case, what if actual computed value of width
             is 'auto'?
   Tab: That's fine, you just get 'auto' back
   RESOLVED: on flex items flex-basis of 'auto' computes to computed
             width/height (as appropriate); on elements that are not
             flex-items, it always computes to 'auto'

   Next Issue: Negative flex formulation
   Tab: Flexbox with 2 children, one small, one really big
   Tab: overflows, negative flex is allowed
   Tab: right now, take overflow amount as negative space, split evenly to
   Tab: small item shrinks to zero, rest of space shrinks other item
   Tab: This is bad -- small item just dies
   Tab: Alex proposes a division-based reduction for negative flexibility
   Tab: So these reduce by a ratio rather than absolute amount of the free
   Tab: effect of this should be that, instead of one's dead and other
        fills remaining space,
   Tab: you get something a little more proportional
   Tab: small items is still smaller, but has same proportion to big item
        as in unflexed situation
   Tab: haven't checked his math yet
   dbaron: what's default negative flexibility
   fantasai: that's a separate issue -- could default to either zero or 1
   dbaron: Normally in a situation like that, you'd have small item inflexible
   fantasai: but if you do negative flex everything, what does it do
   Tab: This compounds your flex basis into the formula
   Tab: It multiplies your basis by your negative flex, and this is how
        you distribute the negative space
   Tab works through the example with one box as 100px and the other at 900px
   dbaron: I'm ok with it
   Tab: Seems reasonable
   <dholbert> agreed
   dholbert: I think it sounds like a good proposal
   RESOLVED: accept Alex's new formulation for negative flexibility
   <tabatkins> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16856 comment 1 for the formulation

   Next Issue: Turn negative flex on by default (now that negative flexing
               makes sense…)
   [fantasai explains reasoning for turning negative flex on by default]
   dbaron: does negative flexing affect multiline flexbox?
   Tab: Only in the case that one single item overflows the box, in which
        case it pulls it back inside
   Tab: you line break first, then apply flex
   Alex: If you say 'flex: 0 auto', it will default flexibility to one
   fantasai: think we should optimize for the common cases, and setting
             flex-basis to a value other than auto or zero seems like
             uncommon case
   fantasai: if we really want to, we can make shorthand defaulting smarter
   Tab: e.g. if flex is set to zero, it sets both to zero
   * dholbert nope
   RESOLVED: Negative flexibility is 1 by default

   Alex's flex shorthand for negative flex issue continued...
   shorthand right now:
     - flex: none -> 0 0 auto
     - flex: auto -> 1 1 auto
     - flex: <number> -> <number> 1 0px
   Question is, what happens if flex: 0; or flex: 0 <size>;
   Option 0: negative flex defaults to 1
   Option 1: negative flex defaults to 0 in case of positive flex being
             set to 0
   fantasai: I'm ok with either
   dbaron: so if you have two integers, it sets positive and negative
   dbaron: if you have one integer, it sets positive, and question is what
           the default negative flex is
   * dholbert doesn't have a strong preference from an implementation
   Tab: yeah. We already have a special defaulting thing for flex-basis
        already (defaults to 0px in the case of a flex being present,
        despite auto being the initial value)
   dbaron: 'flex: 0', if you only do the one special case you mentioned,
           then the basis is 0px
   dbaron: if the basis defaults to 0px in the shorthand, then that's
           useless anyway
   dbaron: seems more reasonable to have defaulting for flex-basis, not
           the integers
   Tab: original goal was to have absolute flex easy, just specify a flex
   Tab: and to have relative flex easy: just set to auto
   dbaron: so if the author wants an inflexible size, they have to set
           'flex: 0 0 size'
   Tab: Yes, or set flex to none and use width/height
   Tab: which is preferred
   Bert: Why do we set flex-basis and not width/height?
   Tab: width/height is physical, flex is logical wrt flex flow
   fantasai: also it's confusing for people to set width/height to zero
             when they want a flex basis of zero, since they don't *want*
             the width to be zero
   Tab explains absolute vs. relative flex to Bert
   fantasai: There's two ways to do flex.
   fantasai: There's zero-based.
   fantasai: You have an element with three children, flexes set to 1, 1,
             and 2.
   fantasai: If flex-bases is 0, they'll become 1/4, 1/4, and 1/2,
             maintaining the specified ratios.
   fantasai: If I do a flex basis of auto, it means lay out the contents
   fantasai: So if one of them has a long word, and another has a short
   fantasai: You then figure out the *extra* space left over, and distribute
             that according to 1/4,1/4,1/2 and add it to the layout sizes.
   back to topic
   dbaron: Now that we just changed the way negative flex distribution
   dbaron: not sure I'm still convinced you don't want the negative and
           positive flexes to be the same
   fantasai: no, still do -- higher flex means it shrinks faster
   fantasai: don't want item that grows the fastest to shrink the fastest
   dbaron: Not convinced that the special case you're proposing for zero
           is particularly useful
   dbaron: Special case proposed for shorthand is that *if* positive flex
           defaults to zero, negative flex also defaults to zero, instead
           of defaulting to 1 like everywhere else
   fantasai: I'm ok with either way
   dbaron: I'm inclined not to do the special casing for 0
   dbaron: seems like one more thing that could confuse authors trying to
           learn how flexbox works, and doesn't feel all that useful
   dbaron: though if you have a strong feeling, I don't mind
   Tab: don't feel strongly either
   Alex: Unusual to have flexibility that's not one or zero, unless flex
         basis is zero (in which case you never "shrink" anyway)
   Alex: So could set both numbers to same thing
   Tab: No, I don't like that. Whole reason we split them out was so that
        item that grows fastest doesn't shrink fastest
   Tab: I'd be ok with not having the special case here.
   Tab: Have an authoring guideline that says to set width/height
   fantasai: Suggest we go with default as 1 for now, call out as an issue
             for feedback. We have two clear proposals, both are acceptable
             to everyone and we don't have strong opinions. If LC comments
             come back with more info or strong opinions, we can change.
   Alex: prefer to have a special case

   <Bert> (wild idea: make the default neg flex the inverse of the pos
           flex: X and 1/X..., except for 0, which becomes 0)
   fantasai: if you have bunch of flexboxes 100px flex basis, have flex
             of 1, 2, 3, and then shrink, what happens?
   fantasai: Would want to think about this, not sure it works...
   fantasai: suggest we defer this to tomorrow
   fantasai: Consider (a) defaulting behavior of negative flex in shorthand
             and (b) Bert's suggestion to invert negative flexes
   fantasai: Is that just a default shorthand behavior or the way negative
             flex works in general?

   Bert: one other issue: it doesn't say what a % on flex-basis means
   Tab: Just like normal layout
   dbaron: means the same as % on width or height?
   tab: yes
   Bert: In the property definition there is no percentage line
   Bert: The "Percentages" line; could just say "see text".
   dbaron: for flex-basis, not for shorthand flex
   ACTION Tab: fix flex-basis percentage line in propdef table
   <trackbot> Created ACTION-458

   Next Issue: Implied minimum size of flexbox items
   Tab: Flexbox sizing does pay attention to min/max constraints
   Tab: But min constraint defaults to zero
   Tab: This might not be ideal
   Tab: In other layout modes, might have other min-content sizing
   Tab: Tables for example floor at min-content
   Tab: Maybe we should do that as well
   Alex: If width is 'auto' and 'min-width: 0' , in that situation you'll
         have min-content as a minimum
   Tab: special case of those two values having those two values?
   Alex: yes
   fantasai: alternate proposal is to introduce 'auto' value as initial
             value of 'min-width/height'.
   fantasai: this can compute to '0' if we need to on non-flexbox-items
             (for back-compat), or not
   fantasai: but then flexbox items can look at the min size constraint,
             see that it's auto, and know that auto means use min-content
             as the minimum
   fantasai: authors can still turn that off by setting it explicitly to 0
   Florian: I think I like that
   Tab: Gives friendly default behavior, e.g. navigation bar with text,
        want each item to be at least as wide as a single word
   proposal is to add definition of min-width/height: auto to Flexbox,
            as described above
   fantasai: This lets us do similarly smart things for other layout modes
             as we add them, which is probably a good thing
   Florian: certainly less hacky than getting the behavior the way Alex
            was doing
   dbaron: This is compatible with Gecko flexbox
   dbaron: It doesn't let you go smaller than min-content
   dbaron: Gecko flexbox treats min-width: 0 as magic
   dbaron: So people using Gecko flexbox will use min-width: 1px when they
           want to go below intrinsic
   RESOLVED: add 'auto' keyword as initial value of min-width/height as
             described above

   fantasai: side-tangent -- do we want it to compute to auto on table cells?
   dbaron: would need to think about that
   Tab: we'll make it go to zero always now, and then if find a way to
        make it compatible, handle as LC comment

Flexbox: Pagination

   Next Issue: Propagating break-before/after to flex line instead of
               allowing items to break lines, but only in fragmenting
   Tab: multi-line row flexbox
   (tab is drawing an example)
   Tab: with stuff in it
   Tab: this is a tall thing, pagination is in play
   Tab: page line cuts right here or something
   fantasai explains the issue
   fantasai: The issue is, if you have page-break-before on the item in
             the middle of a line, and you honor it, it creates a line
             break in paged media, but not in continuous
   fantasai: Proposal is to propagate the break-before to the line box,
             so that you get equivalent line-breaking in all media
   dbaron: Do you have breaking of multiline column flexboxes?
   fantasai: yes, it's complicated, roughly like multi-col layout
   Bert: Sounds to me like that item wants to be on its own line
   fantasai: We could make break-before/after: always trigger breaks on
             flexbox lines
   fantasai: Other values of break (e.g. column/page/left/right) would
             still propagate to the line, but always would trigger a
             line break in all modes, and additionally a page break in
             paged mode
   howcome: wouldn't expect page breaking to be used much on flexbox
   Tab: but line breaking, definitely
   Tab: would be weird to say, you ignore page break controls in flexbox
   for no good reason
   fantasai: So proposal is break-before/after: always triggers a
             flex-line break, and all values that trigger fragmentation
             get propagated to the flex line
   RESOLVED: proposal accepted

   Tab: our paging algorithm right now is optimized for page-at-a-time layout
   fantasai: suggest we go to next issue, which is to make the paging
             algorithms informative
   Tab: We're not sure they're correct, and they're simplified, so we'll
        leave them in as implementation advice, but not normative
   Tab: Nobody has well-defined pagination yet, so not worse than other
        layout modes
   szilles: Make sure to note that doing better is acceptable and encouraged
   Tab: bullet points that say how to deal with break properties stay
   Tab: but actual rules for precisely how to do layout, become informative
   howcome: make it a subsection
   Tab: yeah
   RESOLVED: make page-breaking algorithms for flexbox informative, as an
             example, UAs can do better

Flexbox: Cross Sizing

   Tab: previously, there was a difference in cross-sizing for single-line
        and multi-line
   Tab draws a single line flexbox
   Tab: if you had one item that was extra big inside of it
   Tab: question is, the flexbox line, which we use for alignment, how
        big should it be?
   Tab: should it be the height of the big item, or height of the flexbox?
   Tab: Old flexbox set it to size of the flexbox in single-line mode,
        but to the height of the tall box in multiline mode
   Tab: top/bottom aligned bits would align within the flexbox element,
        and stretch items would stretch to fit it
   Tab: In second case (multiline) the flexbox line would stretch to
        height of big item, and items would align to bottom/top of that/
        stretch to height of that
   Tab: [even in case of having a single line]
   fantasai reads Alex's choices ^
   Tab: for case C, could get into inconsistent situation with text size
        wrapping, e.g. vertical text stretch inside first line, when it
        wraps behavior changes, so size is different of this item,
        which causes the wrapping to wrap differently
   szilles: advantage of bottom drawing is it doesn't distinguish between
            multiline and single line
   fantasai: related question is whether flex-line-pack: stretch can
             shrink the lines in order to fit inside the flexbox
   fantasai: you could get the first (old single-line) behavior also
             for multiline cases
   fantasai: though it means that multiline mode, items will overflow
             each line instead of lines overflowing flexbox
   Tab: This only is an issue if you are using a cross-size that's just
        too small
   Tab: My proposal is to keep the current spec, which puts them always
        in the second situation
   Alex: if you compare with vertical-align, there are multiple values
         for [...]
   Tab: We share all the basic values between vertical-align and
        flex-align, we miss the ones based on text metrics
   Alex: in single-line case there's no wrap, the height of the flexbox
         is the height of the line
   Alex: vertical top and bottom will align with top and bottom of the
   Alex: Don't want to change to align to overflowing items, just to
         handle the multiline case
   Tab: Introduces unfortunate case that whether you wrap or not changes
   Alex: in multiline height of line can't be set explicitly; single-line
         mode, can do that by setting it to the height of the flex box
   szilles: for inline setting, the container has no height of line
   fantasai: the vertical text case Tab gave, doesn't apply because the
             size of that item is determined by the fill-available into
             the cross-size of flexbox
   fantasai: so it's height won't change -- it'll either be short b/c
             doesn't wrap, or it will fill the flexbox and the line will
             fill the width of the flexbox
   reveiwing Alex's proposal C
   Tab: I'm ok with that now

   szilles: so if baselines are snapped to the line grid, does that move
            the flex box, or does that move the items?
   fantasai: you have a problem with line grid anyway, regardless of the
             sizing of the line
   fantasai: since alignment can change how it snaps to the line grid,
             which can change its sizing...
   Tab: So, if we pay attention to line grid, which we'll want to, it
        will force us to move the flex line or have items overflowing
   Tab: so we might as well embrace that and make it happen in general,
        so that the line does not auto-size to the flexbox, it autosizes
        to the line
   szilles: you've got the container, and you've got the line that goes
            in the container
   szilles: when I say snap, which moves?
   Florian: if it only overflows if the flexbox is set to a definite
            size, it's not that bad
   Florian: If it overflowed in auto-sizing cases that would be bad
   Tab: ...
   Tab: either way work
   szilles: So you create a line, which as a baseline, which you are
            aligned to. You take that line, and align it to the grid
   szilles: you're saying as I compute the individual lines, I snap
            those to the line grid
   szilles: those will result in different results
   Tab: I think the way things generally work, I think it's a slightly
        saner approach when we accommodate line-grid explicitly
   Tab: point is, either way, if it causes something to get too large,
        it'll overflow no matter which decision we make here
   szilles: if I set a container height and have an object overflowing
            it, seems like an edge case
   fantasai: use case is, e.g. toolbar, where most items are inside
             the flexbox, but focused item is big, overflowing the
             flexbox, for visual effect (margins used to prevent
             overlapping with other content; overflowing is intentional
   Bert has mild preference for A
   szilles has mild preference for B
   <SteveZ> my preference for B is based on not having the "top" and
            "bottom" keywords for alignment have a different behavior
            or flex-lines and inline lines.
   Bert: [gives some use case]
   Tab: No, C will give you this behavior as long as you only have a
        single line
   Tab: so it's actually what you want
   Bert: if I set min-height on the flexbox
   fantasai explains that case
   Bert: ah, missed the extra if clause
   RESOLVED: adopt proposal C in http://lists.w3.org/Archives/Public/www-style/2012May/0299.html

Flexbox: Terminology

   Issue: Flexbox Terminology and display values
   Tab: rename display:flexbox to display:flex
   Tab: and change spec terminology from flexbox -> flex container,
        and flexbox item to flex item
   Florian: would want to do either both or neither
   peter: any objections?
   RESOLVED: rename display:flexbox to display:flex
   RESOLVED: change spec terminology from flexbox -> flex container,
             and flexbox item to flex item
Received on Tuesday, 15 May 2012 14:08:37 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:15 UTC