Hacker News Reader

Comment by b450 | Hacker News Reader

Wow, all these "why is this still so hard" complaints feel so off-base to me! As the article says, Flexbox straightforwardly solves centering in every simple case. When it doesn't solve it for you, you're doing something more complex than _just_ centering, so it's inappropriate to expect that the implementation will be dead simple.

View on HN

It's because for those of us who have been around a while, it was hard before flexbox, then it continued to be hard when flexbox didn't have 100% support and we kept having to track browser usage and deciding whether we could use flexbox or not, and now there are just so many ways to do it that it's an overwhelming amount of complexity. You're often not building something from scratch but rather updating old code, and having to figure out why the CSS was done in one particular way for what reason, and what might break in which edge cases, and whether you should/can update it or not, and which one of several solutions when it's not simple.

If you look through the article, none of it is intuitive. Even with flexbox, the horizontal setting is called "justify-content" while the vertical is "align-items". I personally simply can't remember what a lot of CSS properties are called anymore -- there are so many now, and the names are so arbitrary. (Even hyphens are maddening -- why is it "white-space: nowrap" instead of "whitespace: no-wrap"?)

At the end of the day, there's a big difference between:

1) Simple, intuitive, reliable building blocks that let you build complex solutions out of simple parts

2) Convoluted, partially-overlapping, constantly-needing-to-Google building blocks that let you build complex solutions out of complex sets of parts

A language like Go or Python is #1. A language like CSS is #2.

justify/align and content/items have specific meanings and the 'intuitive' naming most people expect - horizontal, vertical - completely betrays the powerful elegance of the flex model.

justify always refers to the main axis of a box model element, and align refers to the cross axis. by default, flex-direction is set to row, so justify often means horizontal and align often means vertical.

until it doesn't of course. when we switch tbe flex direction from row to column which is a very handy trick for easy responsive on small devices, the main axis is now vertical and the cross axis is now horizontal.

There's just always going to be confusion because both pairs are basically synonyms: justify and align; items and content (what's the content of a flex container? flex items).

I buy the value in having them be main-axis and cross-axis properties rather than horizontal/vertical by name, but I don't know that I buy the justify/align distinction to represent that as being meaningful or memorable.

It's very easy to remember all this, if you can just memorize the acronym AMIJAMITCOE ("Ami-Jamit-Coe"): A monad is just a monoid in the category of endofunctors.

Its similar with changing "left" and "right" to be "start" and "end" because we built in a lot of assumptions with LTR languages that don't apply to RTL.

My mnemonic for justify vs align is to picture the "justification" options in a word processor. you can justify content to the side of the primary axis when it's written right-to-left. so, justify is main axis, and the one that's not justify (align) is the one that's not main axis (cross axis).

What I don't remember ever is does flex default to row or column; so I write a lot of unnecessary `flex-direction:row;` but if you are fine with always specifying a direction, the default doesnt really matter either.

Which is even more confusing because that's not the terminology used in word processors.

Word processors have four modes of alignment -- left, center, right, and justified. Justified means stretching out to both edges.

There's no such thing as justifying content in a particular direction. And justifying something to the center is purely nonsensical.

They could leave the elegance by calling it align-x and align-y and turn-right. Or make them independent of “direction”. Or allow both ways so people could use them in corresponding situations. Instead they chose to satisfy the most useless case of a pseudo-turnable container, which makes zero sense.

For comparison, here's WPF that shipped in 2006:

   <Button HorizontalAlignment="Center" VerticalAlignment="Center"/>

(and you can write styles that apply these to groups of elements based on criteria etc)

I don't know, I constantly need to google how to work with package management in Python

Flexbox is what I always wanted CSS to be, but for a long time wasn't, until one day it was, and we could drop support for browsers without it. Feels almost end-game for CSS.

There was a reason people loved Bootstrap's grid system so much, Flexbox does all that and more straight in your browser. Cannot over-express how much I love it.

I too love flex but your comment is a bit off. bootstraps grid system is a fake grid modelled on flex. building layout grids with flex in general is definitely not endgame, its actually very tedious and unreliable.

css grid however is perfect for this and represents one of the most underutilised powerhouses in the css kit

I remember when bootstraps cols were implemented using float.

I haven't really found much use for CSS grid. It's fine if you're doing a strict grid, but it seems to have all the limitations of a literal table to me. You can't put two objects in one cell. It has no way to wrap. It just isn't responsive at all. You can't make a sidebar with grid. You basically have to just write multiple styles and switch between them with media queries.

