Mozilla

The CSS 3 Flexible Box Model

This article about the Flexible Box Layout was written by Jérémie Patonnier, French open Web enthusiast.

The flexible box model

CSS 3 introduces a brand new box model in addition of the traditional box model from CSS 1 and 2. The flexible box model determines the way boxes are distributed inside other boxes and the way they share the available space.

You can see the specification here.

This box model is similar to the one used by XUL (the user interface language used by Firefox). Some others languages use similar box models such as XAML or GladeXML.

Usually the flexible box model is exactly what you need if you want to create fluid layouts which adapt themselves to the size of the browser window or elastic layouts which adapt themselves to the font size.

In this article, all my examples are based on the following HTML code:

<body>
  <div id="box1">1</div>
  <div id="box2">2</div>
  <div id="box3">3</div>
</body>

Distributing boxes: so what?

By default, the traditional CSS box model distributes boxes vertically depending on the HTML flow. With the flexible box model, it’s possible to specify the order explicitly. You can even reverse it. To switch to the flexible box model, set the property display to the value box (or inline-box) on a box which has child boxes.

display: box;

Horizontal or vertical distribution

The box-orient property lets you specify the distribution axis. vertical and horizontal values define how boxes are displayed. Other values (inline-axis and block-axis) have the same effect, but also let you define the baseline alignment itself (basically the boxes are treated like “inline” boxes).

body{
  display: box;
  box-orient: horizontal;
}

Reversed distribution

The property box-direction allows you to set the order in which the boxes appear. By default–when you simply specify the distribution axis–the boxes follow the HTML flow and are distributed from top to bottom if you are using a vertical axis and from left to right if you are using a horizontal axis. By setting box-direction to reverse, you can reverse the boxes’ distribution order. It acts as if you actually reversed the order of the elements in the HTML.

Be careful with this property because it changes the way some other properties work, which can produce some unexpected behavior.

body {
  display: box;
  box-orient: vertical;
  box-direction: reverse;
}

Explicit distribution

The property box-ordinal-group lets you specify the order in which the boxes will be distributed. This is the ultimate customization opportunity, because you can define the order you want, regardless of the HTML flow order. Those groups are defined by a number starting at 1 (which is the default value). So the box model will first distribute those groups, then all the boxes inside each group. The distribution occurs from the lowest value (the group numbered 1) to the highest (the groups numbered 2 and above).

body {
  display: box;
  box-orient: vertical;
  box-direction : reverse;
}
#box1 {
  box-ordinal-group: 2;
}
#box2 {
  box-ordinal-group: 2;
}
#box3 {
  box-ordinal-group: 1;
}

And what about flexibility?

If changing the natural HTML flow order is huge, the real fun begins when you start to deal with the available space.

Box sizing

By default, a box is not flexible. It becomes flexible only if it has the property box-flex with a value of at least 1.

If a box is not flexible, it will be as wide as possible to make its content visible without any overflow. Its size can be forced with the properties width and height (or their min-*, and max-* alternatives).

If a box is flexible, its size will be computed as follows:

  1. The explicit size declarations (width, height, min-* and max-*)
  2. The size of the parent box and all the remaining available inner space.

So, if the boxes haven’t any size declarations, their sizes will fully depend on their parent box’s size. It will work like this: the size of box is equal to the size of its parent multiplied by the value of the its box-flex property divided by the sum of all the box-flex properties values of all boxes included in its parent.

On the other hand, if one or more boxes have an explicit size statements, the size of all those boxes is computed and all the flexible boxes share the remaining available space on the same principle as above.

It probably sounds a bit tricky, but with some examples it will become easier.

All boxes are flexible

In the next example, box 1 is twice the size of box 2 and box 2 has the same size as box 3. It looks the same as using percentages to set the boxes’ sizes. But there is a big difference. If you add a box, you don’t need to recalculate its size. With the flexible box model, each time you add a box, all the others automatically shrink to make room for the new one.

