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.
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.
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!
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?
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'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).
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.
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.
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:
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.
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.
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.
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).
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.
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
X
-
X
-
X
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.
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.
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 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.
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.
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.
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...
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.
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.
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'
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.
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.
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'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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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 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.
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.
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!
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
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.
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).
https://github.com/philipwalton/flexbugs
A community-curated list of flexbox issues and cross-browser workarounds for them.