Re: [css3-flexbox] intuitivity and width computation rules

Hey all,

for what it’s worth, here’s what I discovered about the current
implementations of Flexbox. There’s some repetition with what others
have mentioned in this thread, but I thought it might still be useful.
Please let me know if I’ve misunderstood anything.

* Preferred width for text content is currently the text without line
breaks, leading to very unintuitive width calculations. This means we
basically must declare a width on a box element child containing any
non-replaced content longer than a few words
* The obvious solution when making a flexible layout is to set
percentage widths, but Firefox ignores percentages on width for
flexbox children. This may be a misreading of percentages not being
valid for box-* children as per the spec [1]
* Firefox treats display:box as display:inline-box [2] I initiall
thought this happened if the box element doesn’t have a width
declared, but box elements with small widths stack horizontally
* Overflow issues are painful — WebKit allows content too wide for the
box element’s child to overflow out of the container box, but FF
ignores width and expands the child [3]. Firefox also doesn’t respect
overflow:hidden on box element children with content larger than the
child’s declared width, such as pre content or a very long word [4]
* When flexbox declarations are nested they are calculated from the
inside out, rather than top down. Combined with our inability to use
percentage widths for children in Firefox, and how the preferred width
of text content is determined atm, this makes Firefox’s Flexbox
implementation unusable for liquid nested layouts atm — inner boxes
take all the space, leaving little for outer boxes. Setting child
widths to percentages works fine in WebKit, and using widths *other
than percentages* works fine in Firefox
* There appears to be a bug in WebKit’s shrinking algorithm if child
widths are not specified, or if child widths are significantly larger
than the box element width, if the box-flex values differ (especially
significantly). This can lead to the child with the largest box-flex
value becoming close to zero width [5]
* Using display:box prevents margin collapsing for the box element’s
children in WebKit and Firefox — I suspect this by design and it’s not
a problem. However Firefox also doesn’t collapse margins between the
box element and surrounding content [6]
* Firefox pads outline on flexbox children by the same amount as the
outline’s width [7]

In conversation with Tab I’ve heard that percentages will be usable in
flex-* (although for me the main problem is the bug with Firefox), and
overflow will also be given some attention. Even more importantly
there’ll be a change to top-down width calculations.

Initially, based on all the 1,2,3-style examples I also thought
flexboxes would work like the black magic of table cell widths, with
the width being somewhat dependent on content (but not ‘content
without line breaks’). Tab’s suggested “auto = min-width” would be a
big improvement on the current implementation.

Another option I think is worth considering would be for the default
value to resemble * in the Template Layout module — all box element
children without widths equally share the left-over width of their
container (=width available after subtracting children with fixed
widths). What do you think about this compared to min-width?

HTH

peace - oli

btw I wrote an article based on this email, with some examples of the
inside-out issue:
http://oli.jp/2011/css3-flexbox/

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=529761 and
https://bugzilla.mozilla.org/show_bug.cgi?id=394078
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=625694
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=625697
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=625700
[5] https://bugs.webkit.org/show_bug.cgi?id=52441
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=625703
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=625702

Received on Friday, 14 January 2011 16:03:35 UTC