Solved by Flexbox | Hacker News Reader

Solved by Flexbox

philipwalton.github.io

671 pointsoskarth123 comments

Solved by Flexbox creator here. I wanted to add that if you're using flexbox today, you should also check out this other repo of mine:

https://github.com/philipwalton/flexbugs

A community-curated list of flexbox issues and cross-browser workarounds for them.

Very smart, it's nice to see you are inviting people to submit workarounds and descriptions of problems in different browser, instead of just asking for bug reports.

This makes feel the project more interesting, because if I hit one of the already covered problems, I already know where I can (probably) find the solution.

Seems that mostly IE had these issues, which are now resolved in version 12. Chrome has only one issue, which seems to be already fixed in Canary.

Thank you for doing all this, that really helps spreading the word and accelerates web development!

Hat's off to you, Philip. You are putting all your eggs in one flexbox basket--and now you are taking excellent care of that basket. I think that's a very smart approach; I particularly enjoy the approach of having a codepen to demo the bug, the workaround, and a link to the filed bug with the browser. It's so obvious, which means it's genius.

Have you also tested it inside of an iframe?

As far as I know support on Safari wasn't quite there yet. Last when I checked, and that was almost two months ago, Flex broke down pretty badly on iOS Safari, both on iPad and iPhone.

Guess I need to revisit this probably. Thanks for the great piece of work!

So unfortunate that we still can't just use flexbox without hacks. Do you know of any methods of 'fixing' Safari?

Replace it with Chrome ba dum ding

Chrome's flexbox support ain't exactly perfect either.

So use a tool like Autoprefixer or SAS and re-roll your CSS occassionaly as compatibility improves.

Safari works fine. It just still needs vendor prefixes.

Nice work, I'm just starting to learn about flex box, and this resource will come in handy for sure.

Solved by flexbox is nice.

Regarding flexbox itself: the syntax is confusing. After working on html/css, leaving, using auto-layout (obj-c, ios) and coming back to trying flexbox, I am scratching my head, who came up with this?

row/column - use horizontal/vertical or hor/ver for short. justify-content and align-items mean different things depending on whether you're using row or column - what?

why not just have hor-align, ver-align?

Suppose you want a box with 3 paragraphs left-aligned, centered on the screen and a footer with 1 paragraph, aligned with the 3 paragraphs above it, how do you do this?

Here's my pseudo-code:

body ver nowrap, hor-align center.

add 2 flex boxes ver nowrap.

box 1 height stretch, hor-align left, ver-align center.

box 2 height fit-content, hor-align left, ver-align center.

add 3 paragraphs to box 1.

add 1 paragraph to box 2.

In reality, it is: body flex: column nowrap, justify-content: center, or is it align-items? I don't know, let's guess.

How do I do box 1 height stretch? Hm... I don't intuitively know because nothing intuitively makes sense with flexbox. The answer turns out to be flex: 1 on box 1 and flex: 0 on box 2. Great syntax.

And the pain continues. Btw, if you set the paragraph margin to 1em 1em 1em 1em;, it breaks the horizontal alignment of the paragraphs, making them center-aligned, why? Only God knows. If you set margin: 1px 1px 1px 1px, it works as expected. What?!

Flexbox is light years ahead of the retardation that is floats and clears and the rest of it but it is a FAR cry from auto-layout.

Let me set the height of an element... in relation to another element... ANY element... Why am I doing flex: 2, flex: 1 but that only works for sibling elements? What if I want box 1 width to be 20% of the height of box 2 that's elsewhere on the page? How do I do that in flexbox?

Even if there is a way, the fact that I don't know and I've spent 2 days figuring it out says it all.

I disagree with row/column vs. hor/ver - the web mostly operates on thinking in terms of rows and columns. Otherwise, I do agree there is some confusion with the flexbox syntax and understanding it. I have found http://css-tricks.com/snippets/css/a-guide-to-flexbox/ immensely useful.

True, but to me it wasn't obvious whether "flex-direction: row" meant horizontal (because a row expands horizontally as you add columns) or vertical (because a table expands vertically as you add rows).

