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.

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:

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.

> 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/

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.

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

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.

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...

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.

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

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