In practice, I find making a fake grid out of flex boxes much more usable. About the only thing grid does easier is letting you place a footer correctly. (Although you gotta make sure you count elements correctly because if you insert an extra element before your grid's footer, it will be rendered after.)

you can do everything you just mentioned with grid more reliably and by writing significantly less css than the flex method.

Grid also doesn’t break in media print. Neither does flex, but at least you can make a div of flexes, so that div breaks.

Yep, there was a time when it was moderately difficult in certain cases, but it's been a solved problem for the last decade or so. You still hear people acting like centering DIVs in CSS is something like a cross between alchemy and rocket science, which is perhaps indicative that people don't follow CSS with the same attention as other parts of web development—yet they still feel comfortable making these statements!

And on top of that, flexbox has been widely supported for over a decade! The comments here are a wild ride.

This is super true. Whenever I find myself struggling w/ flexbox it helps to take a step back and solve it one step at a time. Working my way out-to-in, parent-to-child element, and it becomes so much easier. There's a skill to it, but it's basically just elastic algebra.

Having to use flexbox already feels like we're shooting a fly with an elephant gun, is the thing.

Everyone expects it to be as simple as <div centered> and everyone is surprised it isn't. That's a pretty universal experience in web development.

Do you want your div centered vertically? horizontally? both? Relative to what? the window? the container? These are just some of the common questions that are asked every time you need to centre something. A simple attribute cannot work.

It worked exactly that way with tables, attributes align and valign:

https://www.geeksforgeeks.org/html-td-tag/

Tables only ever "worked" when compared to the poor implementation and browser support of the alternatives of its time.

In today's web landscape using tables to center categorically fails to work in many scenarios that will work with flexbox.

They worked great and still do for the vast majority of use cases.

The fact it took over two decades to surpass is not a compliment at all. Considering "internet time" (first identified in the 90s), it's a disgrace.

> Relative to what? the window? the container?

I don't think I ever wanted things centered relative to anything other than the direct parent, no matter what that is. I am sure some cases need it differently, but I don't see why those should prevent intuitive defaults.

> A simple attribute cannot work

Can it not work at all or just if one insists on covering 100% of cases on the internet with a single comprehensive option? I'm not an expert in this so I'm not sure, but I've seen a lot of software center items automatically and it worked quite well because they didn't assume by default that I might push the boundaries of design to new heights at any moment.

`<div centered>` is the same thing as `<div read-my-mind>` since there are so many variations of what you might want. And once you generalize the solution around those variations, you have something like flexbox.

For example, what does `<div centered>` do when there are two children? And what do you do when you want the opposite behavior?

> For example, what does `<div centered>` do when there are two children?

Force me to use the advanced option or to wrap the two children in a centered container? I am certain this wouldn't cover many, many edge cases, but they are called edge cases for a reason.

Edit: People can complain about tables etc being the wrong approach all they like, in the end those examples are only proof that the proper way could be at least as simple for the average case.

It takes the sum of two children’s intrinsic sizes with a margin between them and centers the bounding rectangle as if it was a single object. Flexbox does the same, and I didn’t even think of it while writing the previous sentence. But somehow you didn’t have the same read-my-mind complaint about flexbox.

Because flexbox picks a default when you give it no configuration but it lets you configure it, so it doesn't need to read my mind and it can be wrong every time.

Now show me how you change spacing/centering behavior with the proposed <div centered> and you'll finish out the point of my previous comment.

Contrast the need to use flexbox with the ability to just specify bold or italic style, or for that matter use <b> or <i> tags. You basically get what you want every time. Nobody has to argue about whether the italicization is the right slope, and while you can select a particular font weight if you want to, bold is bold and is fine for basically everybody.

Hell, I would argue that centered table contents gave people what they wanted most of the time, and if it didn't you could fix it by adding more tables. Tables composed quite nicely and gave you something if you just laid down a table and some TDs.

Flexbox doesn't scale down the way tables do. I have to have both the container and elements inside that container and think about the ramifications of all of that. It's minimum level of complexity is a higher floor than most of the HTML specification.

That's not to say it's the wrong solution for the problem; I think a case can be made that the problem itself is irreducibly complicated. But that's why I say it feels like using an elephant gun relative to much of the rest of the spec; I have a "read my mind" option for bold and italic.

grid and flex were very nice semi malleable additions, they really lift the legwork and in the 10% of complex cases you can spend your brain time with joy

Reply on news.ycombinator.com