body {
  display: box;
  box-orient: horizontal;
}
#box1 {
  box-flex: 2;
}
#box2 {
  box-flex: 1;
}
#box3 {
  box-flex: 1;
}

Some boxes have a fixed size

In the next example, box 3, which is not flexible, is 160px in width. In this case, there’s 240px of free space available for boxes 1 and 2. So, box 1 will be 160px in width (240px x 2/3) and box 2 will be 80px in width (240px x 1/3). If you wish, you can make box 3 flexible as well. In this case the way the size of this box is computed will be almost the same as with the property min-width.

body {
  display: box;
  box-orient: horizontal;
  width: 400px;
}
#box1 {
  box-flex: 2;
}
#box2 {
  box-flex: 1;
}
#box3 {
  width: 160px;
}

Managing overflow

Because we can mix flexible boxes, inflexible boxes, and flexible boxes which have preset sizes, It’s possible for the sum of all the boxes’ sizes to be larger or smaller than the parent box size. So you can have too much space or not enough.

I have too much space available; what do I do?

The available space gets distributed depending on the properties box-align and box-pack

The property box-pack manages the way the space is distributed on the horizontal axis and can have one of four possible values: start, end, justify, or center

  1. start: All the boxes are on the left side of the parent box and all the remaining space is on the right side.
  2. end: All the boxes are on the right and the remaining space is on the left
  3. justify: The available space is divided evenly in-between each boxes
  4. center: The available space is divided evenly on each side of the parent box

The property box-align manages the way the space is distributed on the vertical axis and can have one of five values: start, end, center, baseline, and stretch

  1. start: The top edge of each box is placed along the top of the parent box and all the remaining space is placed below.
  2. end: The bottom edge of each box is placed along the bottom of the parent box and all the remaining space is placed above.
  3. center: The available space is divided evenly and placed half above and half below.
  4. baseline: All children are placed with their baselines aligned and the remaining space is placed before or after as necessary (This is a simplification about how this value really works, but you see the point).
  5. stretch: The height of each boxes is adjusted to fit the parent box height

A warning about how those properties work: they are strongly influenced by the use of the properties box-orient and box-direction. They can cause some unexpected behavior (for example, the behavior of values start and end could be fully reversed). I hope that once the specification is finalized, we’ll have more information about how those properties work together.

body {
  display: box;
  box-orient: horizontal;
  /* The content of the body is horizontally centered */
  box-pack: center;
  /* and vertically as well ... \o/ */
  box-align: center;
  width: 100%;
  height : 100%;
}

What happens if I don’t have enough space?

Just like with the traditional box model, the overflow property lets you to define the way it’s managed. No surprise here.

However, you must be careful here too. Indeed, the use of the properties box-orient and box-direction can mess it up. For example, you can see elements overflowed to the right instead of the left or to the top instead of the bottom. Take the time to experiment before trying to use it on a big project or you could go mad.

You can also avoid overflow by making the boxes run over multiple lines (or columns, depending on the orientation) by setting the property box-lines to multiple.

Okay, cool, but does it work in real life?

Yes it does! Both Gecko and WebKit have vendor-prefixed implementations of a box model (Note: The current state of the specification does not reflect Mozilla’s or WebKit’s implementation). This means that Firefox, Safari, Chrome, and any browsers that use one of those rendering engines are able to use the features described in this article. If you use one of those awesome browsers, here is a little demo of the flexible box model in action.

If you’re not using a browser implementing a box model, this screenshot shows you what it looks like:

To conclude

You can start to use this box model to layout your HTML documents with modern web browsers. Be careful though, it’s the really first iteration of a W3C Working Draft. There will certainly be some changes. Anyway, the implementations available in Gecko and Webkit are extremely consistent and mature, so if there are changes, they should not be that troublesome.

This box model is a very easy and simple way to solve some usual problems in web design (form layout, page footers, vertical centering, disassociation of visual flow from HTML flow, etc.). I strongly suggest you become familiar with it because it could become a standard tool for web designers in the near future (if Microsoft decides to include it in IE, it could become so very fast).