I didn't find it helpful - confusing, yes. I found the spec better, which I thought there'd never come a day I'd say but yes - the flexbox spec is the best resource for understanding flexbox. Wow. I know.

I think I'm just ranting on the html layout rules in general, for instance:

https://css-tricks.com/almanac/properties/m/margin/

This points out like 3 things that make NO SENSE. To center something horizontally, you use margin: auto; What? Margins are for having space between elements, not for centering anything. But ok let's say it is for centering, which makes no sense, then you should be able to set the vertical margins to auto. Wait, you can't do that. WHAT!?!

It goes on to say if you have 2 paragraphs with top and bottom margins, that doesn't mean you have 2 paragraphs with top and bottom margins some of the time. Because 2 paragraphs, the top/bottom margins of the 2 paragraphs will collapse. WHAT?!?!?!?!

Yeah, flexbox is just another abysmal attempt, in the right direction mind you. I don't know who runs the show but I'd say a 3rd year comp-sci student in one year, can come up with a better layout engine (how it works, not performance, by copying auto-layout for instance) than what is currently in existence.

You can do vertical centering with margin:auto. Just absolutely position.

And margin collapse was a bad idea, I agree. But HTML had it, before CSS. If anyone is to blame for margin collapse, it's NCSA Mosaic. CSS just needed to describe what already existed.

> The flexbox spec is the best resource for understanding flexbox.

Link to the Flexbox spec for anyone interested:

http://www.w3.org/TR/css3-flexbox/

Actually I just read "Dive into Flexbox" and in 5-10 min read now have a clear understanding of how flexbox is designed to work. Best explaination I've read.

http://bocoup.com/weblog/dive-into-flexbox/

The fact that justify-content and align-items changes based on horizontal or vertical is useful for many reasons: toolbars that can become vertical or horizontal per user customization, or vertical writing-direction, for example.

I'm saying the syntax is terrible. The functionality is limited. Why is one 'content' and another 'items'?

If you want horizontal and vertical alignment to switch places when you change directions, then you can have a flag that does that for you.

For example I have X | X | X - a horizontal layout. I want it left-aligned horizontally and top-aligned vertically. (Top-left corner) and I make it work with the current flexbox stupid syntax.

Now if we switch that to vertical layout

Now where is it gonna be with the current flexbox layout and using content-whatever align-items? I don't really know off the top of my head, because it doesn't make intuitive sense!

With horizontal/vertical I know it's in the top left corner. With flex-start, justify-content and align-items I don't know what the heck.

It makes sense after you've worked with it for a little bit, I had the same confusion when I first started using it but after a while it started making sense and by now I absolutely cannot see myself go back to anything else, it's just so pleasant to write in.

I agree, when you're forced to eat at McDonalds, choose the shitty salad.

Have you worked with auto-layout in xcode? If you did that and used flexbox and chose flexbox, I'd be flabbergasted.

Given the choice between blocks, inline-blocks, floats and flexbox - I'm choosing flexbox 100% of the time. Doesn't mean it's not painful however, just that the other options are insane.

I prefer flexbox to auto layout in Xcode, actually. In fact, for Mac apps I've always turned off auto layout and gone back to springs and struts, since they're so much simpler...

Hehe that'll come to bite you ;)

I'd actually equate auto-layout when it was first introduced to the current state of flexbox. It can do what you want but boy are there some gotchas along the way.

It has gotten a lot better - the pain point with autolayout remains when when you need to add constraints in code - then it's a painful API. In UI, it is quite a pleasure to work with I find.

I wonder when that's coming to web dev - a GUI for web layout using flexbox would make a lot of people happy. The reason dreamweaver and the like didn't work well is because there were too many gotchas, do this in javascript, that in css, etc.

With flexbox, css selectors and some good plug'n'play javascript components (carousel, etc, everything bootstrap offers basicaly) - I can see a tool like Dreamweaver making a big comeback. What do you think?

Auto layout is fiddly and annoying. You have to specify at least 3 or 4 constraints per element, often more. It also has no concept of flow, which in my book makes it essentially useless for many applications.

Specifying constraints one time and having them work across landscape/portrait and different sizes, all done in a UI interface, with warnings/errors to help you out. Being able to specify relationships of any element to any other element.

