4 ms·

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 swi

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.

sondr3 11y ago
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.
- alexashka 11y ago
  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.
  - pcwalton 11y ago
    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...
    - alexashka 11y ago
      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?
  - woah 11y ago
    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.
    - alexashka 11y ago
      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.
mbrock 11y ago
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/Flexible_boxes https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...
- pcwalton 11y ago
  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.
- deleted 11y ago
  [deleted]
- alexashka 11y ago
  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.
deleted 11y ago
[deleted]
woah 11y ago
I agree that the syntax isn't great. But you'll memorize it after a few times. The semantics however are pretty good.

sondr3 11y ago

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.

alexashka 11y ago
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.
- pcwalton 11y ago
  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...
  - alexashka 11y ago
    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?
- woah 11y ago
  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.
  - alexashka 11y ago
    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.

mbrock 11y ago

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/Flexible_boxes https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...

pcwalton 11y ago
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.
deleted 11y ago
[deleted]
alexashka 11y ago
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.

deleted 11y ago

[deleted]

woah 11y ago

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