- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 15 May 2012 07:07:55 -0700
- 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
http://www.w3.org/mid/2C86A15F63CD734EB1D846A0BA4E0FC81A3EDD72@CH1PRD0310MB381.namprd03.prod.outlook.com
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16856
- 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
http://lists.w3.org/Archives/Public/www-style/2012May/0299.html
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 ======
Present:
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
there.
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</></>
http://lists.w3.org/Archives/Public/www-archive/2012May/att-0023/flexbox-table-boxes.jpg
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
display-outside:flexbox-item
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
<div>...</>
<img>
...ABC...
<div>..</>
</>
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]
http://lists.w3.org/Archives/Public/www-archive/2012May/att-0023/flexbox-inline-magic.jpg
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.
http://www.w3.org/mid/D51C9E849DDD0D4EA38C2E5398569284121366F7@TK5EX14MBXC213.redmond.corp.microsoft.com
* 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
'hidden'.
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
jiggle
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?
http://www.w3.org/mid/57440D3E-FD1B-4526-91AD-0898C6AAB3AA@philipwalton.com
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?
http://www.w3.org/mid/D51C9E849DDD0D4EA38C2E539856928412EB4BF0@TK5EX14MBXC214.redmond.corp.microsoft.com
http://www.w3.org/mid/D51C9E849DDD0D4EA38C2E539856928412EB55DC@TK5EX14MBXC214.redmond.corp.microsoft.com
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?
http://www.w3.org/mid/4F91E0D6.7040502@inkedblade.net
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
width/height?
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
http://www.w3.org/mid/2C86A15F63CD734EB1D846A0BA4E0FC81A3EDD72@CH1PRD0310MB381.namprd03.prod.outlook.com
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16856
Tab: Flexbox with 2 children, one small, one really big
http://lists.w3.org/Archives/Public/www-archive/2012May/att-0023/flexbox-negative-flex.jpg
Tab: overflows, negative flex is allowed
Tab: right now, take overflow amount as negative space, split evenly to
children
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
space
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
perspective
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
first.
fantasai: So if one of them has a long word, and another has a short
word...
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
happens
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
contexts
http://www.w3.org/mid/4FA150C0.7080605@inkedblade.net
Tab: multi-line row flexbox
(tab is drawing an example)
Tab: with stuff in it
http://lists.w3.org/Archives/Public/www-archive/2012May/att-0023/flexbox-break.jpg
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
http://lists.w3.org/Archives/Public/www-style/2012May/0027.html
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
normative
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
---------------------
http://lists.w3.org/Archives/Public/www-style/2012May/0007.html
Tab: previously, there was a difference in cross-sizing for single-line
and multi-line
Tab draws a single line flexbox
http://lists.w3.org/Archives/Public/www-archive/2012May/0023.html
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]
http://lists.w3.org/Archives/Public/www-style/2012May/0299.html
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
flexbox
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
behavior
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
effect)
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