So much worse than typing in a text file, saving, refreshing your browser, testing in different browsers, testing on different phone devices, polyfills, -webkit, etc etc etc.

Autolayout got ways to go to catch up to web dev huh :)

I feel your pain regarding auto layout being difficult SOMETIMES but if you've come from web dev and you're not crying tears of joy at not having to waste your life trying to create proper column layouts with a footer and a header (the 'holy grail' of web dev, lol the bar is set so low it's hitting me in the ankle), I don't know what to tell you :)

Also, what the heck is this flow concept. I hope you're not referring to uicollectionview which has, flow layout, lol.

If you took the time you've just spent calling flexbox "retarded" and used it to read the basic documentation of the properties you claim are impossibly unintuitive, you would know the answer to your question.

Switching orientation is a basic requirement for the whole idea of flexible boxes in CSS. From MDN [0]:

> The flexbox layout algorithm is direction-agnostic as opposed to the block layout, which is vertically-biased, or the inline layout, which is horizontally-biased. While the block layout works well for pages, it lacks sufficient definition to support application components that have to change orientation, resize, stretch, or shrink as the user agent changes, flips from vertical to horizontal, and so forth.

[0]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...

Interestingly enough, even that is out of date with respect to block and inline layout--CSS3 writing modes make block and inline layout direction-agnostic as well.

Ok so given the example, you have a media query for a smaller screen and you switch the direction to be column.

Would it really present a problem to add 2 more lines of code to change hor-align and ver-align to be different if need be?

In the example, they don't even use justify-content and align-items frankly.

The trade-off seems to be that you define a flexbox and let's say define the elements to be spaced out evenly horizontally on the page and when you flip it to be a vertical layout - now they are spaced out evenly vertically.

Except you probably don't want that, so you're going to be redefining these justify-content and align-items based on row/column directions anyway so what are you winning by having it confusing and direction-agnostic?

In the real world, we scroll vertically and read horizontally in most cultures, so WE are not direction agnostic. Why flexbox is, is beyond me.

Granted, I haven't extensively used it - it could be that there's hidden powers that add complexity that I am not appreciating at this time.

The model of flexbox is that items are layed out along an axis, and justified/aligned along the axis and the cross axis. The axis can be vertical or horizontal. This is not an immensely complex model, and in fact makes a lot of sense.

As for doing alignment with explicit horizontal/vertical specifications versus based on an axis direction, I can see advantages and disadvantages of both, but no pressing reason to prefer one over the other. I don't know what the discussions about this were like, or what compromises are involved.

In my opinion, your finding the names of these two properties somewhat hard to remember doesn't discredit the whole layout model as much as you seem to think!

Me, I'm just glad to have a better way to do layout. I switched our basic layout (a full-viewport web app, similar to the "holy grail" layout) from absolute positioning to flexbox earlier this week. It's been quite pleasant to work with, and I can see it saving quite a bit of time in the future.

I'm with you, flexbox is definitely a step in the right direction.

It's not so much the naming as it is just wrapping your head around these things. The flexbox spec for instance uses margin-left: auto; on one of the children elements of a flexbox to align the element to the right!!! edge.

What in the world...

Here's the link: http://www.w3.org/TR/css3-flexbox/#auto-margins

That can't be right, and yet it's in the spec.

What happens when you want the elements on the left to be centered but have one element on the very right? Oh that's right, that whole example no longer works.

It's these hacky solutions that ultimately drive me crazy. Look at sticky-footer: https://philipwalton.github.io/solved-by-flexbox/demos/stick...

The footer is not at the bottom of the page if you copy-paste his code. What in the world...

You have to run around until you come upon needing: html, body { width: 100%; height: 100%; margin: 0; }

for the footer to actually be on the bottom of the page like a footer should be. What on earth is the value of width and height by default if not 100% btw? Lol...

I don't even remember how I came upon that but it's not in solved by flexbox and not on the mozilla site. Which makes me think wow, have these guys even written a layout with a proper footer and a content area that doesn't have a hard-coded height?

