I kinda like it (although some things could be even a bit more powerful), yet everybody I meet tells me how horrible and hard etc it is. I never had that feeling at all, not even back when I started using it as a teenager to customise my MySpace site.
I cursed at how hard common things like centering a image within a div were, I cursed at the purposeful and ignorant incompatibilities of different browsers, but with CSS3 I was sold, even more so when grid based layouts and flexbox became a thing one could lean on.
The one thing that I miss is a little bit more power when it comes to selectors. E.g. there is no way to select a <p> which has only a <img> as a child, which is coincidentally something that a standard conform markdown to HTML converter will produce. So you cannot — say give your <p> a max-width of 120ch without also limiting the width of the <img> contained within it. AFAIK there is a parent selector planned that might address this if I recall correctly.
There's the experimental :has pseudo-class which appears to be doing what you want [1].
Personally, I'm against adding any more complexity to CSS, though; and :has fundamentally changes the locality/algorithmics and complexity of CSS selector matching. I think if the goal of CSS was to bring good-enough styling to the masses, it has utterly failed to so, yet has left a legacy of overcomplicated and badly specified ad-hoc styling rules that don't compose to a reasonable whole. CSS is what you get if you're starting with a disruptive mindset at a welcoming phase in an innovation cycle, then just can't stop to add features. I personally know several graphic artists who did fantastic professional animations using sprites (and also Flash), yet couldn't make sense of CSS, at all. To become proficient in CSS, you need years of learning a non-type-checked and bogus hell of half-assed and half-implemented bloat. As a Comp.Sci. nerd, I also question the notion (ie nonsense) that "HTML is for structural semantics, and CSS for presentation"; the reality is that HTML, it being based on SGML, has excellent support for vocabulary evolution. I mean, look at CSS: it's an item-value syntax (sans the selector part). In which world does it it make sense that, starting from generic markup with lots of syntactic features (elements, attribute), to come up with yet another syntax for specifying item-values? Specifying hundreds or thousand of microsyntaxes does not an inherently procedural layout system make, and there were much better styling languages for SGML available. To adequately describe layout mechanisms, a constraint-based formalism makes much more sense.
> a legacy of overcomplicated and badly specified ad-hoc styling rules that don't compose to a reasonable whole
Agreed. For instance instead of creating the flexbox display, it would have been much nicer to version it out into CSS4 with center aligns, vertical aligns, and a few other things fixed rather than continuing to add new concept layers and increasing the complexity.
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.
Same here. Most of the devs I know who don't like CSS actually never read the docs, or really understand the box model and padding vs margin, etc. They don't treat it like a real language, and so they hate it. I've even worked with someone even recount that once they read the manual, it got a lot easier!
Of course, I'm a dinosaur. I still don't know nearly as much about flex, CSS grids, etc. but i actually have very few cases where the CSS that worked 10 years ago doesn't work today. Flex just makes it much easier, at the cost of adding multiple ways to do the same thing. IMO there's a real cost there. I try to use it minimally, but newer devs like to start with flex first.
I understand the box model well and I still hate CSS. I just feel like CSS has way too many unique things to remember that have no apparent logic to them.
CSS clicked for me from the very start. It was always fun, I never had problems with it (aside from the browser bugs, of course).
Maybe problem others have with it is not because of the nature of the CSS, but because of people ignoring that nature and refusing to learn it and trying to carry over their experience with other technologies to CSS.
You were never asked to implement a simple three column layout in CSS where the center column expands with the screen size? That’s often the first thing people were asked to do in the early days after being asked to replace the old table based layout. CSS grid/flexbox took way too long to arrive.
I did lot of things, and even had to implement pixel perfect designs in IE5.
Honestly, those challenges were a part of the fun. Not sure I'd want to go through the same again, but it was fun back then.
The :only-child pseudo-class selector property in CSS represents an element that has a parent element and whose parent element has no other element children.
on edit: sorry I got confused and dropped your requirement to select the parent.
You're correct about not being able to target parent selectors without some JS intervention - BUT - if you avoid any property declarations on your default img elements you can achieve what you desire.
> to select a <p> which has only a <img> as a child
To basics, this selector
p > img { display:block }
has O(0) complexity (+/-) - for any IMG element you can instantly tell if the selector applies to it. By inspecting its tag and tag of its parent (any element always have valid parent).
But this selector:
p:has(> img) { display:block }
has complexity O(N) - in order to test applicability you need to scan all N children of the P.
And now consider some JS code that does this
p.append(<img />);
If we would have that :has() feature then that simple statement will force rescan of the whole DOM tree. That will lead to O(N*N) complex updates.
> If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization
Programmers who write browsers do care about such things, trust me. We have plenty of creative Web desickers who are managing to push browsers to extremes already ...
Give me better composition options with css. I will love it. Until then, it is a toxic relationship. I have to use a preprocessor for that and it increases the time to see feedback from the browser.
Don't get me wrong, of course if you'd ask me whether I could envision something better and more elegant than CSS I would immediately have ideas in the back of my mind — however if you'd tell me I'd be stuck with CSS as it is my response would probably be a neutral shrug. It could be better, but it is okay and the direction things are going (CSS variables, Grids, ...) are not too bad either.
People who call it horrible in my experience often just didn't really take the time to learn it properly. For me to handwrite the CSS for a normal sized personal blog takes maybe 6 hours if I do it from scratch with mobile support etc and most of the time goes into little design adjustments that have nothing to do with CSS. As I said: to me it is not great, but it doesn't really get into my way too much either.
Functional css totally changed my perspective on css. In the same way that react made me enjoy writing JS again Tailwind made me enjoy styling with css again. All that nasty coupling disappears.
I kinda like it (although some things could be even a bit more powerful), yet everybody I meet tells me how horrible and hard etc it is. I never had that feeling at all, not even back when I started using it as a teenager to customise my MySpace site.
I cursed at how hard common things like centering a image within a div were, I cursed at the purposeful and ignorant incompatibilities of different browsers, but with CSS3 I was sold, even more so when grid based layouts and flexbox became a thing one could lean on.
The one thing that I miss is a little bit more power when it comes to selectors. E.g. there is no way to select a <p> which has only a <img> as a child, which is coincidentally something that a standard conform markdown to HTML converter will produce. So you cannot — say give your <p> a max-width of 120ch without also limiting the width of the <img> contained within it. AFAIK there is a parent selector planned that might address this if I recall correctly.