8 ms·

CSS sucks because we don't bother learning it (2022)

• busterarm 10mo ago
  I saw @fat's Cascading Shit Show talk. the "it" you have to learn has constantly been a moving target. That's its biggest problem.
  • shadowgovt 10mo ago
    Which wouldn't be so bad if it were a language built of small atomic values and transformations atop those values, like most programming languages. Then you don't have to care that, say, an entire new language for flexible layout exists because you've written your layout core and transformers on top of those atoms and it works fine. It's not. It's a declarative language where the declared intents are extremely high-level and can interact in surprising ways (credit where it's due: modern CSS has almost all those interactions well-defined and considered; it was much worse when the answer to how two pieces that were independently designed interacted was "However the browser feels like they should interact"). As a result, to really be deeply fluent in it you have to keep abreast of design trends (dialog boxes! scroll state! custom corner shapes!), and that's not every programmer's cup of tea. (To be fair: there are really good tradeoffs here. Especially around accessibility: a declarative language where high-level intent is the main element is much easier to answer questions around, say, "How will a screen reader interpret this" than a low-level atoms-and-transforms language. Othewise, your screen reader has to be able to guess things like whether that set of SVG commands and transforms is supposed to be the corner of a dialog box or a very fancy letter 'C').
• nailer 10mo ago
  You can prove that most people don't learn CSS using most LLMs: they're trained on github code. A card with a top image, some text and a button - which should be... - A card - A top image - Some text - A button ie 4 HTML elements, ends up being about 10 HTML elements with various strange hacks in the div-soup HTML the models have scraped from Github. Then someone else comes along and uses tailwind, because naming 10 arbitrary HTML elements (rather than .card, .card img, .card p, .card button or similar) is hard. They're right, but the problem is they didn't need that many elements in the first place and wouldn't if they'd just learnt CSS.
  • moi2388 10mo ago
    I couldn’t agree more. Tailwind isn’t a solution, it’s a symptom.
  • icedchai 10mo ago
    This matches my personal experience. I am primarily a backend developer. Can you recommend a book that teaches CSS the correct way?
    • Tomte 10mo ago
      „CSS The Definitive Guide“ or „CSS in Depth.“
    • nailer 10mo ago
      I’d spend time on the CSS Grid and Flex playgrounds. Get used to creating layouts using grids and padding and gaps, leave block elements and margins to actual writing.
  • h_ko 10mo ago
    So much this. The amount of unnecessary divs created by LLMs are an abomination. Let alone the blatant disregard for any semantic elements. Took a lot of strongly worded instructions to get rid of the bias for div-span-spaghetti, and it still slips in entirely superfluous elements.
    • CPLX 10mo ago
      LLMs are the new FrontPage it seems.
  • Levitz 10mo ago
    Is turnabout fair play? https://chatgpt.com/share/695be6f6-3188-800f-b2b0-e07cb196b6ab https://chatgpt.com/share/695be6f6-3188-800f-b2b0-e07cb196b6... CSS has gotten much, much better, which is why it doesn't suck so much these days, but come on now, using a div with a background image was a common practice. There were like, what, 3 different hacks to center an element inside another? People don't just opt for a plethora of different tools to deal with it "just because".
• deleted 10mo ago
  [deleted]
• phoronixrly 10mo ago
  Well first of all CSS is complicated. Second, it changes constantly. Third, there are no widely-used conventions and best practices. You are either a full-time front-end dev and have a chance to keep on top of it, or you do not know CSS, and are now blamed for it sucking. To garner that, many people just want a simple UI that is not ugly -- not everyone wants a web design masterpiece, thus they 'don't bother learning it'.
  • yoz-y 10mo ago
    I don’t buy the “it changes” argument. Yes, stuff is added, but everything that worked at some point still works. Just because CSS grid was added doesn’t mean that using flexbox, or even properly using divs and box model is suddenly out of the window.
    • phoronixrly 10mo ago
      Let me ask you this then -- if you create a brand new web app UI using a table-based layout, do you consider yourself a person who 'knows CSS'? Yes, it will work as it used to 15 years ago. You will get laughed out of a tech interview for it though.
      • svieira 10mo ago
        Depends ... are you using `display: table` or are you literally using HTML instead of CSS? If you are doing the former, you know CSS. If you're doing the latter, then you haven't demonstrated that you know CSS and we'll have to talk to figure out if you know it and are avoiding it or if you just don't know it.
      • ecb_penguin 10mo ago
        Table based layouts were deprecated even 15 years ago. It goes against your point that things change frequently. > do you consider yourself a person who 'knows CSS'? Sure. They know an older version of CSS. They don't know the latest version. Shrug.... > You will get laughed out of a tech interview for it though. I've never laughed at anyone in an interview. Can you share some more nuances here? What's the role and expectation? How good is their code? Did they just not learn some modern designs, but can learn it quickly? What have they been working on the past few years?
• rascul 10mo ago
  I find writing CSS to be easy enough. The hard parts are tracking latest changes and browser compatibility.
  • shadowgovt 10mo ago
    The thing that makes me most anxious about CSS is the lack of composability in the language itself (in the sense that every selector is more-or-less globally applicable). This is both a feature and a bug; it makes it much easier to style the entire site coherently, but at the same time much trickier to release individual modular components of UI as libraries and be able to drop them into the world for consumers to use without those consumers worrying about name collisions in a global symbol space of class names. Web components have helped here, but in practice I don't ever use them; I either use one global style.css file (for personal projects that fit in my brain alone) or I use a system that supports local CSS classes via a compilation-and-name-mangling step.
    • WorldMaker 10mo ago
      `@layer` is another recent CSS feature that helps a lot in this space. (I think it's a more exciting feature than Web Components with Shadow DOM.) It makes it easier to stack multiple levels of stylesheets from most generic/system-wide to most specific. You can import 3rd party stylesheets not written for `@layer` in mind into specific named layers. Layers take care of things you'd used to use `!important` to try to hack around much more systematically based on the specificity of the `@layer` the CSS is coming from. (More specific layers override more general ones as if they were more "!important".) Layers don't entirely save you from naming conflicts or CSS specifiers that are too broad, but Dev Tools give you increasing ways to isolate which layer a conflict is coming from, at least, and that can help you decide on ways to fix the conflict. I think `@layer` is a closer hint to what the "CSS-native" approach to "CSS modules" is going to start to be than just CSS class munging at compile time.
    • rascul 10mo ago
      > in the sense that every selector is more-or-less globally applicable If I understand what you're saying, that's more about how you use (or don't use) combinators.
• throwawayffffas 10mo ago
  I know CSS and believe me it sucks. Sure grid layout and flexbox fix things. But a lot of it is hacks on top of hacks. Why do you think the padding as a percentage is relative to the width of the parent? Do you think it was a happy accident? I don't think so, it was purposefully put there in the specs so that we could have boxes with fixed aspect ratios. This is just the tip of the iceberg. The good thing is that all the hacks together make a working thing. And if you know them you can do a lot of stuff.
  • christophilus 10mo ago
    Yeah. If you like programming exclusively with globals and no warning when you have conflicting variable names, then CSS is for you-- it's basically programming (almost) exclusively using global mutable state. I understand why people hate Tailwind, but it largely solved this problem for me.
    • zelphirkalt 10mo ago
      You don't have to use global variable names. You can scope variables by defining them in the scope you want them to be defined in. Where do you see CSS being global mutable state?
      • madeofpalk 10mo ago
        Class names are "global mutable state". You can declare a class in one file, and other file can 'mutate' it. There are solutions/workarounds to this. First following a convention like BEM, then enforcing that at build time (CSS Modules), and now (potentially, i haven't checked in with it) the language supports @scope.
        • bryanrasmussen 10mo ago
          Class names and other selectors are more like a query language, because they don't do anything if you don't have an html element with that class or matching the selector. on edit: a downvote on that, really. because I don't think class names are anything like a variable!
• Devasta 10mo ago
  It's also just kinda bad. Like, people were celebrating the has() pseudo class allowing them to do things with selectors that would be trivial in XPath in its first version 20 years previously. I will give the people who work on CSS props though, they are the only ones interested in advancing browser's capabilities as something more than just a JS runtime, that is to be commended.
  • shadowgovt 10mo ago
    I imagine it's a difficult language to ride the saddle-point of capability and performance. A declarative language like that seems like it'd be easy to design a feature that, as a side-effect of existing at all, slows rendering globally by 5%.
    • marcosdumay 10mo ago
      IMO, browsers should throw their hands up and say "if the developers want to do that, it's not our problem" more often. The argument that people would migrate to some browser with a faster CSS engine is a bad one for the cases where it's impossible to handle bad code with good performance. There are too many good features that aren't being added to CSS because browsers don't want to slow down on bad sites.
      • nicoburns 10mo ago
        If a feature can't be used without the site using it becoming one of those bad sites then it's not very useful (that was absolutely the case with `:has` until the Safari team figured out a trick to implement it performantly - after which the other browser promptly adopted the same trick and implemented the feature).
• ukuina 10mo ago
  It is obvious now that CSS exposes great atomics with terrible dev ergonomics. Look at MDN, the gold standard for web docs, on Grid: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Grid_layout/Basic_concepts https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Grid... That's just the basic concepts! Now look at how easy MUI's Grid is: https://mui.com/material-ui/react-grid/ https://mui.com/material-ui/react-grid/ Atomics vs Usability. Everyone needs CSS. No one needs to *write* CSS.
  • albedoa 10mo ago
    You are comparing CSS Grid to a Flexbox abstraction that MUI calls "Grid". Your point might still be valid with the fairer comparison: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Flexible_box_layout/Basic_concepts https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Flex...
  • WorldMaker 10mo ago
    It's partly a case of people mean different things when they talk about "a grid" and how they would use a grid. Bootstrap popularized one simplified model of layout they called "Grid", and MUI is continuing a version of that. CSS Grid is an attempt to unify that simpler "Grid" with more powerful grid constructs and as a more generalized 2D layout engine. It takes the things learned from Flexbox and Table layout and tries to unify them into a sane 2D layout system that has the power of both and additional tools. I think you can replace nearly every use of Flexbox (and Tables for layout) with CSS Grid and have overall better dev ergonomics. The `grid-template-areas` tool and named areas can be great dev ergonomics far better than anything that came before it in CSS, especially if you have highly responsive layout needs and/or desire to decouple HTML source order with layout order (for better, cleaner accessibility, for one instance; or for cleaner streaming order on slow pages, as another reason). It has a learning curve more than the simpler "Bootstrap-era" Grid designs, certainly, but I think it's an easier learning curve than Flexbox (but esp. if you've already learned Flexbox, because they share a number of concepts).
  • PaulHoule 10mo ago
    Another big problem is that designers never got the "semantic" bit. I don't know how much of that is that most designers aren't used to thinking systematically and like to design a page at a time instead of a system for a whole site and how much of it is CSS being structurally wrong. So we have MUI and bootstrap to impose an application-like structure or tailwind to just "do what I mean".
• chistev 10mo ago
  "There are people who care about the UI. I can’t do UI to save my life. I mean, if I was stranded on an island and the only way to get off that island was to make a pretty UI, I’d die there." - Linus Torvalds. Source of the quote above - https://youtu.be/o8NPllzkFhE?si=8vIMSR9qjVuFlvtt https://youtu.be/o8NPllzkFhE?si=8vIMSR9qjVuFlvtt If you don't want to watch the whole video, here's the exact part about the UI - https://youtu.be/u4cI71pnFUc?si=DZqOaj6SE9yIh7Re https://youtu.be/u4cI71pnFUc?si=DZqOaj6SE9yIh7Re Transcript - https://terence-xie.medium.com/linus-torvalds-the-mind-behind-linux-4d995b8f3ee9 https://terence-xie.medium.com/linus-torvalds-the-mind-behin...
  • ecb_penguin 10mo ago
    This is a different problem and disciplin. I'm not an artist. I can't design anything pretty. But I can learn a programming language (or CSS) well enough that I can replicate something an artist designs. We have an entire design org that produces pretty UIs. FE developers are then expected to know the CSS rules to build that design. The very first thing I teach new FE developers is how to build from Figma designs.
    • OkayPhysicist 10mo ago
      IMO, this particular division of labor (design/specification) introduces a rather unacceptable level of friction. It is a feature, not a bug, that when the design and specification work is being done by the same person, the designs tend to be ones that are relatively straightforward to specify. It makes it a conscious choice to budget more specification effort towards elments that are more important to the designer.
      • ecb_penguin 10mo ago
        [flagged]
  • pkoird 10mo ago
    *Linus
• j2kun 10mo ago
  "Did you learn X before using it?" is indeed my one of my most commonly occurring thoughts that I never say out loud.
  • ecb_penguin 10mo ago
    There's nothing wrong with using something before learning it. In fact, I'd argue most people can't learn something without first using it. You can read all the programming books in the world. Actually writing a hello world program will teach you far more. If you want to learn to play guitar, you need to start practicing simple chords long before you ever learn theory.
    • bryanrasmussen 10mo ago
      but in the same way nobody writes a hello world programming in any language without first reading enough of the language specification to write that hello world program. on edit: yes, HN cleverboots et al, I should not have written "language specification", you got me! However I challenge anyone of the especially clever people here to go write a hello world in some programming language that you know nothing about, without first looking up how to do it. That is to say that while hardly anybody "learns the language" to write hello world, they do learn exactly enough of the language to do just that, and continue from there, until they get to some point at which they may feel to get deeper into the language. Thus the parent comment about people not learning the language was not exactly correct either.
      • oneeyedpigeon 10mo ago
        I think you would be surprised by how many people write hello world without reading a single character of the language specification! In fact, I would be amazed if it weren't even the majority of new programmers.
      • ecb_penguin 10mo ago
        Absolutely no one has read a language specification before writing hello world. Even as a developer with 30+ years experience, I'll write a dozen simple programs before I ever read a specification... I'm looking for examples of basic control blocks, not esoteric edge cases for advanced features I don't yet care about.
• cubefox 10mo ago
  I once tried styling a slightly elaborate table in LaTeX, which turned out to be an hour long task. It made me truly appreciate CSS (and HTML).
• Pxtl 10mo ago
  css is bad. 1) Why is it using an NIH format instead of using XML or INI or something? 2) Why does it use symbols instead of words for selectors? HTML calls them "id" and "class", why does CSS call them "#" and "."? Yes you learn that quickly, but terseness isn't really defensible when the verbosity already exists in the other file that you download and edit more frequently. 3) It's too global. This is good for consistent styling but bad for modularity. 4) It's too much of a moving target. Best practice for html+css+js changes constantly. 5) The long history of stuff like "centre a div vertically" shows how it fails the "easy things easy and hard things possible" test. 6) Pseudo-classes are ugly and weird and were a way-too-late NIH thing. I mean there are good reasons for it to suck. Anything that has grown organically since 1996 with no coherent versioning or deprecation strategy is going to be a hot mess. But it is what it is.
  • shadowgovt 10mo ago
    What is "NIH" in this context? "Not invented here?"
    • leephillips 10mo ago
      Without doubt.
      • shadowgovt 10mo ago
        Ah, cool. I wasn't sure what "here" could possibly mean when we're talking about a language that was part of the web standard. AFAIK, CSS syntax is inspired by the syntax of STTS, and STTS intentionally didn't use XML because it's a pain in the ass to hand-write and hand-read. I cannot argue with that assessment. So CSS's syntax was based on an existing syntax, but it happened to be a syntax that didn't catch fire (which is so often the history of such things): it made plenty of sense at the time when the devs were looking at the options and maybe went "Well, we know XSLT and... It sucks and is hard to use, so what alternatives are there?" And STTS was apparently billed as an XSLT that human beings could write and read.
        • 10mo ago
• Joel_Mckay 10mo ago
  Anyone that actually works with CSS will tell you it is the platform specific standards mess that made it a problem. Try something fancy, and it will likely become a bug later. It gets painfully clear if you want pixel-perfect layout on every desktop screen, mobile screen, and browser. YMMV, and PDFs will be around forever now... =3
• drcongo 10mo ago
  The only part of this article that I disagree with is "It's much easier than your traditional programming language" because it very much isn't. I don't program in many languages, but I can read most that I come across and mostly understand what they're doing. CSS to me seems like a pile of rules, rather than something with control flow.
• TZubiri 10mo ago
  CSS also sucks because 10px isn't 10 pixels, 10cm isn't 10 centimeters, and 50% isn't 50% of the screen. But yeah, many people learn the intended syntax, but don't learn the actual clusterfuck of its backwards compatible standardless behaviour. I'm convinced you can do almost anything with just html,css and maaybe a tad of vanilla js.
  • kwisjajdjh 10mo ago
    [dead]
  • pjaoko 10mo ago
    > CSS also sucks because 10px isn't 10 pixels, 10cm isn't 10 centimeters, and 50% isn't 50% of the screen. This really isn't about CSS, it's about screen hardware - and the thousands of constantly evolving products in the market.
• miiiiiike 10mo ago
  If you want to learn CSS, and I mean, REALLY learn it, buy "CSS: The Definitive Guide" (https://www.amazon.com/CSS-Definitive-Guide-Layout-Presentation/dp/1098117611 https://www.amazon.com/CSS-Definitive-Guide-Layout-Presentat...), read it cover to cover, and use every property in playground while you're going through it. I was a backend developer that hated CSS before it, now I love it.
  • TZubiri 10mo ago
    I was about to argue that there can be no definitive guide on CSS as it's a technology without a single manufacturer and it has a 20 year old history. But then I saw the length of the book: "Print length ‏:‎ 1126 pages" Ok, I'd say it's legit.
  • asplake 10mo ago
    You have to really, and I mean REALLY want it, because it’s £45, even on Kindle
    • bigbuppo 10mo ago
      It's literally the definitive guide on CSS, and frankly, it's the gold standard for any book calling itself a definitive guide. An inordinate amount of work went into the book's 1126 pages. You will learn something every time you open the book. It will pay for itself the next time you wonder, "how do I do X with css?", because you don't have to search. It's right there in the book.
    • zffr 10mo ago
      If you do software as a profession, is the book really THAT expensive at £45? Having a deep understanding of CSS could make you significantly more than that.
  • robrain 10mo ago
    Simplistic analysis of whether CSS sucks: this definitive guide is 1,126 pages long. On the Amazon page it also suggests the "Definitive guide to JavaScript" - it's 704 pages long. If you can fully explain JS (an inexplicable bodge built on a tower of inexplicable bodges) in less pages then CSS almost definitely sucks.
• threethirtytwo 10mo ago
  It’s the other way around. We don’t bother learning CSS because it sucks.
• RockieYang 10mo ago
  CSS is tricky, touch one place the whole thing could collapse. I guess that just the nature. I find this course is very helpful for me https://css-for-js.dev/ https://css-for-js.dev/
  • kccqzy 10mo ago
    That’s just bad code in general. In any language, when incompetent or very inexperienced devs write code, they tend to write brittle code that breaks entirely when one thing changes. CSS is not unique. It’s just that a lot of people wrote CSS without really learning it, so they wrote it incompetently.
    • array_key_first 10mo ago
      Language design has a lot to do with it. CSS encourages much more global mutable state than even something like C, so of course it's going to be brittle in practice. The solution is writing the least amount of CSS possible and then just using components to build up a UI. Using CSS any other way feels patently insane. I think this is best evidenced by our constant innovation of news ways to undermine the "cascading" part of CSS and introducing scope wherever possible.
      • kccqzy 10mo ago
        The brittleness of badly written CSS is unrelated to its cascading nature. In my experience the “cascading” part is a good thing. If you want to make a paragraph red, you do want all other inline elements inside the paragraph to be red as well. Also, in my experience, most of the brittleness comes from an insufficient understanding of selector specificity, including both unintentionally broad selectors as well as unintentionally narrow selectors. The solution is a careful consideration of scoping: most programming languages encourage the developer to carefully consider whether a variable should be local and global, and a similar amount of care must be taken in CSS too. The programmer needs to have a high awareness of which rules should apply to the whole document and which should apply to this particular component.
  • 10mo ago
• charlieyu1 10mo ago
  I just don’t understand why we design every language to be so different
  • ivanjermakov 10mo ago
    Because every language is designed for specific domain/problem and follow specific constraints. Imagine using Rubik's cube turning notation instead of English.
    • charlieyu1 10mo ago
      On the other hand, English is quite fine for describing Rubik’s cube turning notation. We use single English letters for turning notation but it’s just abbreviations
• kbrisso 10mo ago
  AI does CSS well!
  • deleted 10mo ago
    [deleted]
• tjwebbnorfolk 10mo ago
  I challenge OP to center a <div> in an arbitrary container using CSS. Good luck.
  • oneeyedpigeon 10mo ago
    .container { display: flex; justify-content: center; align-items: center; }
    • nicoburns 10mo ago
      Or even: .container { display: grid; place-items: center; }
    • tjwebbnorfolk 10mo ago
      That's not an arbitrary container, that's a container you're defining right there
      • oneeyedpigeon 10mo ago
        Ok: *:has(> #your-div-id) { display: flex; justify-content: center; align-items: center; } If that's not an "arbitrary container", please explain what is and I'll give it another go!
• reimuwu 10mo ago
  I've tried picking up CSS several times but always revert to plain text or some simple rectangles. I just don't have the patience for mastering web design. Fortunately, AI tools are now capable enough to handle the heavy lifting, allowing those of us who hate CSS to actually ship something that looks professional. :)
  • llvmhelpbot 10mo ago
    This is the reality for me too. Something about css just doesn't click. The surface area of the api, how often it changes, the lack of suggestions and guardrails. It's just so different feeling than regular programming. Thank God for AI, I don't have to burn 50% of my time on battling css and can focus on shipping things.
• lbrito 10mo ago
  I had the same realization about myself some time ago: I suck at styling because I never bothered to try to learn css. I know enough by heart to solve most basic problems, but anytime I spend more than a couple of minutes on styling, I'm inevitably scrambling search engines (and these days asking llms). The analogy with learning programming languages is helpful to get the point across but pretty inaccurate. Most of us should treat css more seriously (I for one just want to get done with it as soon as possible), but it's not realistic to compare it to programming. It's like comparing building a sandcastle with building a house.
• bena 10mo ago
  I think it's the "cascading" part that makes it laborious. If I have an element with a class on it, there are multiple selectors that can affect it. It can be because it is contained within another element, because it is an element, because it has a class, because it is an element with that specific class, because it is next to an element, and many others. And deciding which rule gets applied is work.
  • b450 10mo ago
    Web frontends have trended towards various forms of isolation (CSS scopes, shadow DOM), namespacing (CSS modules, BEM), or composition (tailwind etc.) because CSS cascading and inheritance cause more trouble than they're worth. So while you're correct, there are lots of available frameworks and patterns that provide a better dev experience, though of course there are tradeoffs involved in all of them.
• dec0dedab0de 10mo ago
  I have thought CSS sucked since shortly after it came out. I tried learning it more than a few times in the last 28 years, on a couple of occasions I actually managed to do something I wanted. The reason I think it sucks is because I can never remember any of it when I need it. Contrast with html, which I first learned in 95 and have never forgot the basics of, even when going years without using it.
• hannofcart 10mo ago
  I have tried learning it and as far as I can tell, what makes learning CSS rather cumbersome is the fact that you need to memorize too many factoids and gotchas to be effective with it. Not that this cannot be overcome with some kind of spaced repetition or daily practice over a period of time; it's just more effort than most programmers will bother with. Relatedly, too many factoids and gotchas are the reason why I gave up on C++ after nearly a decade of reaching significant expertise with it.
  • bigbuppo 10mo ago
    As if frameworks are any different? Besides, they're not a 100% solution. They are a framework, after all. And what really made me hate frameworks is that as soon as you decide on which framework to use, it's now out of fashion, and the wider community is laughing at you for choosing the wrong framework. Still, anything that lets you get more done with less toil for Work Stuff is probably a good thing. Yes, this even includes Tailwind Font Tags 2.0.
• SilentM68 10mo ago
  In my view it is difficult to learn because it is not intuitive enough for my mind to enjoy. Learning it feels like work.
• css_apologist 10mo ago
  CSS is hard to love, but its worth it there’s a deeply elegant language hidden in there with unbelievable support for generic programming, however it is practically impossible to do that in a component system and the current state of CSS editors i find it hysterical we design component libraries where the only acceptable way to extend the design of a component is add a prop when CSS has a perfectly elegant way to do this without muddying up the component source not to mention the dark arts of encoding show/hide/position/more logic that is often done in js it is the saving grace of the web, but never has been realized
• kevinsync 10mo ago
  CSS can be difficult (not hard, "difficult" like how we would describe a persnickety, sometimes erratic person in our life) but I get the feeling that when haters rant about how bad or illogical it is, they never even bothered to grasp the first principal that CSS isn't much more than an articulation of the visual characteristics of a nested structure of boxes. That's it. You have to be able to visualize, from outside-in, the Matryoshka doll of naked structural elements that make up the component, page section, or entire page you're styling, ensure (or hope and pray) they have sane identifiers (id, class, attributes, etc), then start to write out properties like you're writing a recipe. This was the whole point of CSS Zen Garden [0] -- offer a static, common structure and challenge people to reskin the same thing 1000 different ways. Now, I do recognize that I'm coming off a little dismissive of the complexity of CSS, and that's not my intent.. I'm one of those people who is a good graphic designer, good developer, and often conceive, design, implement and deliver projects end to end, so when I'm in Photoshop I'm also mentally laying out how these designs will be structured in HTML to then be able to be implemented. Naming conventions between markup and styling are also important to be able to translate from bitmap to browser without losing context, and I know we're "post-Sass" by a lot of opinions, but I still find writing nested SCSS far more manageable and readable than plain CSS. Break everything up into discrete components and files, name them well, use box-sizing: content-box to make sure your borders and padding get included in dimensional calculations, imagine in your mind the physical structure/skeleton of the markup, then fill out each part, piece by piece. Browser dev tools to inspect and modify styles in realtime is critical to playing around until you get what you want. That said, IMO the only way to really get comfortable with all of that is to do actual projects, not just tutorials. There are 1001 ways to achieve most things in CSS, and the sheer scope of the spec is impossible to grasp without constantly looking up what property does what, but it really does just boil down to taming all the boxes on the page one by one. [0] https://csszengarden.com https://csszengarden.com
  • bschmidt600 10mo ago
    [dead]
  • kevinsync 10mo ago
    edit: I actually meant box-sizing: border-box LOL and mistyped, so maybe I'm just proving everybody's hatred for CSS. I still stand by what I wrote though.
• gmiller123456 10mo ago
  No, we don't learn CSS because it sucks. I have given up on the idea that I will ever be able to remember all of the rules and exceptions. Just one example most people already know. If I set a height or width on an inline element, it's ignored. So, obviously there is a limitation in the renderer that can't do it. But wait, make it inline-block and suddenly it works! So why the f*k didn't it just honor the width and height to begin with? It's quite literally a rule for the sake of having a rule. I don't doubt there is some deep dark reason for why it is the way it is, like optimizations, or backwards compatability, but it doesn't matter to the end user. It's an implementation detail they shouldn't have to bother with.
  • bigbuppo 10mo ago
    It's because an inline element, like applying italics to text, are expected to behave a certain way. Additionally, it may be inheriting some properties from that cascade thing, and you really don't want it to behave like anything other than an inline element unless you explicity want it to not behave like that. It's like wondering why this grape doesn't taste like fried catfish. They're both food. Why don't they taste the same?
    • gmiller123456 10mo ago
      What ever that "certain way" it's supposed to act, someone obviously wants it to act different if they set a height and width. Having to redefine the display time is a needless extra step that the user has to "just know" when the intention could easily be inferred.
      • Izkata 10mo ago
        Okay; would you like it to change to inline-block or block or grid? Width and height are meaningless for inline elements, but automatically changing the display would be more confusing, not less.
        • gmiller123456 10mo ago
• system2 10mo ago
  The key to using CSS properly is to use it without the fancy stuff. Just keep it simple and stick to the box model with a simple grid in mind. People try to fix dumb HTML decisions with CSS and get frustrated.
• taeric 10mo ago
  CSS sucks because the fundamental ideas were a) abandoned, and b) somewhat bad. The abandoned ideas I have in mind were all around user stylesheets. I know some folks are going to dig up an amazing demo. In the wild, this just never materialized. Remember back when browsers would give you a built in way to manage your own stylesheets for sites? The bad idea, to me, is the whole recursive concept for sizing. I legit cannot think of a good reason to have a constantly recursive application of sizes. Which, I think if you stuck with the standard elements when CSS was started, you could argue that this makes a lot of sense. As soon as we all accepted that a tree depth of 20+ divs is just normal, that went out the window. Which, fair that you could blame the latter on HTML going off the rails with how we explode things into a DOM. Doesn't change the fact that trying to set relative sizes is almost certainly going to bite you in the ass. Edit: I should also add the hilarious fight between the different browsers on default box-sizing. Or how we spun our wheels for a long time before adding flex/grid to the standard. How many years was the recommendation not to use table for layouts, without having a good alternative for the times when it was the easiest to reason way to design something?
  • PaulDavisThe1st 10mo ago
    I think this is more or less totally wrong, based on my experience with native desktop development, which CSS has been racing to catch up with/overtake/replace. Nested widget heirarchies that are 20 deep are a dime a dozen in native desktop development. If you want to argue that this reflects poor UI/UX design, be my guest, but that's the way it has been for 30 years or more. Web design wasn't like this in 1995, but as the platform has evolved to support almost any kind of UI-driven application development, it has also picked up these long-utilized models from that world. What CSS has added, which I view as an entirely good thing, is to extend the notion of rule-driven box packing as the fundamental underlying layout model. GTK realized the sense in doing this when the development of GTK3 began, and other desktop toolkits on all platforms have picked up either all or most of the same fundamental model for layout. Native and web-based UI implementations are ever converging on the same models, and CSS has been the crystalizing force in that convergence, along with its recursive, fundamental box packing (sizing & positioning) concepts.
• weego 10mo ago
  CSS doesn't suck. What sucks is that somewhere along the line we forgot that it's a visual markup tool and not a programming language, and it's been treated as such for far too long.
• paulddraper 10mo ago
  CSS sucks no. 1 because Tennent's Correspondence Principle doesn't exist. That is, there is no nested reusable unit. The number of CSS pre-processors that have been invented to fill this gap is obscene.
• rk3000 10mo ago
  Maybe one day css will be worth something again
• lemonwaterlime 10mo ago
  The challenge for most people is that HTML and Modern CSS are a declarative programming paradigm. You then selectively sprinkle state on top of that. I use HTML and Modern CSS for frontend. I sprinkle htmx when I want interactivity and a tiny amount of plain JavaScript. That gives me a mostly declarative frontend. On the backend I use Haskell, which is also declarative unless you opt into other things. The challenge with web development is that we’ve learned over the years that asynchronous, stateful programming is the most bug-prone programming yet we reach for it first. We should reach for those things last and where they are appropriate. The thing about cascading style sheets is that it all cascades by default. A web page naturally resizes. It’s when we add all this other stuff that things start breaking and becoming rigid. The key to CSS is knowing when to let go.
• deleted 10mo ago
  [deleted]
• rambambram 10mo ago
  I learned webdev around 2004. I'd love to call myself a fullstack programmer. CSS does not suck, it even got better over the years. It's just different from programming languages (whether frontend or backend), MySQL queries and HTML documents. As a fullstack programmer, you have to learn them all. And once you do, you also learn how well they all go together.
• satvikpendem 10mo ago
  I largely agree with this article, and while CSS is pretty hacky due to having to keep up with backward compatibility since the earliest implementation, modern CSS is pretty good for laying out designs. I recommend Josh W Comeau's CSS for JS devs [0]. If you've seen his other articles on CSS and on web dev in general [1], you know that he's a great teacher of complex topics. The course is priced for corporations to buy via their employee development budget, which is how I took it, so for individuals it is steep, but if you can convince your employer to pay, I don't think there's a better CSS course out there. [0] https://css-for-js.dev/ https://css-for-js.dev/ [1] https://www.joshwcomeau.com/ https://www.joshwcomeau.com/
• knallfrosch 10mo ago
  CSS can't be easier than the concepts it describes. If you want a completely different menu on mobile, well, you're going to have at least two menues. Should images keep their aspect ratio or be stretched? Minimum size in pixels or as percentage? Should the image container constraint the image or should the image push the container's boundary? I often ask people what they want to happen. Rarely can they describe it in words – how do they expect to write CSS? Of course they're going the explorative route.
  • throw-12-16 10mo ago
    You do realize that people develop UI for other platforms without CSS right?
    • 1718627440 10mo ago
      You do realize that UI for other platforms is now often done with CSS right?
      • throw-12-16 10mo ago
        Yes, and its usually a bloated mess
        • 1718627440 10mo ago
          Do you have a citation or example for that? Also note, that CSS is just the language itself.
• bschmidt300 10mo ago
  [dead]
• Zak 10mo ago
  > It's inconceivable that you can learn a programming language and be effective in it in a short time. I didn't spend any time learning Python. I just started using it and was fairly effective immediately. I already knew programming in general of course, and several languages with similar features. It takes years to get good at programming, but adding a language that doesn't contain any major new concepts shouldn't take a long time for a proficient programmer.
  • morshu9001 10mo ago
    My wife only knew R and still had a way easier time using Python than R for some simple data science stuff. I gave her one Python example and she took it from there. There are things that are hard but have gold at the end of the rainbow, like SQL. CSS isn't like that. Idk about R, I ragequit it too fast.
• throw-12-16 10mo ago
  No, CSS sucks because its abandonware wrapped in legacy api bullshit. Web frontend as a whole is a dog chasing its tail.
• baxuz 10mo ago
  CSS would be good if you could selectively apply cascading to certain properties and having an option to unset all cascading and inheritance. @scope only works for selectors you add, but there are a ton of properties that even break through closed shadow roots.
• gashmol 10mo ago
  Blaming the user again aren't we?
• deleted 10mo ago
  [deleted]
• tapirl 10mo ago
  CSS sucks because it is sometimes elegantly simple and intuitive, other times a maze of quirky, frustrating hacks.
• robinhood 10mo ago
  Poor article that is borderline click bait and designed to fuel HN rage. CSS doesn't suck. As most things in life, mastering an art takes time and effort.
• bicepjai 10mo ago
  During my initial 2 years of working in web dev at my first job, the main reason for developing a negative experience with web dev was CSS. In the GenAI era, LLMs take care of it for me, and it has been a blast creating websites.
• csnover 10mo ago
  It used to be the case that a web developer could be reasonably expected to actually learn and know pretty much all of CSS, but it has reached the point where it is actually not possible for a single person to “learn” CSS in the way you could in the 2000s or 2010s. Just as one example, there are now, by my count, at least eight[0] layout models (column, anchor, positioned, flow, float, table, flex, and grid), plus several things that sit in some ambiguous middle place (the inline versions of block types, sticky positioning, masonry grid layout, subgrid, `@container`, paged media), each of which is different and each of which interacts with the others in various confounding ways. Flow collapses margins; table elements can’t have margins at all, but tables can have `border-spacing`, which is like `gap`, but different. Flex has a different default `min-inline-size` than flow, and `flex-basis` overrides `inline-size` if it isn’t `auto`, which is its initial value, until you use the recommended `flex` shorthand, at which point it becomes `0%`, unless you redefine it explicitly. Table layout[1] uses a special shrink-wrapping algorithm, which the CSS authors noted back in CSS 2 might make sense to add a way to work more like a regular block-level element, and then that just never happened. Grid is a mix of implicit and explicit placements with competing ways to do the same things (named areas, number ranges, templates on the parent, properties on the child) and a bunch of special sizing algorithm keywords like `minmax` and `fit-content` which only work in grid, some of which also work in flex, most of which don’t work in flow, but some of them do now, but they didn’t before. You can select your elements with the old CSS 3 selectors, or `:where`, or `:is`, or `&`, or `:has` (but not if they’re nested), or `@scope`, or `@layer`. Definitely don’t try to put trailing commas on your selector lists, though, since that’s not syntactically valid in CSS, until it is, in some future revision. To make sure your site works correctly with all scripts, all the directional keywords now have logical versions with `inline` and `block` keywords. Unless it’s a transform[2]. Or a gradient[3]. That’ll probably eventually be fixed, just keep checking the spec periodically until you have to re-learn something that used to be false is now true. Which is how “learning” CSS works. There is never an end. And this is just the tip of the iceberg. There are also all the CSS units, colours, the whole animation engine, forms, pseudo-classes, pseudo-elements, containment, paints, filter effects, environment variables (yes, those are a thing), maths functions, overflow, scroll snaps, backgrounds and borders, feature queries, font features, writing modes, the different-but-not-really CSS of SVG, the half-forgotten weirdo things like `border-image` and `clip-path`, or the half-dozen other major and minor CSS features which I am not even thinking of right now. CSS doesn’t suck “because we don’t bother learning it”. CSS sucks because its core strength is its core weakness. It is infinitely flexible and extensible, and that means it has been flexed and extended to fulfil every design trend and address every edge case. Then it needs to support all of those things forever. Making CSS do what you want as a web developer has probably never been easier, but “learning” CSS has never been harder. [0] Please, for my own sanity, resist the urge to pedantically nitpick in the responses about whether everything in my list is actually a “layout model”. I am aware that some of these things overlap more than others. This is just my list. You can make your own list. It’s fine. [1] Tables also create their own anonymous layout block such that a child `<caption>` element is drawn outside the putative `<table>` in the actual layout. Framesets do a similar thing with `<legend>`. These are all things that are the result of having to retroactively shoehorn weirdo features into CSS in a backwards-compatible way, but that doesn’t make it any less insane to learn. [2] https://github.com/w3c/csswg-drafts/issues/1544 https://github.com/w3c/csswg-drafts/issues/1544 [3] https://github.com/w3c/csswg-drafts/issues/1724 https://github.com/w3c/csswg-drafts/issues/1724
• socalgal2 10mo ago
  I don't hate CSS. In fact I love the fact that I can make a website and with relatively little work it runs everywhere, including mobile. Though I do have to check. That said, I'm not a pro. I asked ChatGPT for some layout primitives which it gave me and I then I probed for things that stood out as strange to me and it gave me lots of background and why things are as they are as well as why they can't automatic. One that stood out was this: Me: No native UI framework in existence has the equivalent of min-width: 0. Somehow they all get by with just layout primitives ChatGPT: native UI toolkits do not expose anything equivalent to min-width: auto (intrinsic min-content) as a default constraint. They get away with pure layout primitives because they made a fundamentally different architectural choice than CSS. This isn’t accidental, and it explains exactly why CSS feels broken here. The core difference (one sentence) Native UI frameworks treat content as flexible by default; CSS treats content as authoritative by default. Everything else follows from that. What native UI frameworks assume (and CSS does not): Across Cocoa, UIKit, WinUI, Android, Qt, etc., the default assumptions are: 1. Text is allowed to truncate 2. Containers decide layout 3. Content adapts to constraints 4. Overflow is normal 5. Intrinsic size is a preference, not a hard constraint In other words: Layout constraints dominate content. What CSS assumes instead: CSS’s default assumption is the opposite: 1.Text must remain readable 2. Content dictates minimum size 3. Overflow is an error 5. Intrinsic size is a hard constraint In other words: Content dominates layout. That single inversion is why min-width: auto exists — and why no native toolkit needs it. After that I asked it could it give me CSS primitives that work like native layout. It did, and it came with all of the issues brought up.
• minebreaker 10mo ago
  Call me crazy, but I love JSS. "Separate styles with components" never made sense to me. Styled components are much better.
• patsplat 10mo ago
  CSS does suck because of the globals. Class names, ids, z index values are all areas where one commonly bumps into other developers in sometimes confusing ways. But to the point of the article, it’s a technology one has to learn. There are name spacing solutions in css (layers) and around css (css modules, panda, tailwind, etc). I think another challenge folks may have with CSS is thinking visually. It’s not automatic. In art school one learns both how to see and how to render, and generally learning how to see clearly is a bigger challenge than learning how to render. Practice your craft.
• fennecbutt 10mo ago
  Nah it sucks because it sucks. Some simpler webgl based grid layout would be much nicer imo. Pretty easy to have a concept of grids and subgrids...which is pretty much what people abused tables for (still required for email clients shudder)
• libyanpoultry 10mo ago
  CSS sucks because it's harder to learn than Chinese, and getting the exact layout you want takes witchcraft and blood sacrifice.