What is already available is a good start to play with. But at this point, the way the traditional box model and the flexible box model interact is not very clear (for example, it’s impossible to use position:relative with the properties left or top on a box which uses the property box-ordinal-group). This will be improved, but don’t be surprised if your work habits are somewhat undermined. Another tricky point: the way all the properties relative to this new box model interact can be sometimes really confusing. This should remind you of the day you discovered the float property. ;)

For further information

97 comments

Post a comment

  1. Christian wrote on April 22nd, 2010 at 10:22 am:

    Thanks for the great article! Too bad there is no support in IE yet.

    Btw shouldn’t the following be converted from:

    1

    to:

    1

    Reply

    1. Christian wrote on April 22nd, 2010 at 10:23 am:

      seems like I can’t insert any html in here. Basically just have a look at your example code in the first paragraph.

      Reply

      1. Paul Rouget wrote on April 22nd, 2010 at 11:05 am:

        Thanks. Fixed.

        Reply

        1. James John Malcolm wrote on April 22nd, 2010 at 11:18 am:

          In Example 3 (Explicit distribution) you should add the “box-direction : reverse;” line to the article, as now the picture shows the reverse of what you’d expect.

          Very good, clear cut examples though!

          Reply

          1. Paul Rouget wrote on April 22nd, 2010 at 11:27 pm:

            Good catch! Fixed.

  2. Kroc Camen wrote on April 22nd, 2010 at 10:27 am:

    Good good. Nice to be able to easily reverse order in CSS without floats.

    Downsides? Combined with display, position and float this new addition just makes CSS layout even more mind-bogglingly confusing for new developers and it still doesn’t replace colspan / rowspan in table layout.

    Who knows, one day we might actually deprecate CSS1 layout and bring some semblance of concise and precise back to CSS.

    Reply

    1. James John Malcolm wrote on April 22nd, 2010 at 11:09 am:

      It doesn’t really seem that mind-boggling.

      I’m especially appreciative of the effort made to accommodate source vs flow order issues, center-center issues, and the eternal sticky-footer problem. All long standing css issues which seem to be resolved in a non-clunky, flexible and compatible way.

      Reply

  3. Norman wrote on April 22nd, 2010 at 10:32 am:

    thats even better than using display:table & display:table-cell. nice work, going to check it out soon. :)

    Reply

  4. Hans Wurest wrote on April 22nd, 2010 at 5:32 pm:

    « if Microsoft decides to include it in IE, it could become so very fast »

    As fast as the decline of IE6 users?

    Reply

  5. Hans Wurest wrote on April 22nd, 2010 at 5:33 pm:

    if Microsoft decides to include it in IE, it could become so very fast

    Just as fast as the decline of IE6 users?

    Reply

  6. Pingback from Atomic Robot Design Blog | CSS3 Flexible Box Layout « Atomic Robot Design on April 22nd, 2010 at 7:35 pm:

    [...] in the body and display it horizontally. That simple. Here’s an example I got from the Mozilla Hacks blog: 123<div id="box1"></div> <div id="box2"></div> <div [...]

    Reply

  7. Jamie wrote on April 22nd, 2010 at 7:50 pm:

    How did I miss this for all these years? I feel shocked that this entire spec has been so thoroughly thought out and implemented while remaining so under the radar. It does seem complex, but perhaps not unnecessarily so. It does seem to solve the “make this height equal to the next col’s height” problem as well as out-of-order HTML display.

    Reply

  8. Havvy wrote on April 22nd, 2010 at 10:17 pm:

    With so many display, it might help to show how they cascade as you change them. Right now it seems like it’d be pure guesswork on how combining various models together works. It is also possible that redundancies exist. It’d be good to test this. Oh, and images of what the layouts look like would be useful too.

    Reply

  9. Loïc wrote on April 22nd, 2010 at 11:33 pm:

    Very interesting!

    Still, actual implementation can be disturbing for the user. Indeed, have you try to select text in the example? For instance, start to select from the “article on always on top” and go down. Not really what was expected…

    Reply

  10. jpvincent wrote on April 23rd, 2010 at 1:24 am:

    for those who wondered : not event IE9 preview supports it

    Reply

  11. Dan wrote on April 23rd, 2010 at 5:50 am:

    “Some boxes have a fixed size

    In the next example, box 3, which is not flexible, is 160px in width. In this case, there’s 240px of free space available for boxes 1 and 2. So, box 1 will be 160px in width (240px x 2/3) and box 2 will be 80px in width (240px x 2/3).”

    The last bit should be 1/3 not 2/3.

    Thanks for the article, this seems like a more natural way of designing things.

    Reply

    1. Paul Rouget wrote on April 23rd, 2010 at 6:41 am:

      Done! Thanks.

      Reply

  12. Ian Obermiller wrote on April 23rd, 2010 at 2:02 pm:

    I didn’t see this pointed out anywhere, so I’ll clarify it here. On the example page noted at the end of the article, they mention that the flexible box model can be used to create a sticky footer. This is accomplished by setting box-flex:1 on the preceding element, in this case #main { -moz-box-flex:1; }.

    Reply

  13. Don Williams wrote on April 23rd, 2010 at 7:12 pm:

    So basically it’s doing layout with tables where “table” has been renamed “box” and the syntax has been made a lot more complicated and unintuitive than tables, all to please the radical anti-table contingent, who want tables but want them not to be called tables so their radical peers won’t nag them about it.

    Reply

    1. Paul Rouget wrote on April 24th, 2010 at 4:24 am:

      No, because the table problem was to have “design” in the “content”. Here, all the design work is CSS side.

      Reply

      1. thinsoldier wrote on October 13th, 2010 at 9:25 am:

        … and in theory (maybe) the same css could be applied to table tags? So maybe I could redesign a fustercluck of a table-based sited from 2002 without ever having to hurt my brain trying to edit the complex table structure…

        Reply

    2. voracity wrote on April 24th, 2010 at 5:41 am:

      Don, I sympathise, but I think you’ve misunderstood the import. Like you, I am one of the anti-”anti-table contingent” contingent, but flex-box very much gets my tick of approval. It *can* make HTML code much cleaner, and it *can* be more powerful than tables. But if you want to ignore it, feel free.

      The push to use CSS over presentational tags was, in fact, well intentioned, but the pure CSS advocates ignored the fact that CSS had absolutely shocking layout support — and they continued to ignore it for a good 10 years! Flex-box, or something like it, should have been brought into play much earlier — but then again, so should have HTML5. ;)

      Note: this is not a criticism of any individual or group. Thankfully, the web is not ruled by a despot, “benevolent” or otherwise, and so will evolve on its own terms, even if that’s sometimes a little slower (say, 10-15 years slower) than we’d like…

      Reply

    3. Mike wrote on April 29th, 2010 at 5:30 am:

      @Don Williams: You clearly don’t get web standards and semantic mark-up. If I have time, I’ll come back here later and write some more in response to your comment.

      Reply

  14. Ryan wrote on April 23rd, 2010 at 10:00 pm:

    I’m using -trunk (specifically, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100423 Firefox/3.7a1pre) and I’m not seeing the example page rendering properly.

    Reply

    1. Paul Rouget wrote on April 24th, 2010 at 4:26 am:

      Can you tell me what’s wrong? (I’m using trunk here as well, no problem)

      Reply

  15. Shaun wrote on April 23rd, 2010 at 11:06 pm:

    Great stuff. With any luck, 99% of users will be using CSS 3 compliant browsers before the year 2019. =) Until then…

    Reply

  16. voracity wrote on April 24th, 2010 at 5:23 am:

    Yay, a hacks.m.o article on flex-box! This layout model seriously needs to be promoted more widely. Does anyone know if an implementation for IE is possible using HTC files or some kind of XAML hack or some such?

    Reply

    1. thinsoldier wrote on October 13th, 2010 at 9:28 am:

      Agreed. Flex-box is probably the single most useful and important aspect of css in my opinion. We should be pushing for this more than transitions, webGL, hsla, 3d transforms, etc…

      Reply

  17. discoleo wrote on April 24th, 2010 at 8:01 am:

    All these boxes are sooo… rectangles. When will we get circles and the like into play?

    Reply

    1. wrote on May 1st, 2010 at 3:25 am:

      When you start publishing in SVG format.

      Reply

  18. Uman wrote on April 24th, 2010 at 8:30 am:

    IE users can use the google chrome frame to try this out…

    Reply

  19. John Haugeland wrote on April 25th, 2010 at 10:01 am:

    This is neat and all – it’s nice that CSS is finally offering the frames sizing model – but it’ll be years before it’s portable.

    In the meantime, this is really quite easily hacked together in a few lines of javascript.

    Reply

  20. Sergio de la Garza wrote on April 26th, 2010 at 8:29 am:

    That’s the seme we have done in elastic css framework like 2 years ago: http://elasticss.com

    Reply

  21. Sergio de la Garza wrote on April 26th, 2010 at 9:20 am:

    That has been done already, and works for all browsers, its called Elastic CSS Framework

    Reply

  22. Shay Howe wrote on April 26th, 2010 at 12:50 pm:

    I love it! The markup is clean and easy, as well as extremely flexible. I understand the table argument however the majority of the code here is within the CSS rather than the HTML. Really looking forward to putting this to use.

    Reply

  23. BigAB wrote on April 26th, 2010 at 12:55 pm:

    Does \box-lines\ property work in any browser? Is there an example of this working anywhere?

    Reply

  24. Philip wrote on April 27th, 2010 at 7:20 am:

    I like it, but I like the specs of CSS Template Layout (http://www.w3.org/TR/2009/WD-css3-layout-20090402/) even more.

    Reply

  25. Wes wrote on April 27th, 2010 at 10:17 am:

    box-lines does not works in firefox

    Reply

  26. denisdeng wrote on April 29th, 2010 at 2:29 am:

    Good article! I have learned a lot from this.
    Css3弹性盒模型

    Reply

  27. ren1999 wrote on April 29th, 2010 at 6:22 am:

    I experimented with this flexible box model and personally found it needlessly complicated and not useful. I really don’t want my cells too flexible so that each word is stacked up on each other.

    Furthermore, there is no rowspan or colspan command which makes the table command still relevant.

    I have always had a lot of problems using div for dividing articles. I do use div but mostly with Javascript’s GetElementByID and innerHTML.

    I think that the header, footer and section reserved words should be removed.

    Reply

  28. Thomas Gossmann wrote on April 30th, 2010 at 8:32 am:

    Once I’d love to have sth like
    width: 100% – 260px; which would lovely fit into the flexible box model :)

    Reply

    1. Christopher Blizzard wrote on April 30th, 2010 at 9:21 am:

      @Thomas – we totally have that coming! We’ll post about calc() shortly.

      Reply

  29. Luke Dorny wrote on April 30th, 2010 at 1:20 pm:

    This looks interesting, and useful.
    Note: the demo page right column overflows the footer when the viewport is collapsed too much horizontally.
    You could add overflow:hidden to that column to force reflow and push down the footer. Common trick.

    Reply

  30. Martin Kliehm wrote on May 4th, 2010 at 6:16 am:

    Wonderful solution, still I’ll have to use hacks for backward compatibility for a few years. I often come across the problem of column order when I want to create an accessible site where the tab order needs to be logical (as opposed to jumping from left to right to middle column). This is perfect for it. Though I’d like to remark that the name ‘box-flex’ isn’t very intuitive. It enables flexibility, but also it describes the size ratio of box columns. Any chance to change this naming?

    Reply

  31. Olivier wrote on May 5th, 2010 at 6:26 am:

    Finally! That’s all I have to say ;)

    Reply

  32. stefan wrote on May 6th, 2010 at 8:03 am:

    I’m very very interested in this. It solves the “footer on the bottom” much better then CSS-templates.

    Unfortunately, the example page works very nice in Firefox, but the text from the right column overflows when you re-size the browser window in Safari or Chrome (4.1.something).
    In Firefox: the footer will be pushed down, and a scroll-bar will appear, not so in Chrome. There the footer stays visible.

    Do you have any thoughts on that? Or am I missing something?

    Reply

    1. Zoe Gillenwater wrote on August 3rd, 2010 at 11:51 am:

      Changing the containing element (in this case #page) from height:100% to min-height:100% fixes it in Webkit in my tests, without changing the behavior in Firefox.

      Reply

  33. Matt wrote on May 13th, 2010 at 6:54 am:

    Seems to be a bug in FF 3.5 when trying to use box-flex alongside position absolute.

    Basically, I’m trying to absolutely position an element relative to one of the flexible divs, but it only seems to work correctly in FF 3.6. Here’s a test example:

    http://meta-graphical.com/tests/box-flex.html

    Div number 3 is always containing div number 4 in FF 3.5 despite it being absolutely positioned. Can’t figure out a fix for this at all. :(

    Matt

    Reply

  34. Giorgio wrote on May 13th, 2010 at 10:44 am:

    hi Matt, positioned items inside boxes and boxes they-self do not works at all in the current Mozilla implementation, but in future i hope they will

    for flex box testers: submit your requests of improvements and features to Mozilla’s Bugzilla

    bye :)

    Reply

  35. Emil Ivanov wrote on May 17th, 2010 at 6:06 pm:

    I wish IE and Opera implement this soon so we can start using it, this is so wonderful.

    Reply

  36. Martin *toi wrote on May 19th, 2010 at 11:38 am:

    Awesome article, thanks man. really got me motivated to finally get myself a clue about the new box model. simple straight-forward describtions and examples, that’s how I like it.
    already discovered some bugs though… nice to have a link for reports in here, you’ll get mail ;)

    keep it up guys… I’ve always been an opera fanboy because I had used it like forever, way before I even heard about firefox. but for work and all things beyond surfing the web, firefox is just way ahead.

    Martin / germany

    Reply

  37. Pingback from Tantek Çelik Working With Mozilla » arunerblog on May 26th, 2010 at 6:27 am:

    [...] now we’re both working in various capacities for Mozilla. Tantek will help us out with the CSS3 Flex Box Model, figuring out what the right thing to do with respect to stylable HTML5 form controls are, and help [...]

    Reply

  38. Sam wrote on June 7th, 2010 at 12:31 am:

    I personally like this proposal more: http://www.xanthir.com/:wih Simply because it defines a flex length for height, width, margins, paddings and border-width. Rather than just have a box-flex property which is only for width or height. Also it talks about wrapping for multiple rows or columns. Over all, it’s just way more powerful.

    I really hope to see the W3 spec changed to this proposal.

    Reply

  39. Mike wrote on July 17th, 2010 at 11:26 am:

    Doesnt work (firefox) , sorry…..

    Reply

  40. gonAlonso wrote on July 20th, 2010 at 3:59 am:

    I’m a little confused about this… CSS is meant to do presentation while XHTML should support content.
    But this example has some tricks to make things just work. The body tag is filled with a div element. This is purely presentation as I’ve read. In fact, all XHTML5 templates I’ve seen shows many specifically elements right inside the body tag, not nested div to manage border, extra space, etc.

    I consider table layout is really needed in some/many scenarios. Both FF and WK support display: table, display: table-cell… something very useful although not complete (lack of colspan, rowspan..)

    Reply

  41. Zoe Gillenwater wrote on August 10th, 2010 at 1:08 pm:

    I’ve been testing this, and box-flex does not work as described in this article, in either Firefox or Safari/Chrome. For instance, in the example where box1 is set to flex 2 and boxes 2 and 3 are set to flex 1, boxes 2 and 3 are only the same width because they have the same amount of content (one character). Add a whole bunch more content to box 3, for instance, and it will get bigger than box 2. So, equal box-flex values do not mean equal widths, as browsers are implementing it now.

    Reply

  42. Geoff Kendall wrote on August 19th, 2010 at 11:05 am:

    I have to say I’m viewing this with horror – yet another layout model? I’m slightly baffled by talk of the ‘sticky footer’ problem, as cleared footers seem to be one thing that CSS can do right on all major browsers. The really big problem with CSS (as implemented in the real world) is that divs (i.e. boxes?) can neither be guaranteed to contain their own content nor to exclude what is not their own content – that’s the major mindwarper IMHO( cue comments on AP, floating nearly everything, having layout, zoom:1, etc). I know lots of folk will want to say that I ‘just don’t understand’ something or other, but when I see a straightforward header/left and right columns/footer layout described as ‘the Holy Grail’ and when almost any layout issue at all seems to be a matter for debate, something’s very wrong with the standard (as we all know). The problem is, how can adding a new box model help when the huge numbers of IE6/7/8 users won’t be able to display the website you make with it? Clients want their sites to look the same for everyone, so barring a worlwide dictat that sees everyone update their browsers, we’re stuck with the current mess and I can’t see much sense in adding to it. Perhaps we should start making sites for new browsers only and call it a new ‘format’, to supercede the old CSS as DVD superceded VHS? We have to leave the old browsers behind, or carry on writing for them.

    Just thinking out loud..!

    Reply

    1. Michael wrote on November 15th, 2010 at 1:51 pm:

      “Perhaps we should start making sites for new browsers only and call it a new ‘format’, to supercede the old CSS as DVD superceded VHS? We have to leave the old browsers behind, or carry on writing for them.”

      I couldn’t agree more, Geoff. In my mind I see super-capable sports cars driving down the Autobahn at only 30 MPH because someone’s grandfather is feather-footing ahead in a car that takes up 4 lanes and can’t let anyone pass.

      I’m currently designing a site right now that’s HTML5/CSS3-only, and I [mostly] don’t care about IE. I could suffer a potential revenue loss at launch time, but I’d rather give users a more modern experience (and give myself fewer headaches) than dumb things down for compatibility. As people start to become more and more acquainted with advanced techniques, the sheer attraction to what’s possible will inspire them to launch sites that may exclude less-capable user agents. Discuss.

      Reply

  43. Matt wrote on August 20th, 2010 at 2:10 am:

    @Geoff Kendall I can see your point. I’ve worked on sites for some major companies and there’s no way I could have used box-flex on any of their websites.

    However, I don’t think we can let the high usage of old browsers stem the development of new standards and techniques. Otherwise, the industry would never be able to move on. It’s important that stuff like this continues to be worked on to drive innovation.

    Also, I’m pretty sure cleared footers and sticky footers are two separate things. Or maybe I’m just misunderstanding what a sticky footer is: http://www.cssstickyfooter.com/

    Matt

    Reply

  44. Geoff Kendall wrote on August 20th, 2010 at 4:33 am:

    Hi Matt

    I’ll have a look at box-flex next time I have a day free or need a break, as I agree that we should at least look at how to progress if what we have isn’t working (although I could argue that CSS and browser incompatibilities keep web designers employed very effectively!). As for footers, I suppose I don’t really understand why the page would ever need to continue down after the footer? Fix a min-height: (IE6, height:) for your main content, if you want to, then the footer will follow and the page will end afterwards? I’m a Float Nearly Everything fan for most situations, but then I’m by no means a layout expert. For what it’s worth, I’ve eventually learned that fixed width layouts are far easier and that design principles frequently depend on alignments, alignments that are difficult to preserve with liquid or elastic layouts. I have done stretchy sites, but they can take (me, at least) a very long time to get working across all popular browsers. Actually, that’s a frustration in itself – with twenty sites online, I really should know all there is to know about layout by now…

    Reply

  45. thinsoldier wrote on September 13th, 2010 at 10:17 am:

    So which of these is the w3c css group’s priority?

    This flexible box model or the “Advanced Layout Module”
    http://www.w3.org/TR/2007/WD-css3-layout-20070809/
    ?

    Personally I like this flexible box.

    Will they ever call a vote to choose which of the 2 to focus on?

    Reply

    1. Paul Irish wrote on October 4th, 2010 at 5:09 pm:

      It’s pretty different people working on those two, but from what I’ve seen there is very little interest from the implementor side in adding support for the css3-layout module.
      It’s very document-centric and doesn’t solve nearly as many problems as flexbox does. :/

      Reply

  46. Tim wrote on October 7th, 2010 at 2:57 pm:

    Is anyone else having problems implementing -webkit-box-lines:multiple? It’s not working for me and can’t find any live examples anywhere…

    Reply

  47. thinsoldier wrote on October 13th, 2010 at 9:21 am:

    Who wants to help me with css-3-flexible-box-model-zen-garden.com ?

    Reply

  48. thinsoldier wrote on October 13th, 2010 at 9:35 am:

    Good thing I checked out your site before taking the time to write a ‘serious’ response.

    I’m not trying to hate. I’m no expert either. And you’re markup’s pretty clean.

    But there’s something about your site that makes me think nobody should ever listen to your suggestions.

    Reply

    1. thinsoldier wrote on October 13th, 2010 at 9:36 am:

      that was in response to kira1999

      Reply

      1. thinsoldier wrote on October 13th, 2010 at 9:37 am:

        actually that was to ren1999

        Reply

  49. Eugene wrote on November 7th, 2010 at 5:19 am:

    I noticed a difference between Gecko and Webkit regarding how they calculate the size of a box (at least, in the direction “opposite” to box-orient). In this respect boxes are like inline blocks in Gecko and like “ordinary” blocks in Webkit. Just in case, here is the code of a test page: http://pastie.org/1278958 (I apologize for lots of not-so-related CSS and JavaScript).

    Reply

    1. Eugene wrote on December 17th, 2010 at 1:33 pm:

      I overcomplicated the problem. This difference between Gecko and Webkit does not depend on box-orient. See http://jsfiddle.net/cpn2u/1/embedded/result/ or http://pastie.org/1385728

      Reply

      1. wes wrote on December 18th, 2010 at 10:36 am:

        current implementation of flexbox in gecko is probably the oldest one, it is an experiment, and the webkit one is an experiment too, there are a lot of unknown behavior that are not yet explicitly fixed by the spec, including the cooperation of other box-models and css positioning, the flexbox in mozilla is designed to work for now in a restricted environment: xul

        i use flexbox to design guis of an intranet software, and it absolutely rocks

        go, flexbox go

        Reply

  50. wrote on November 21st, 2010 at 6:36 pm:

    So I’m playing with this now and it seems to not work at all in absolutely-positioned containers. I set up display: -moz-box, pack center, align center, and it works beautifully… then I add position: absolute and bam, it no longer works.

    This means it’s still not possible to vertically centre within the window. Good god this should not be such a difficult task.

    Reply

    1. Michael wrote on November 22nd, 2010 at 1:33 am:

      @wrote (November 21st, 2010 at 6:36 pm)
      That’s because absolutely positioning it is wiping out the entire effect of the box layout.

      Reply

      1. wrote on November 22nd, 2010 at 12:51 pm:

        Right, but if I have an absolutely-positioned container, 100% width and height, should I not be able to use box layouts inside that container? I don’t understand why the positioning of a parent/ancestor element affects box model any more than it would affect normal flow within the container.

        Reply

1 2

Post Your Comment

  1.