Hacker News Reader

Comment by Osiris | Hacker News Reader

I cannot look at a UI design and intuitively know what CSS attributes would generate that exact output.

I think part of it for me is that I do not have an intuitive understanding of the box model and how layouts are calculated. On top of that, since CSS cascades, you have to be able to mentally keep track of all the parent attributes to understand how they affect a specific element on the page.

I was working on a React Native project the other day and I could just not get flexbox layout to do what I wanted. I ended up just playing around with putting attributes on various components until I found what worked.

I have an ADHD brain that quickly discards information I don't use frequently, so since I don't use CSS often, I never remember it well enough to be good at it.

View on HN

> I ended up just playing around with putting attributes on various components until I found what worked.

It's sometimes hard for me to wrap my head around flexbox as well. If you haven't already seen it, this page [0] is imo the flexbox bible. There's one for grid [1] too.

[0] https://css-tricks.com/snippets/css/a-guide-to-flexbox/

[1] https://css-tricks.com/snippets/css/complete-guide-grid/

Also add in flexbox froggy and css grid garden

> I ended up just playing around with putting attributes on various components until I found what worked.

I think that's what everyone actually does when doing CSS.

Even as a pretty experienced front-end developer I would often times ask myself “how the heck will I do this”. A lot of that changed with flex box and then css grid. “gap” especially has made is easier the formulate a plan without just poking at CSS and hoping it works.

That said, pretty basic things like truncating text and making sticky components still trips me up every time.

If you have the liberty to limit your team to a subset of modern CSS features that have predictable behavior and patterns of applying styles (like never putting margins directly on a component, always spacing things from the parent; along with a laundry list of other conventions); and your site is designed to not do weird painful stuff (eg masonry layouts, though that should become a native CSS thing soon!) then I find it’s pretty predictable to do 95% of layouts, and only the weird outliers require special sauce. But then again I do a B2B SaaS that doesn’t need to look shockingly sexy, with lots of standard CRUD dashboards so maybe our use case is light on weird CSS tricks required.

Box model + flex box + the display modes + "positioning" (stacking contexts) are typically the most confusing parts of CSS, I feel.

Add maybe margin and padding, and how they interact (margin collapse, no margin collapse in flex or grid context, box model again, auto values).

But then, that's basically all the hard conceptual parts. But they are mostly intuitive and well-designed! I know I'm alone with this opinion.

Naming + global scope is the rest of the problem, but even without this, here is where the problem of creating design system shows up, too. Harder than CSS probably :)

Something I don’t like about the way grid and flex has been implemented is the seemingly random application of naming conventions. Memorising the differences between justify items and align items, the argument order for repeat including min and max content variables. The odd naming convention for grid area.. There’s a lot going on.

Oh yeah and debugging a broken sticky because some parent has stacking context stuff going on, also fun.

> Box model + flex box + the display modes + "positioning" (stacking contexts) are typically the most confusing parts of CSS, I feel.

That's like 90% of UI. Saying they are the most confusing parts of CSS is basically admitting that CSS is awful to learn and use.

Yeah but I'm not sure if that's primarily a fault of CSS.

I just wanted to enumarate the "hard parts".

But even if I were to agree, what layout and "styling" language or API is the easiest, most logical and well-designed one in your opinion, that still covers the same variety of use cases? From print-like simple layouts to all complicated, nested application UIs for all imaginable screen sizes?

Just curious, I'm not writing that much CSS anymore and I have cursed at it as well.

But I feel it is also powerful and sometimes, yes, even beautiful to use.

Often things that bother people are a feature at the same time, e.g. visible overflow by default.

whose fault is it then?

We had desktop UI's in far simpler forms years before. Yeah, sure, there are new requirements, but those requirements didn't actually need the complexity of modern CSS.

modern CSS came about because people like to be fancy. You value the wrong thing, you get the wrong thing.

I've found people have the most trouble taking full advantage of the cascading feature of css.

Not a flex —and that wasn't an intended pun— but when you've been doing it 20 years, all you see is layout-modelling options.

Getting good takes practice. Lots and lots of practice.

Skill issue

Reply on news.ycombinator.com