That's what mozilla has, a hard-coded height in their fkn example of using flexbox. So when you try to change it to be stretchy, nothing works because you need the line above. Joke...

Anyhoo it's Friday, I need a drink :) Sorry for the attitude.

I agree that the syntax isn't great. But you'll memorize it after a few times. The semantics however are pretty good.

Would it be overly pedantic to point out that the syntax is CSS syntax? You seem to have an issue with vocabulary and semantics, not syntax.

Good point, thank you :)

I'd argue that creating an element that has size dependant on the size of something somewhere completely different is not something you should be doing anyway.

As others have mentioned, being able to switch the orientation of the principle axis is very helpful, for example when going from a row to a column on mobile. Because all positioning is defined based on the principle axis, all the styles translate correctly, and you don't have to override 4+ different rules.

> How do I box 1 height stretch? Hm... I don't intuitive know.

If you understand how align-items aligns everything else along the secondary axis, then "align-self: stretch" seems pretty intuitive (http://codepen.io/conlectus/pen/WvGLvy).

> re: 1em margin breaking alignment

I'm not sure what you're referencing here, as it seems to not do that http://codepen.io/conlectus/pen/WvGLrK

A guess would be that you don't have box-sizing: border-box on all elements set.

Adding "flex" always makes the element take up as much space as it can, and the number specifies how much "force" it applies compared to other elements.

Minor nit: You mean "principal axis", not "principle axis". Principle is a noun, not an adjective.

What is horizontal and vertical? Why should they be absolutely defined?

Exactly. Damn thing applies to a whole CSS, but you would think that in the year 2015, when all that "web was flawed at embryonic stage of development, but it's kinda hard to fix it, when you noticed 20 years later, when it's grown into a huge monster" thing became sort of legendary, they would be more thoughtful of designing APIs.

But it seems that w3c has something in common with war: it never changes.

A very nice realtime flexbox simulation. http://flexboxin5.com/

Yes, that's a very nice visual introduction to what's possible with flexbox.

It's worth mentioning that the flexbox standard has gone through three major revisions, each with very different syntax. To extend the usefulness somewhat to older browsers it's possible to mix the different versions.

See this article at CSS-Tricks for some examples https://css-tricks.com/using-flexbox/

Also worth mentioning that you can avoid having to deal with most of the problems of the multiple syntaxes if you're using sass by using bourbon's mixins - http://bourbon.io/docs/#flexbox (or you can just not care about < IE11...)

I certainly wonder what has gone wrong at W3C that resulted in the situation that the world's leading layout language didn't support proper vertical centering for several years (to give an example). How could this possibly happen?

My favorite misconception! CSS 2 does support vertical centering. Google "absolute centering". I had to implement the chapter and verse that explicitly describes vertical centering...

I think OP's point was that the trick to vertical centering involves wrapping a div as a table cell and then vertically aligning that. It should be much simpler, like 'text-align:center'

Why would you want to do that? That sounds absolutely horrific.

Just center the div in absolute mode. You need to have it wrapped in something though, to have something to center against, but you shouldn't have tables in there unless you want them.

The point remains that centering vertically with absolute positioning does not work with an element of variable height. Meanwhile, horizontally centering something of variable width is dead simple. Why the difference? It's a shortcoming of CSS.

There is a fundamental reason for the difference: in standard CSS block/inline layout, widths depend on parent widths, but heights depend on child heights. Far from being stupid, this difference is the entire reason CSS is parallelizable at all.

Flexbox makes this simpler by switching to an entirely different model, which is the right approach for UIs (as opposed to documents). But I can't really fault CSS 2.1 for not introducing flexbox right away, because CSS 2.1 is complex enough as it is.

Are UIs and documents so different?

Use margin: auto and absolute positioning to center something vertically. No tables or special magic needed.

I think "margin: auto" maybe should have been written "margin: center" to make it more obvious, but the feature is there.

Absolute centering only works when the element you are trying to center has a defined height. If you are trying to center an element with unknown height inside a container with unknown height, the table-cell is likely the front-runner, sadly.

I like the translateY(-50%) trick. But yeah, it is a pain point. Hence flexbox.

People always suggest margin auto but at least for me having defined heights for elements is the very rare exception.

http://howtocenterincss.com/

I think the need for an entire domain to explain to people tricks to make it work rather supports the original point.

Another one to check out if you (like me) don't get how to use it just from reading about it: http://bennettfeely.com/flexplorer/

Just started a test project using flexbox and I'm finding myself using it constantly.

In the "individual grid sample" why have you chose to make a 2/3rds and 1/3rd column with divs respectively

    flex:1; width:33.3333333%

instead of leveraging the ratio

    flex:2; flex:1

I'm not sure I'm looking at the example you're looking at, but generally: a Flexbox layout will defer to the content, where when you're laying out on a grid, you want the content to defer to the grid. By giving an explicit width, you tell the browser that, in this case, the specified width is what's most important for the layout.

I see, That makes sense thankyou

Luckily, this is built into the flexbox model too. By default flexbox uses an element's automatic size as the basis to calculate its new size from.

However if you set flex-basis to zero then it will treat the element as if it was zero width for the purposes of calculating its new size from.

So if all elements have a zero basis then the flex ratio will be the only thing affecting their final width:

http://codepen.io/anon/pen/WvGLML?editors=110

When you use gutters sometimes the math doesn't work out quite right. http://codepen.io/anon/pen/xGEMYY

Then there is the leading dots as commonly seen in tables of contents http://jsfiddle.net/hmquvmvp/

I'm actually kind of pissed that flexbox solved everything but horizontal masonry layouts. This layout has been javascript-bolstered for years now and it sucks there's no pure-html solution. You can do google-images-style layouts (right-to-left, fixed height, variable width) but pinterest-style (right-to-left, variable height, fixed width) is impossible and requires (slow) javascript.

If I'm wrong, I'll gladly take 100 downvotes in exchange for a link to a resource that has flexbox-driven horizontal masonry instructions.

Something like this?

http://demosthenes.info/blog/844/Easy-Masonry-Layout-With-Fl...

That is a vertical layout. It goes top to bottom, not left to right:

    1 4 7
    2 5 8
    3 6 9

So, no, that doesn't solve the problem.

Ah, my bad! I was a bit focused on "Pinterest style" and shared the first thing that came to mind.

No problem. I saw that post a few months back and thought "wow, finally!!" but once I implemented it I realized it wouldn't work. Unfortunately going from vertical to horizontal requires fixed height flex elements.

Very impressive gallery of solutions, and nice to see the absence of CSS hacks in those solutions.

One thing to help complete the story: could this page link to a flexbox polyfill for older browsers?

This is exactly what I need. Does a polyfill even exist?

Here's a highly interactive flexbox demo, done using re-com, a Clojurescript library that uses react.

http://re-demo.s3-website-ap-southeast-2.amazonaws.com/#/h-b...

Definitely try out the Show me: on the bottom. Also try checking out the checkboxes in the gray box, as well as changing the values.

Flexbox is great. Now we just need to wait a couple of years for 99% of the active browsers to be upgraded. I know there are shims but I cannot imagine they don't come with caveats. Web development has come a long way but it's a slow process. Remember when we had to support IE6. (shudder) Now most people are ditching IE8 but 9 is still common.

Saw a post on stackoverflow the other day where the OP justified in comments that their client had 7% IE7 users.

Browsers are getting upgraded in general, but you still get government-x and company-y asking for IE7 support.

Sometimes IE7 statistics based on user-agent strings is unreliable.

We have a phantom measurement of 3% IE7 usage when the actual usage is 0% (our web app prevents IE7 users using JavaScript because it is too broken). The measured IE7 users are actually using IE8 (as a control embedded within a Windows exe, actual usage measured using @cc_on @_jscript_version).

What layouts does Flexbox solve that Cassowary[0] or GSS[1] layout doesn't?

[0]http://en.wikipedia.org/wiki/Cassowary_(software)

[1]http://gridstylesheets.org/

For a start, flexbox doesn't require JS.

I meant more as in Layouts. Anyway, cleared that miscommunication.

Built-in browser support

That's kinda only true at the moment.

With https://wiki.css-houdini.org/ there is a chance you could implement custom layout in CSS.

As another user says, no js.

Pure CSS runs in the browser without a get request (other than the CSS file you are already using, obv.) so it eliminates the need for a grid system like Bootstrap, 960gs etc. The 'grid' is there in the CSS and html where it is meant to be, without the need for @media queries with 10 decimal points and 15 font sizes. It also provides more layout options than currently exist without the need for hacky solutions.

How useful the linked site is right now is questionable though. If you want a IE8+ cross browser & mobile site to rely on flex-box ... it can be done and quite easily, but not with the skeleton examples on that page (but they do point that out themselves).

I'd like to read more about flexbox, any link you'd recommend? Especially backwards compatibility and the cross browser/mobile you are mentioning are something I'm interested in. Thanks

http://caniuse.com/#feat=flexbox

https://scotch.io/tutorials/a-visual-guide-to-css3-flexbox-p...

https://css-tricks.com/snippets/css/a-guide-to-flexbox/

https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...

Here is some extensive discussion on that very issue: https://twitter.com/nikitonsky/status/561941079038390273?__h...

Basically, constraint solving is harder to understanding, doesn't support wrapping, and is slow.

This is the kind of response I was looking for. Though I have to ask, is this specific to Cassowary.js or to Cassowary constraint solver in general?

Because from what I've seen/heard, the Cassowary constraint solver is used extensively in Mac OS X/iOS for UI layout, which AFAIK isn't really referred to as slow.

Plus the constraint solver does operate on a matrix of constraint, which should make it easier to work on GPU.

GPU based Web page layout has so many practical hurdles to overcome that the fact that Cassowary can be described in terms of a matrix isn't relevant.

There's no reason why constraint solving wouldn't work just as well in the browser as AutoLayout works on OSX/iOS if it was natively implemented.

It is not natively implemented however. Also, to take it further, Cassowary.js could solve for and output to flexbox as a backend.

Autolayout is very slow compared to manual layout on iOS. It limits the complexity of the UI you can build, especially if you need to update the layout at the display's refresh rate.

All these things may be solved by flexbox, but they were also all solved by tables 20 years ago.

After re-assessing our analytics a couple of weeks ago, we decided it was safe to drop support for IE9 and below. Since then, we found ourselves using more and more Flexbox for layout. Just a simple thing like vertical centering becomes much easier with Flexbox. The sticky footer technique from the website (https://philipwalton.github.io/solved-by-flexbox/demos/stick...) is also something that we use on the Hstry application.

Thank you, thank you a million times.

I've recently looked into flexbox for a project I started, but all the examples and stuff out there seem very ambiguous (compared to the amount of time I'm willing to invest. I just want things TO WORK). But looking at those docs again with this will help my understanding heaps.

Flex was working out a lot better for me some ten years ago, in Mozilla extensions, as it was. There's just too many rendering glitches and performance problems with flex nowadays, so I've moved on to scripted layout. I just felt that someone should say it.

Can you elaborate on this? What rendering glitches did you encounter?

There's one right now where a combination of flex and transform3d will cause things to simply disappear in Chrome and Safari but I haven't searched for any issues reported on that. The problem is progressively getting worse, so I'm almost sure you'll encounter it if you play around with those properties. I'm unfortunately not in a position to elaborate much further in this exact moment - but if this only happens to me, I really couldn't be happier!

I think I actually had a similar problem, but using `filter`. Don't really remember though.

Try writing idiomatic Flex rules based on the latest spec, and then running through PostCSS Autoprefixer. It smoothes out nearly all of the cross-browser glitches.

What performances issues are you talking about?

Well, I made some code that would emulate flexbox in IE for a specific HTML structure (it would parse classnames in the HTML and not the CSS, the code is still around on https://github.com/wiredearp/spiritual-mix/blob/master/dist/...) but it turned out to run about a hundred times faster than the associated CSS flex that other browsers would use; even in those browsers. The layout must aspire to a certain complexity before it happens, that's why you don't notice it at first (and why I posted the comment). I just checked back with the issue called "Catastrophic flexbox perf" over on https://code.google.com/p/chromium/issues/detail?id=331352 and it appears that it's now a lot better in Chrome, but you can try to Ctrl+F for "hosted demo" on that page and open the demo in Firefox (you should save your work first!). When the page eventually does appear, you'll see that it's really nothing special, and certainly not worth the wait.

Exact opposite experience. I like the newest CSS spec, and it is now supported in the vast majority of stable browsers in use.

It is an elegant approach to very common layout problems without any libraries, plugins, or javascript.

The whole point of markup and CSS is to solve the layout stuff for you. Javascript should be mainly for data transformation.

When you throw in web components and two-way data binding via object.observe, we can approach this ideal separation of concerns.

I spent more than an hour and a half yesterday trying to get a sticky footer working in a non-hacky way. This morning, using the technique described here, it took me less than five minutes and it involved no hacks or trickery. Thank you.

Flexbox seems to serve most HTML layouts. Are there any that it doesn't work so well for? What about CSS Grid Layout? I've not heard anything about that for a while. Does that have any advantages over Flexbox?

It seems the CSS Grid Layout needs far less divs to accomplish the same layout. With Flexbox you end up creating a lot of parent elements to layout the content elements correctly. With CSS Grid Layout you can express the layout more precisely in the CSS, so there is no need for a lot parent elements.

I have lots of examples of grid layout over at http://gridbyexample.com (you need Chrome with Experimental Web Platform features flag on to view them)

Used this in my presentation on React Native the other day (http://brentvatne.ca/react-native-intro-talk/) as it demos beautifully how Flexbox fixes some persistent CSS layout problems, thanks!

With vjeux's css-layout library, adoption from React Native on iOS and Android and mentions of perhaps adopting it in AsyncDisplayKit, Flexbox is becoming a valuable layout system to be familiar with.

I came up with this very minimal implementation of flex box. Basically defines row or column, their content can be centered or marked as tight to keep from dividing the cell evenly. https://github.com/chrisguilbeau/quickflask/blob/master/s/fl...

Thank you for this. I was just wondering how I should approach a full-height column next to a center-aligned image (http://images.apple.com/osx/photos/images/powerful_editing_t...). Flexbox seems to be the answer

This is awesome! I've been building an app with a grid that scrolls horizontally and this is the best solution! Getting this pattern in html is really hard:

      1 4 7 10
      2 5 8 11
      3 6 9 12

Other than than columns, which dont respond the screen size that well, this is the only good option. Thanks for educating me!

Sadly, Flexbox kills the joy of commenting on the "How to center X in CSS" that periodically appears on HN

Sadly? Good riddance I say. There's so much textbook cynicism here.. the more we can get rid of the better!

I suspect flex-time will be coming sooner than expected. flexbox is amazing!

I've used it everywhere on two production website, and we have had close to no issue with it. I'd say it's quite safe to start using them now.

Sorry for my laziness, how does this compare to Bootstrap?

Bootstrap is a CSS framework and the flexbox layout is a CSS module, so you can't really compare them.

Do they not provide comparable functionality?

It's analogous to asking if jQuery provides comparable functionality to JavaScript ES5 enumerables. It does, it's just a strange comparison given that the former is a library built on top of the latter language, using a different API due to the former predating the spec

Honestly a Bootstrap / Semantic UI style system that implemented Flexbox would probably be the best thing for making Flexbox more popular.

Older browsers dying so we can actually use Flexbox on sites that have to work back a couple versions will probably help even more.

Didn't seem to work that well for the "Pure CSS" library that Yahoo made, which uses Flexbox.

Nice work Phil!

Cool

spacer.gif

a down vote for "spacer.gif"? kids these days, just don't remember

Please note that the HN community takes a rather strict approach when moderating comments that contribute noise to the conversation. "Nice article!" comments are routinely downvoted. As is sarcasm, witticisms, memes, references and other styles of comments that occur frequently but do not contribute to the discussion. It's a knowingly doomed attempt to hold back the flood of noise that covers Reddit.

As it should be!

The ubiquity of the "funny == upvote" mentality is rather depressing, and I'm glad that HN (generally) tries to avoid that. It makes the comments section a much more interesting place to be (to me, at least).

Reply on news.ycombinator.com