You can't work out the logical consequences of seemingly obvious properties. That is unlike 95% of most programming I do in any programming language I've ever used. Since I have zero interest in learning unintuitive interfaces to GUI design, I have zero interesting in excusing CSS. It is not difficult to learn, it is not difficult to understand in terms of conceptual understanding, it is downright tedious to learn though - and you don't get anything unique out of it that can't be done in anything else: you get a nice looking website. Amazing.
Probably because very few learn CSS right. In particular: the box model.
All the devs I know that struggle with CSS don't understand it. The ones that don't have issues have internalized it and don't need to think about it much anymore.
The box model is one of those fundamental building blocks you really should be learning very early on, a bit like an "if" statement in imperative languages - you can hack around it with ternaries and single-iteration loops, but you're never going to be as effective or have as strong an understanding of the language as you should.
I keep seeing this excuse, "If you don't like CSS you must not understand the box model". The box model is easy to understand but it still doesn't make CSS good.
This is more like saying you don't need to learn algebra and then saying you hate math because it takes too much work to get the answer you need. A surprising number of developers are under the mistaken belief that not learning how the web works is saving them time and over the years I've been amazed by how many people will instead unquestioningly spend years playing bug whack-a-mole with megabytes of JavaScript sturggling to replicate built-in behaviours.
You've said everything I wanted to say but I wasn't able to express. CSS is nothing like programming. I am a decent programmer and I can write actual code in virtually any language that's new to me, in minutes. CSS is always tedious and God forbid I don't use it for a couple of months - then I've got to go back and re-learn everything. I'm on my fourth round of re-learning about CSS because I'm not purely a front-end developer.
For me the hard part is remembering all the arbitrary rules and special conditions. Most tech "makes sense", once you get it it has system that helps you to remember stuff.
Css has semblance of system, but mostly it us a lot of rules with no rhyme slapped together.
Though any self-respecting web developer should sit down and learn CSS.
Part of the problem with CSS is that we seem to relegate it to something we don't need to learn. "Well, it's just CSS. I'm a developer!" And then we complain when we don't understand it or when our jerry-built sequence of StackOverflow copy-and-pastes is a clusterfuck to deal with.
I myself realized I was working off knowledge I read in a CSS book I read in 2004, so I committed a week of updating my knowledge on my own. I realized very few people actually do that, as I'd easily gone 15 years without doing it, and even with my 2004-level knowledge of CSS I'd always be amazed when a fellow 30-yo web developer didn't know how you can offset absolutely-positioned children inside a relative-positioned parent or something just as entry level. Just like, until recently, I'd probably amaze someone that I didn't know what the rem, vh, and vw units were.
It's a terrible waste of time if you can find a good alternative. Luckily Elm-UI is exactly that.
Edit: of course it's worthwhile to learn enough CSS to understand more or less what it does since it's so pervasive. I mean that using it as the main way to lay out pages is a frustrating experience in many cases.
My point is that there's nothing in CSS that's exceedingly difficult to understand once you sit down to learn it - it's that you're often sitting down to learn things that are entirely idiosyncratic to CSS and act as impediments to creating anything beautiful. I could abandon CSS and use SVG to create prettier things pretty quickly, because although SVG has some gnarly parts, programmatically manipulated it makes much more sense. CSS is designed to solve different problems to the ones I often want to solve in isolation - i.e. it's document oriented as opposed to element oriented, if that makes sense. Then I'm dealing with the interaction of specific elements and document flow and everything is liable to fall apart the second some mismatch between my mental model of layouts and CSS's actual model occurs. At least it's getting better, as gradual as it is.
> Then I'm dealing with the interaction of specific elements and document flow and everything is liable to fall apart the second some mismatch between my mental model of layouts and CSS's actual model occurs
Here lies the problem. If you fix your mental model, then your layout won't fall apart.
It's the same as in any other language. Haskell doesn't match my mental model, but it's not the programming language's fault.
Haskell's problem is that it's so consistent (e.g. in enforcing purity, to the point of frustration for common tasks), if you don't understand it, you won't get anywhere. CSS's problem is rather the opposite - or if it's consistent it's consistent in its own, rather frustrating way. Mathematics may not be how we inherently reason, but I feel good having solved a problem in Haskell. I feel bad having solved most problems in CSS.
SVG is simpler than CSS because it doesn't tackle the inherently difficult problems of adapting typography and layout to a wide variety of devices and aspect ratios. It is simpler in the same way it is simpler to create a PDF than to create an adaptive layout.
SVG is just scalable vector graphics, like Postscript which is the basis of PDF.