[degun]

CSS gets the impression of being illogical, because it’s a bit more complex than it looks. At first, it looks so simple that you think you know all there is to know about it by the first week or so. You think that you can infer what a said instruction will do, just by its nam. But to actually get a hold of it, you have to learn all the concepts that are listed in the article, otherwise you can get easily frustrated.

[emn13]

Is it really complex? I think the real reason it gets this reputation isn't because of any complexity or lack of logic, but rather more simply because it's so opaque. Browser devtools are much worse for CSS than JS; there's no way to ask for an explanation of _why_ a certain value was computed. You can't step through a computation and figure out that well, DUH, there's a cyclical dependency here so of course that won't work, or, DUH, it's using the wrong containing block etc etc etc. Even stuff like selectors are pretty opaque; like you can't easily visualize why a certain selector matches or worse _doesn't_ match, and even trivial concepts like specificity aren't really surfaced in a very helpful way.

It's very much a black box people just fiddle with until it works. But if we had better tooling to explain why selector A matched and B doesn't (relevant in particular for stuff like `.outer .inner` - which `.outer`, exactly?); and why A has more specificity than B; and why and how a certain value was computed (e.g. so that a margin-top of some block is related to a highlightable _width_ of some specific containing block, for instance) - then I bet most people would figure out CSS pretty easily.

Another helpful thing would be if browsers had compiler-style warnings for CSS. We have (bad) CSS linters, but that's partially because it's hard to tell what kind of CSS is problematic "in general" for lots of the tricky stuff that only becomes apparent for a specific DOM. E.g., it seems like a browser should have no problem highlighting which percentage sizes are being semi-ignored due to cyclical dependency issues, but... they don't. Instead they simply pick some fallback which while technically deterministic isn't educationally helpful. There are usually pretty simple reasons why things "don't work" - but good luck finding those, because browsers won't tell you.

CSS is pretty simple, but not simple enough to be immediately intuitive in all cases without some inspection help - and we don't really have good CSS inspectors AFAIK.

[J_Shelby_J]

Debug or a flowchart for computed properties would be amazing for learning.

[dsego]

Doesn't help that there is a lack of internal consistency between properties and that things just got bolted on over time.

[yCombLinks]

Or that the "right way" to do things have changed several times over the years, and you have to figure out if that's the "old right way" or not, because they both are still available.

[spcebar]

The main example I'd give of that is laying out elements. Best practice, at one point, was putting two inline-block divs next to each other, then it changed to 'everything flexbox,' then it changed to 'everything grid.' In my experience, really, you wouldn't lose a job for using any of the three of those, as long as you're being conscious of the limitations of each method, and, in specific cases, each is the right tool for a certain job. Best practices change in lots of languages, and paradigms shift. CSS is flexible, and has always felt a little more like art than science. I get why a lot of people don't working with it, I enjoy writing it though.