Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: