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.
> 1. Many early web engines used `display: content-box`. So the padding was actually considered to be outside of the box itself.
IIRC this was actually the spec, and IE decided to ignore it and do something saner, while the box-sizing attribute to pick what you wanted came later. Designing for content-box and IE displaying using border-box (or whatever it did) was one of the reasons it got the nickname "internet exploder" - everything ended up positioned or sized wrong. Until box-sizing came along, it was common to use various hacks / bugs in the browsers' CSS parsers to make certain rules only apply to certain browsers to fix this.
> IIRC this was actually the spec, and IE decided to ignore it and do something saner
That's actually a little unfair on IE. This behaviour predates there even being a spec. IE and Netscape did it differently, and as a general rule Netscape's behaviour tended to be what ended up in the spec. This was mostly a good thing, but not so much in this case.
While that's true. They could have gone another way without breaking the dependency rules.
Padding top and bottom could be relative to parent height and padding left and right could be relative to parent width. They would not be the same. But it would still make sense. It would arguably be more logical than the selected behavior.
But the specific example does not even invalidate my point there is a whole website about css quirky behaviors and how to use them to your advantage, https://css-tricks.com/.
I know CSS, but also a few other displays and layout engines.
In my experience "CSS sucks" right up until you try to do a tenth of what it offers in something else. Cross-platform, device-neutral UI is hard. Then allow user-provided alterations?
Yeah, there's a good reason why I have a lot of criticisms about CSS and only some about, say, QT. It's because I spent the last 15+ years writing CSS in some way or another and one extended summer of hacking a side project in QT, abandoning it, and never looking back.
It depends on what you mean by "sucks". I don't think anyone here is denying that it's often the best tool for the job. You SHOULD learn CSS if you want to be an effective UI programmer simply because you'll encounter it everywhere. But the quality of the language should still be critique IMO.
That's the basis for my critique of CSS. There were plenty of other layout systems extant at the time CSS was cooked up. How CSS could have delivered such an incomplete and broken scheme is beyond me. To this day, it sucks harder than GridBagLayout from AWT of the 90s (and that one sucks a quite bit).
> 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.
It’s because you cannot do a percentage of a height unless your parent’s height is fixed - something that happens naturally maybe 1% of the time. You’d be missing vertical borders in almost every case with your suggestion
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.
If you are thinking about CSS, in terms of state, mutability, variable names and programming, you are already down a very wrong path and you won't have a lot of luck.
CSS is about rules, selectors and cascading, hence Css.
Abstractions matter, and using procedural programming abstractions on a declarative styling language only gets in your way.
Absolutely agree, although CSS has slowly become more and more like a programming language over time, so it's understandable that people have this confusion.
CSS isn't "like" a programming language. It is a programming language.
It's just not one based on states, mutability, and variables. Even the things that use the `var` keyword are constants, not variables.
(But then, don't read that as being against scoped rules. The fact that all rules are global to the document is bad. We can emulate scopes with specific selectors, but that's the kind of thing a language is supposed to help with.)
I’m dumb and don’t understand the distinction you’re making.
elem.style.setProperty(‘—var-name’, newValue);
… will set a new value for the “constant”. The element will rerender with the new value. You can animate/automate these changes and the element will continue to rerebder with the updated value.
To me, that justifies the name “variable” from the perspective of the CSS.
We've heard that one before, haven't we? HTML was supposed to be a declarative language, not a vanilla programming one. And look where we are... the biggest mess of a programming language the world has ever seen.
What's the wisdom of randomly inserting cutesy "declarative" bits in a world infused with programming-oriented infrastructure... It doesn't make any sense.
For me the first-approximation litmus test of "is it a real programming language" is "does it have conditionals"? HTML itself does not have conditionals (at least in common use, if you don't count the contents of <canvas> and <noscript>, which I don't). So I don't see how HTML is a programming language, let alone a messy one. LaTeX is a programming language because it's built on TeX, which is a programming language, but HTML purely marks up text.
Granted, when you add CSS to the mix, HTML+CSS is programming if you get fancy about it.
HTML (Hyper-Text Markup Language) is a specific kind programming language, a markup language. It is nowhere close to a general purpose (Turing complete) programming language. Maybe you meant the web stack (HTML, JavaScript, CSS)?
It's a (computer) language, it is also a formal language. A programming language is a language in which you can write programs, which are descriptions of algorithms. You don't describe algorithms in HTML, hence it is not a programming language.
> Maybe you meant the web stack (HTML, JavaScript)
HTML5 doesn't refer specifically to HTML, rather it's "HTML + JavaScript + CSS". There's hardly a website nowadays that can be used without JS.
By using the name HTML5 as an umbrella name for a programming language API plus some declarative bits, the W3C tacitly admitted that the declarative push has been a mistake - I explained "why" in my previous comment.
HTML5 refers specifically to the latest, living version of HTML, the markup language. CSS and JavaScript have their own specifications, and version numbers. The term your looking for is the web platform [1].
On a technical forum in a post that contains, both the words "CSS" and "HTML"? Sorry, but no "HTML5" refers to the version 5 of the Hypertext Markup Language.
HTML5 is the HTML of today, that's what I meant originally. I'm not sure what you're afraid of, nobody is attacking you, I'm simply explaining what I had in mind, and why it's not unreasonable to use words in a more inclusive, close to contemporary practice meaning.
The fact is, JavaScript is ubiquitous in web programing and the web is unthinkable without it, it's so pervasive on the front end that it's been repurposed for backend use precisely because it makes a lot of sense to use one programming language for one project. Pure HTML is unsuitable for backend use and it sticks like a sore thumb in the front end.
Younger developers are likely missing on the history of the entire web endeavor but in order to get a feel for it, I'd recommend to focus on practical meaning rather than on trivial semantics.
The big point I was driving at is this: The damage has been done, instead of a clean rendering API we've got this hybrid monstrosity which locked us to a couple / triple browser rendering engines which, due to cutesy BS, are complex beyond comprehension, beyond security analysis or normal competition. This is what an obsession with fancy names leads to.
nah. the technical semantics is absolutely the point when we're talking about code. HTML is thing distinct from javascript and CSS and it's very useful to be precise about it in our context.
Sure but things like scoping and shadowing are still relevant to CSS. The fact that it's declarative doesn't give it an excuse for the poor scoping design.
In the initial conception pages have their own stylesheet, that solves the scoping issues.
It's our fault we pack all the rules in one file and ship it to all our pages.
"Shadowing" is on purpose it's the cascading part of the cascading style sheets. There are rules around which rule has priority read about selector specificity.
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.
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!
This doesn't make CSS classes mutable global state. CSS rules are applied according to specificity of selectors. You could maybe say that the overall style of a page is mutable state, but not the CSS classes themselves. A CSS class is assigned and that's it. Unless JS is involved, it also doesn't disappear or toggle.
I'm aware of browser defaults and how they work, yes. Just because someone does not agree with you does not make them uneducated.
Frankly I tend to find analogies not very useful, I don't think my analogy of CSS as a db is very good, but as bad as it is I feel it makes some sense as opposed to talk about classes as if they were global mutable variables.
I will take my analogy slightly farther.
I will say the browser ships with a DB system called CSS, and a toy DB called BrowserDefaults implemented in CSS, the same way MS Access used to ship with Northwind. The especially sucky thing about this system is that when you want to create your own DB you have to extend BrowserDefaults. This is why a lot of specific DBs have what are called resets that basically delete all of the BrowserDefaults setup so it is not messing with your DB.
The browser also ships with two languages with the ability to query CSS, one is JavaScript and that is a pretty straightforward language it can read and write to CSS using an API called the CSSOM. The other query language is a tree based query language called HTML (actually there is also another tree based language called XML in there but nobody talks about that anymore, let's just say it works almost the same as HTML only when you use it, it automatically clears all the data out of the base BrowserDefaults DB)
(We can see what I mean about analogies suck right about here)
This tree based query language is crazy as shit! Because it is not just a query language but also has some weird transformational capabilities.
And also the thing that is weird is that the HTML query language can be changed by the JavaScript language!
Let's look at an example
Let's suppose we have a tree structure like this
<div class="one"></div>
<div class="two"></div>
and the JavaScript holds a tree fragment <span class="myspan">text</span>
the JavaScript reading that fragment css properties will see that "color" = "green"
but placing it inside of the parts of the HTML tree gives different values for the color property. Some people will mistakenly claim at this point that the is mutation of the global state but that is obviously incorrect. The CSS state has not been mutated at all, what the HTML query has done essentially is run a transformation and output an object, the CSS state remains unchanged because JavaScript can use the CSSOM to query what the data in the myspan class is.
JavaScript can mutate the value of the CSS classes, but HTML cannot. HTML essentially copies all the classes, runs a transformation, and outputs the result.
This is actually a pretty interesting situation, I don't feel that there is any similar architecture anywhere. I don't feel it really fits with DSSL or Latex (because of how JavaScript works with HTML)
Now although I don't feel that I have ever really had the problems that other people of undoubtedly superior programming ability seem to have with this, I can see how this unique and somewhat accidentally arrived at architecture can be irritating to people.
Note - when I say I don't have any problems I mean sure, I can create bugs with this, I can find bugs impacting me with this, but I've never really had long running hard to resolve bugs due to CSS/HTML. Bugs that are generally hard to resolve I find are in the JS stack.
Going back to the browser defaults thing - again not really a good example of either of our analogies, more an example of how every programming language has its idiosyncratic and stupid things you just have to learn about it and keep in mind or they will bite you on the ass.
on edit: obviously I am not making any claims as to internal implementations in browsers and how they do it, I am just discussing the external experience of these languages working together and how to think about them.
I'll just note here that there are some obvious points about CSS custom properties here that might seem more like mutating state, although there it is not global state being mutated, but I can't really address all that here, as it is midnight and I need to get up early.
again here, in case someone wants to argue that the css itself has mutated the state, no it hasn't.
JS with CSSOM can read what the value .myspan, .one span and .two span all are.
because this is the point where CSS breaks down as a db holding properties, it is here that it is instructions for the HTML language on how it is to run transformations.
It ought to be possible to compose HTML documents the way Ted Nelson wanted to compose documents in Xanadu, it's a PITA to do because the classes are all in the same namespace although now we have Shadow DOM to manage this and you can even do it without JS with Declarative Shadow DOM.
It's a source of stress to add a class to the system with a simple, short and readable name and have to worry it is used someplace else. There is BEM but I despite it (not simple, not short, not readable)
I work on a React application that uses more than one plain-CSS framework and also Emotion and some other JS frameworks that generate more CSS properties. These are all leaky abstractions so if you aren't happy with the defaults the way I am with my boostrap-based RSS reader, you have to understand the abstractions of the framework and still understand the underlying CSS. Probably the worst time was when I had to get an application to run inside the Shadow DOM and vendorize some components to patch them accordingly.
One saving grace is that that LLMs are good at both coding CSS and answering questions about how it works.
> It's a source of stress to add a class to the system with a simple, short and readable name and have to worry it is used someplace else.
That is the whole point of CSS classes: re-use. A CSS class is not meant to be used in only one very specific place. For that, you can select an element's ID or an elements HTML path, to style just that one thing.
It bothers me that we're comparing logical languages versus compositional, and I think it's based on a clear misunderstanding of what CSS is supposed to do versus something like C++.
It's like saying Rego[1] should just be done in a procedural language when in fact it also wouldn't be useful in that context.
I've spent a LOT of time trying to learn it. I've read the O'Reilly book, CSS zen garden, Eric Meyer on CSS, and the spec itself... I still think it sucks.
That is my impression too. From my experience, the fact that I used it early on makes me use it in the "wrong" way as the fundamental concepts have changed a few times.
>> as the fundamental concepts have changed a few times.
This is what got me. I exited development about eight years ago. Came back and was like, "WTF is going on with CSS now?" Completely lost and took me a few years working as an accessibility engineer to find my way back.
Its very hard having people telling you constantly how to "properly" use CSS, then learning all those techniques and approaches. Using those for a few years, then suddenly you have to completely unlearn it, then relearn it "the right way" again a few years later.
Completely maddening where front-end development has gone and continues to go.
> "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."
I don't think that css evolved with specs, the HTML/CSS specs were descriptive rather than normative, and they came after the browser wars and the organic clusterfuck.
"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."
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.
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.
Back in the "golden age" of Web my development career, circa 2008, before "full-stack" and before SPAs, we were fortunate to have people that specialized in UX and CSS. They understood fonts, colors, spacing, browser quirks, and they understood CSS. They have their own conferences and bloggers that they followed. (Eric Meyer) They were technical enough to deal with a Git repo and commit css and image files. The back-end / "CS major" types could simply focus on the CRUD part of the application and didn't have to care about UI or CSS.
Many people very much cannot cook because they have poor kitchen skills (or even none at all).
"Anyone should be able to follow a recipe" is far from reality, especially since the vast majority of recipes are not written for the kitchen illiterate.
Nobody is born with "kitchen skills" whatever that means. You have to spend some time learning it, and everybody can do that. Trying to explain chopping onions as "kitchen skills" is just running away from the challenge.
Jumping to conclusions about what "kitchen skills" means aside, the fact that nobody is born with them is precisely the point. Congratulations, you understood it!
Slightly less facetiously, "anyone can follow a recipe" makes about as much sense as "anyone can follow a README". Is it some arcane black magic that only a select few can decipher? No, but at the same time if you don't recognise that there is a baseline level of technical literacy needed to actually follow your average README then you might have your head stuck too far in a bubble.
Following a readme on a github project is obviously a very technical skill and conflating it with following a cooking recipe where the complexity level is around "chop onions" is a strawman, I haven't claimed such.
Cooking is very much a technical skill, much more so than following a readme to install and set up some end-user-targeting project or other. I've seen too many flat-out horrendous meals from people who self-describe as "knowing how to cook" to be convinced otherwise.
Have you looked at a typical recipe recently? Here's an example (https://www.bbcgoodfood.com/recipes/oriental-egg-fried-rice) from the "quick and easy" section of BBC Good Food, a site that's regularly in the first page of search results for various recipes. Never mind that it expects you to have procured cooked chicken breasts from somewhere (and oh boy are those easy to turn into a bland, dry, rubbery mess if you don't know what you're doing)...do you honestly think there is no room in those instructions for someone who does not already know how to cook to screw it up?
Here's a recipe (https://urbanfarmie.com/instant-pot-jollof/) for a more complex dish that I am intimately familiar with, which is how I can tell you for absolutely free that if you just "follow the recipe" as described you will very easily end up with a soggy mess at best and burnt rice at worst.
Or - since you seem to like patting yourself on the back about onions - the next time you're following a recipe and it tells you to "sweat" or to "caramelise" onions or "sauté until golden", maybe spare a thought for how likely it is that someone who is actually new to the kitchen will get the correct result.
Cooking is so easy, everyone who has hands, can read a book and a clock can do it. Start with eggs or pancakes, work your way up from there.
My kids learned to cook from age 9. Now everyone can cook in this household.
I can’t take any adult who says it’s hard seriously, especially since I grew up in a culture where I heard a myriad of excuses from ‘manly man’ who think of it as a woman’s job.
Refactoring UI is a well known book for learning about design as a developer [0]. It's co-written by Adam Wathan of Tailwind even before he made Tailwind. Steve Schoger, the other author, refactors UIs on YouTube [1] which you can take a look at too, lots of good tips there and he talks through each one and visually shows you what changes and why.
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?
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.
Nested is fine. Setting text size to be 50% of parent just rarely does what you want it to do. Well, to be precise, it does exactly what you want for the first week that you have designed it and have not started adding all sorts of other widgets to a site. Such that, inevitably, you just want to have large swaths of text that are at given sizes. You don't care how nested the thing is to get you there.
I remember learning the different Java Swing layout managers back in the day. Again, being nested was fine. That said, if you were doing a large layout, you were probably reaching for GridBagLayout. Back in 1999... (And I recall that SWT layouts were even simpler?)
I'm willing to concede that many of the ideas in CSS are good. At the least, benign. User stylesheets were just flat out a rake in field, though. And I stand by the claim that percentage sizes is largely a massive foot gun.
Edit: I should say that I find native interfaces took a massive nose dive in many ways when we abandoned so many interface builders. I have no idea how nested your typical MS Access form was or was not. I know that designing and wiring them up was far easier than what I typically see today.
Don't get me wrong ... I don't think that trying to build apps with the complexity or layout demands of a native desktop app (particularly the creativity ones) using HTML+CS+*script makes much sense. The native toolkits are still a much better fit for this purpose.
But the native toolkits have learned from CSS in many ways, and that is just accelerating as we see what new wonders get cooked up in a web context that people used to say "you just can't do this in a browser with HTML+CSS".
I think I should have put "sucks" in quote at my opening salvo. CSS, I think is fine if you stick to the easy things. Which, fair that most things should stick to the easy things.
Where web development sucks is when we try and rube goldberg getting an icon where we want it, or anything sized the way we want it. It is akin to forcing yourself to play mouse trap every time you want to align something. (With some common alignments still just not supported? Or can we decimal align numbers easily finally?)
It isn't trivial to get that right with native toolkits either, particularly if you are screen-size and resolution aware.
Vertically aligning a set of decimal numbers with the separator the same place would be challenging in GTK and Qt and several others, unless you make some not well-supported assumptions and simplifications.
And reflow is generally being handled much better in most web apps than it is in native ones, if the latter actually allow it at all (more likely, they set a minimum window size that handles the expected layout just fine).
Also interesting to note that the the much lauded arrival of constraint-based layout across all apple GUI toolkits about 10 years ago (driven in large part by the needs of iOS) has not revolutionized layout APIs or algorithms in general.
I think aligning to decimal point just amuses the crap out of me because "receipt" is a very common document type that you would expect to see on the web. No?
At least in something like GTK and Qt you would be more than justified in just punting on the semantics of the receipt and formatting a fixed width set of numbers to call it a day? In HTML, doing that feels extra wrong. (But, indeed, you can do the same "fixed width" with non collapsed whitespace, even in HTML.)
And it isn't like this isn't a somewhat solved thing in long existing layout engines. Aligning to variables and such is very common in math texts. And largely not doable in HTML.
Reflow is one that always strikes me as largely misguided. No amount of reflow will make most websites look good on a gigantic monitor. Same as no amount of reflow will make most documents handle someone's name that is actually a novel. It just doesn't make sense, for many reasons. And yet we will put forth herculean efforts to maintain "reflow" based on content in so many places.
> Well, to be precise, it does exactly what you want for the first week that you have designed it and have not started adding all sorts of other widgets to a site. Such that, inevitably, you just want to have large swaths of text that are at given sizes. You don't care how nested the thing is to get you there.
Shared library components is where this could work - each individual application would be able to scale the component's size to what it needs.
Is certainly where folks thought it would work. I have never ever seen this work in a way that wasn't more work than makes sense. Happy to see some actual success cases, if you know of any.
Same as with alternate stylesheets or a reasonable line of death. For all the annoying things Mozilla does, Firefox is still a great browser and for some measures the only shop in town.
> meaningful styles across sites
You can also modify the browser chrome with it, and I think UBlock Origin uses it for modifying the page. Also some settings are exposed via a UI, so also lawmen not knowing about user.css might still use the user (agent) stylesheet.
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).
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".
In the example there is a mixture of style and content. This would be of course more ergonomic. However, the strength of CSS is that you can decide later on to change the style without touching the content.
Both right. Sucking at something is the first step to being kind of good at something. At the same time doing that in a professional environment sucks for your coworkers
> At the same time doing that in a professional environment sucks for your coworkers
The vast majority of what we learn is in a professional environment. I can't build a hobby app with hundreds of millions of active users. We learn at work, and that means sometimes it sucks. But that's why we have blameless cultures, because we all realize you can't learn unless you first do it in a shitty way.
It's also why AI replacing juniors is terrible. Juniors need to make mistakes and figure things out. That's how they become experienced seniors.
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.
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.
+1 my point is that, if you didn't learn it, you need a humble attitude. And in the context of software you're building as part of your profession, not learning it well is a bigger problem than hobby pursuits.
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-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.
Any professionally edited and published book is better than reading disjointed blog posts and online pages. I learned CSS in 2006 or 2007 from the then-new book, Web Design in a Nutshell, and after a month I was already way more comfortable writing CSS than three months of reading various blogposts.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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. :)
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.
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.
`@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.
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.
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.
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
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.
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.
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".
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.
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.
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.
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.
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.
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%.
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.
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).
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/
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.
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.
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.
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.
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.
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.
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.
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.
Because every language is designed for specific domain/problem and follow specific constraints. Imagine using Rubik's cube turning notation instead of English.
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
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.
With the actual layout models, I see it more of an evolution thing. For someone starting on CSS today, you do not have to learn all 8 now if you don't want to, just master the grid. It was designed to be the last one to rule them all.
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.
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
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').
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'.
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.
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.
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?
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.
1) doesn't seem to be a very big issue, the syntax is quite simple and readable. Arguably, INI or XML would have been worse. INI especially would have been a shame, now that we can nest blocks. XPATH selectors would have been nice, they are more powerful and barely less readable.
2) doesn't seem to be a very big issue, this kind of stuff is very common in many programming languages as well. I don't remember struggling with this even as a beginner, and it's the first time I encounter a complaint about this as well.
3) Fair point, and the inheritance and specificity rules are very complex as well
4) On the other hand, backward compatibility is stellar (and I guess that it's your point in your last paragraph). Your 20 years old CSS file still works today and doesn't even feel really out of place. We could wish the web platform didn't evolve so rapidly, it makes it very difficult to implement.
5) It's very easy to center a div vertically now. Therefore, it can only be a critic of old versions of CSS, not the current one. Do you have another example of basic things that ought to be easy but aren't, or aren't possible?
5) Doesn't seem to be a very big issue. I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
> I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
Single-colon is a pseudo-class, for targeting elements based on some external state. I learned these as "pseudo-selectors" but it seems that's not the right name.
Double-colon is a pseudo-element, for targeting inner parts of an element that themselves aren't actually an element in the document.
Right! Thanks for this. I've never really looked into this and have been writing whatever worked, with a preference for the single colon.
CSS 1 & 2 apparently conflated the two, and CSS 3 allows one column for CSS 1 & 2 pseudo elements. I never noticed it wasn't all of them. Since I learned CSS right before CSS3, my situation kinda makes sense I guess.
Single colons everywhere have felt easier and more regular to me, so I've written basically everything with single colons except maybe the odd CSS 3 pseudo element here and there. But it seems the two colons will be mandated going forward.
I guess I'll have some edits to do, though I do hope and kinda expect they won't break backward compatibility.
> Why is it using an NIH format instead of using XML or INI or something?
The original suggestion was LISP-like or X.11 configuration file syntax (https://www.w3.org/Style/CSS20/history.html) - XML was still too new (but look at https://www.w3.org/wiki/Xsl-fo if you want to see what the W3C came up with for "styling, but in XML format for XML documents"). My guess is that the declarative shape imitates SGML with a C syntax to make it easier to understand.
> It's too global. This is good for consistent styling but bad for modularity.
Yeah, that was an explicit design choice - one that we're now asking for (and getting) more control over as the web continues to expand, but it's not like it wasn't considered, it was considered and rejected for MVP as it were.
> Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
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.
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.
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.
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?
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.
> Width and height are meaningless for inline elements
Really not sure what you're trying to get at there, obviously any element that displays will have a width and height. Maybe you meant a user specified width/height, but the entire point of my post is an inline-block is an inline element with a specifiable width and height. And we've always had the IMG tag, which is also an inline element with a specifiable width and height. The obvious and intuitive choice would have been to not put artificial limits on inline elements.
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.
The serious answer is:
1. Many early web engines used `display: content-box`. So the padding was actually considered to be outside of the box itself.
2. Early web engines were strict about height-can-depend-on-width, but width-cannot-depend-on-height to avoid circular dependencies.
IIRC this was actually the spec, and IE decided to ignore it and do something saner, while the box-sizing attribute to pick what you wanted came later. Designing for content-box and IE displaying using border-box (or whatever it did) was one of the reasons it got the nickname "internet exploder" - everything ended up positioned or sized wrong. Until box-sizing came along, it was common to use various hacks / bugs in the browsers' CSS parsers to make certain rules only apply to certain browsers to fix this.
That's actually a little unfair on IE. This behaviour predates there even being a spec. IE and Netscape did it differently, and as a general rule Netscape's behaviour tended to be what ended up in the spec. This was mostly a good thing, but not so much in this case.
Padding top and bottom could be relative to parent height and padding left and right could be relative to parent width. They would not be the same. But it would still make sense. It would arguably be more logical than the selected behavior.
But the specific example does not even invalidate my point there is a whole website about css quirky behaviors and how to use them to your advantage, https://css-tricks.com/.
In my experience "CSS sucks" right up until you try to do a tenth of what it offers in something else. Cross-platform, device-neutral UI is hard. Then allow user-provided alterations?
It sucks and it's very powerful and flexible.
It’s because you cannot do a percentage of a height unless your parent’s height is fixed - something that happens naturally maybe 1% of the time. You’d be missing vertical borders in almost every case with your suggestion
I understand why people hate Tailwind, but it largely solved this problem for me.
CSS is about rules, selectors and cascading, hence Css.
Abstractions matter, and using procedural programming abstractions on a declarative styling language only gets in your way.
Writing CSS is not programming.
It's just not one based on states, mutability, and variables. Even the things that use the `var` keyword are constants, not variables.
(But then, don't read that as being against scoped rules. The fact that all rules are global to the document is bad. We can emulate scopes with specific selectors, but that's the kind of thing a language is supposed to help with.)
Constants which you can redefine/shadow in scopes, and change the values of at runtime via JS.
They seem like variables to me.
No, you can't. You can set a new value and reevaluate everything.
To me, that justifies the name “variable” from the perspective of the CSS.
We've heard that one before, haven't we? HTML was supposed to be a declarative language, not a vanilla programming one. And look where we are... the biggest mess of a programming language the world has ever seen.
What's the wisdom of randomly inserting cutesy "declarative" bits in a world infused with programming-oriented infrastructure... It doesn't make any sense.
Granted, when you add CSS to the mix, HTML+CSS is programming if you get fancy about it.
HTML5 doesn't refer specifically to HTML, rather it's "HTML + JavaScript + CSS". There's hardly a website nowadays that can be used without JS.
By using the name HTML5 as an umbrella name for a programming language API plus some declarative bits, the W3C tacitly admitted that the declarative push has been a mistake - I explained "why" in my previous comment.
1. https://en.wikipedia.org/wiki/Web_platform
The fact is, JavaScript is ubiquitous in web programing and the web is unthinkable without it, it's so pervasive on the front end that it's been repurposed for backend use precisely because it makes a lot of sense to use one programming language for one project. Pure HTML is unsuitable for backend use and it sticks like a sore thumb in the front end.
Younger developers are likely missing on the history of the entire web endeavor but in order to get a feel for it, I'd recommend to focus on practical meaning rather than on trivial semantics.
The big point I was driving at is this: The damage has been done, instead of a clean rendering API we've got this hybrid monstrosity which locked us to a couple / triple browser rendering engines which, due to cutesy BS, are complex beyond comprehension, beyond security analysis or normal competition. This is what an obsession with fancy names leads to.
It's our fault we pack all the rules in one file and ship it to all our pages.
"Shadowing" is on purpose it's the cascading part of the cascading style sheets. There are rules around which rule has priority read about selector specificity.
Where do you see CSS being global mutable state?
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.
You can do this in TypeScript and Ruby too.
on edit: a downvote on that, really. because I don't think class names are anything like a variable!
Give your element a class. Now show me the CSS that styles it. Good luck because it can be literally anywhere.
Absolutely the worst kind of variable.
One very obvious example is browser defaults.
You literally have no idea what they are. You can override them, but not until you find a list so you know what to override.
Did you know the default browser margin for body is 8px?
Insane.
Frankly I tend to find analogies not very useful, I don't think my analogy of CSS as a db is very good, but as bad as it is I feel it makes some sense as opposed to talk about classes as if they were global mutable variables.
I will take my analogy slightly farther.
I will say the browser ships with a DB system called CSS, and a toy DB called BrowserDefaults implemented in CSS, the same way MS Access used to ship with Northwind. The especially sucky thing about this system is that when you want to create your own DB you have to extend BrowserDefaults. This is why a lot of specific DBs have what are called resets that basically delete all of the BrowserDefaults setup so it is not messing with your DB.
The browser also ships with two languages with the ability to query CSS, one is JavaScript and that is a pretty straightforward language it can read and write to CSS using an API called the CSSOM. The other query language is a tree based query language called HTML (actually there is also another tree based language called XML in there but nobody talks about that anymore, let's just say it works almost the same as HTML only when you use it, it automatically clears all the data out of the base BrowserDefaults DB)
(We can see what I mean about analogies suck right about here)
This tree based query language is crazy as shit! Because it is not just a query language but also has some weird transformational capabilities.
And also the thing that is weird is that the HTML query language can be changed by the JavaScript language!
Let's look at an example
Let's suppose we have a tree structure like this
<div class="one"></div>
<div class="two"></div>
and the JavaScript holds a tree fragment <span class="myspan">text</span>
and the CSS says
.myspan { color: green; } .one span { color: red }
.two span { color: black }
the JavaScript reading that fragment css properties will see that "color" = "green"
but placing it inside of the parts of the HTML tree gives different values for the color property. Some people will mistakenly claim at this point that the is mutation of the global state but that is obviously incorrect. The CSS state has not been mutated at all, what the HTML query has done essentially is run a transformation and output an object, the CSS state remains unchanged because JavaScript can use the CSSOM to query what the data in the myspan class is.
JavaScript can mutate the value of the CSS classes, but HTML cannot. HTML essentially copies all the classes, runs a transformation, and outputs the result.
This is actually a pretty interesting situation, I don't feel that there is any similar architecture anywhere. I don't feel it really fits with DSSL or Latex (because of how JavaScript works with HTML)
Now although I don't feel that I have ever really had the problems that other people of undoubtedly superior programming ability seem to have with this, I can see how this unique and somewhat accidentally arrived at architecture can be irritating to people.
Note - when I say I don't have any problems I mean sure, I can create bugs with this, I can find bugs impacting me with this, but I've never really had long running hard to resolve bugs due to CSS/HTML. Bugs that are generally hard to resolve I find are in the JS stack.
Going back to the browser defaults thing - again not really a good example of either of our analogies, more an example of how every programming language has its idiosyncratic and stupid things you just have to learn about it and keep in mind or they will bite you on the ass.
on edit: obviously I am not making any claims as to internal implementations in browsers and how they do it, I am just discussing the external experience of these languages working together and how to think about them.
.one span {color: red}
.one span {color: purple}
inside of a CSS file.
Again I don't think I could consider that as mutating state.
This is mutating state
let color = "red";
if (x} { color = "purple"; }
because it mutates the variable value at run time based on something else.
The variable at different parts of the program have different values.
If you read .one span with the CSSOM in the above example it will always return color: purple.
That is not a mutated value, that is poorly written code that has been compiled down.
JS with CSSOM can read what the value .myspan, .one span and .two span all are.
because this is the point where CSS breaks down as a db holding properties, it is here that it is instructions for the HTML language on how it is to run transformations.
It ought to be possible to compose HTML documents the way Ted Nelson wanted to compose documents in Xanadu, it's a PITA to do because the classes are all in the same namespace although now we have Shadow DOM to manage this and you can even do it without JS with Declarative Shadow DOM.
It's a source of stress to add a class to the system with a simple, short and readable name and have to worry it is used someplace else. There is BEM but I despite it (not simple, not short, not readable)
I work on a React application that uses more than one plain-CSS framework and also Emotion and some other JS frameworks that generate more CSS properties. These are all leaky abstractions so if you aren't happy with the defaults the way I am with my boostrap-based RSS reader, you have to understand the abstractions of the framework and still understand the underlying CSS. Probably the worst time was when I had to get an application to run inside the Shadow DOM and vendorize some components to patch them accordingly.
One saving grace is that that LLMs are good at both coding CSS and answering questions about how it works.
That is the whole point of CSS classes: re-use. A CSS class is not meant to be used in only one very specific place. For that, you can select an element's ID or an elements HTML path, to style just that one thing.
2. Custom properties can be scoped to a particular part of the DOM [1].
3. @function has shipped Chrome; custom properties defined inside of an `at` function are local custom properties. So are the parameters.
4. Local properties stay local unless the outside explicitly references them (which it can't without knowing they exist)
[1] Limit the reach of your selectors with the CSS @scope at-rule -- https://developer.chrome.com/docs/css-ui/at-scope
It's like saying Rego[1] should just be done in a procedural language when in fact it also wouldn't be useful in that context.
[1] https://www.openpolicyagent.org/docs/policy-language
Tailwind is built on top of CSS. It is basically a library of hundreds of tiny "global", documented CSS classes.
This is how it works for me:
https://media1.tenor.com/m/QWdPngpHxZ8AAAAd/family-guy-css.g...
This is what got me. I exited development about eight years ago. Came back and was like, "WTF is going on with CSS now?" Completely lost and took me a few years working as an accessibility engineer to find my way back.
Its very hard having people telling you constantly how to "properly" use CSS, then learning all those techniques and approaches. Using those for a few years, then suddenly you have to completely unlearn it, then relearn it "the right way" again a few years later.
Completely maddening where front-end development has gone and continues to go.
Which is the actual issue. Learn CSS and treat it as part of the web stack.
I don't think that css evolved with specs, the HTML/CSS specs were descriptive rather than normative, and they came after the browser wars and the organic clusterfuck.
- Linus Torvalds.
Source of the quote above -
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
Transcript -
https://terence-xie.medium.com/linus-torvalds-the-mind-behin...
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.
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.
Nobody said split design and specification. Specification is not development.
I don't know anything about tracking.
Anyone should be able to follow a recipe. And UI design generally follows recipes. Because UI’s simply suck when they don’t follow conventions.
"Anyone should be able to follow a recipe" is far from reality, especially since the vast majority of recipes are not written for the kitchen illiterate.
Slightly less facetiously, "anyone can follow a recipe" makes about as much sense as "anyone can follow a README". Is it some arcane black magic that only a select few can decipher? No, but at the same time if you don't recognise that there is a baseline level of technical literacy needed to actually follow your average README then you might have your head stuck too far in a bubble.
Have you looked at a typical recipe recently? Here's an example (https://www.bbcgoodfood.com/recipes/oriental-egg-fried-rice) from the "quick and easy" section of BBC Good Food, a site that's regularly in the first page of search results for various recipes. Never mind that it expects you to have procured cooked chicken breasts from somewhere (and oh boy are those easy to turn into a bland, dry, rubbery mess if you don't know what you're doing)...do you honestly think there is no room in those instructions for someone who does not already know how to cook to screw it up?
Here's a recipe (https://urbanfarmie.com/instant-pot-jollof/) for a more complex dish that I am intimately familiar with, which is how I can tell you for absolutely free that if you just "follow the recipe" as described you will very easily end up with a soggy mess at best and burnt rice at worst.
Or - since you seem to like patting yourself on the back about onions - the next time you're following a recipe and it tells you to "sweat" or to "caramelise" onions or "sauté until golden", maybe spare a thought for how likely it is that someone who is actually new to the kitchen will get the correct result.
Talk about bubbles
My kids learned to cook from age 9. Now everyone can cook in this household.
I can’t take any adult who says it’s hard seriously, especially since I grew up in a culture where I heard a myriad of excuses from ‘manly man’ who think of it as a woman’s job.
It’s lame and it says a lot about them.
Any good source of design recipe to share?
[0] https://www.refactoringui.com/
[1] https://www.youtube.com/steveschoger
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?
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.
I remember learning the different Java Swing layout managers back in the day. Again, being nested was fine. That said, if you were doing a large layout, you were probably reaching for GridBagLayout. Back in 1999... (And I recall that SWT layouts were even simpler?)
I'm willing to concede that many of the ideas in CSS are good. At the least, benign. User stylesheets were just flat out a rake in field, though. And I stand by the claim that percentage sizes is largely a massive foot gun.
Edit: I should say that I find native interfaces took a massive nose dive in many ways when we abandoned so many interface builders. I have no idea how nested your typical MS Access form was or was not. I know that designing and wiring them up was far easier than what I typically see today.
But the native toolkits have learned from CSS in many ways, and that is just accelerating as we see what new wonders get cooked up in a web context that people used to say "you just can't do this in a browser with HTML+CSS".
Where web development sucks is when we try and rube goldberg getting an icon where we want it, or anything sized the way we want it. It is akin to forcing yourself to play mouse trap every time you want to align something. (With some common alignments still just not supported? Or can we decimal align numbers easily finally?)
Vertically aligning a set of decimal numbers with the separator the same place would be challenging in GTK and Qt and several others, unless you make some not well-supported assumptions and simplifications.
And reflow is generally being handled much better in most web apps than it is in native ones, if the latter actually allow it at all (more likely, they set a minimum window size that handles the expected layout just fine).
Also interesting to note that the the much lauded arrival of constraint-based layout across all apple GUI toolkits about 10 years ago (driven in large part by the needs of iOS) has not revolutionized layout APIs or algorithms in general.
At least in something like GTK and Qt you would be more than justified in just punting on the semantics of the receipt and formatting a fixed width set of numbers to call it a day? In HTML, doing that feels extra wrong. (But, indeed, you can do the same "fixed width" with non collapsed whitespace, even in HTML.)
And it isn't like this isn't a somewhat solved thing in long existing layout engines. Aligning to variables and such is very common in math texts. And largely not doable in HTML.
Reflow is one that always strikes me as largely misguided. No amount of reflow will make most websites look good on a gigantic monitor. Same as no amount of reflow will make most documents handle someone's name that is actually a novel. It just doesn't make sense, for many reasons. And yet we will put forth herculean efforts to maintain "reflow" based on content in so many places.
Shared library components is where this could work - each individual application would be able to scale the component's size to what it needs.
Even in Firefox, the dream of meaningful styles across sites is largely dead, I thought.
There are people who read that?
> Everywhere else? Good luck.
Same as with alternate stylesheets or a reasonable line of death. For all the annoying things Mozilla does, Firefox is still a great browser and for some measures the only shop in town.
> meaningful styles across sites
You can also modify the browser chrome with it, and I think UBlock Origin uses it for modifying the page. Also some settings are exposed via a UI, so also lawmen not knowing about user.css might still use the user (agent) stylesheet.
Look at MDN, the gold standard for web docs, on Grid: 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/
Atomics vs Usability. Everyone needs CSS. No one needs to *write* CSS.
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).
> It uses CSS Flexbox (rather than CSS Grid) for high flexibility.
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.
The vast majority of what we learn is in a professional environment. I can't build a hobby app with hundreds of millions of active users. We learn at work, and that means sometimes it sucks. But that's why we have blameless cultures, because we all realize you can't learn unless you first do it in a shitty way.
It's also why AI replacing juniors is terrible. Juniors need to make mistakes and figure things out. That's how they become experienced seniors.
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.
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.
Not every tool out there has the same educational requirements. And there's no reason why they should.
"Print length : 1126 pages"
Ok, I'd say it's legit.
If you can fully explain JS (an inexplicable bodge built on a tower of inexplicable bodges) in less pages then CSS almost definitely sucks.
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.
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)
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.
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/
[1] https://www.joshwcomeau.com/
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.
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.
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.
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.
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.
It's almost always an inequivocal mistake to use a feature that was released last year.
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.
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.
If I understand what you're saying, that's more about how you use (or don't use) combinators.
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
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.
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".
Claude and Grok output garbage:
https://claude.ai/artifacts/fc5ef98b-a9f8-48c9-b0ea-b60c778d...
https://grok.com/share/bGVnYWN5_a5cab471-1c3a-42ab-a25e-c491...
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
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.
This really isn't about CSS, it's about screen hardware - and the thousands of constantly evolving products in the market.
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.
There are too many good features that aren't being added to CSS because browsers don't want to slow down on bad sites.
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.
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.
That's one very strong indicator that you are doing it wrong.
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.
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.
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.
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
[3] https://github.com/w3c/csswg-drafts/issues/1724
@scope only works for selectors you add, but there are a ton of properties that even break through closed shadow roots.
That is, there is no nested reusable unit.
The number of CSS pre-processors that have been invented to fill this gap is obscene.
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
the "it" you have to learn has constantly been a moving target. That's its biggest problem.
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').
Good luck.
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'.
Yes, it will work as it used to 15 years ago. You will get laughed out of a tech interview for it though.
> 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?
Web frontend as a whole is a dog chasing its tail.
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.
2) doesn't seem to be a very big issue, this kind of stuff is very common in many programming languages as well. I don't remember struggling with this even as a beginner, and it's the first time I encounter a complaint about this as well.
3) Fair point, and the inheritance and specificity rules are very complex as well
4) On the other hand, backward compatibility is stellar (and I guess that it's your point in your last paragraph). Your 20 years old CSS file still works today and doesn't even feel really out of place. We could wish the web platform didn't evolve so rapidly, it makes it very difficult to implement.
5) It's very easy to center a div vertically now. Therefore, it can only be a critic of old versions of CSS, not the current one. Do you have another example of basic things that ought to be easy but aren't, or aren't possible?
5) Doesn't seem to be a very big issue. I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
Single-colon is a pseudo-class, for targeting elements based on some external state. I learned these as "pseudo-selectors" but it seems that's not the right name.
Double-colon is a pseudo-element, for targeting inner parts of an element that themselves aren't actually an element in the document.
CSS 1 & 2 apparently conflated the two, and CSS 3 allows one column for CSS 1 & 2 pseudo elements. I never noticed it wasn't all of them. Since I learned CSS right before CSS3, my situation kinda makes sense I guess.
Single colons everywhere have felt easier and more regular to me, so I've written basically everything with single colons except maybe the odd CSS 3 pseudo element here and there. But it seems the two colons will be mandated going forward.
I guess I'll have some edits to do, though I do hope and kinda expect they won't break backward compatibility.
https://stackoverflow.com/questions/17684797/should-i-use-si...
The original suggestion was LISP-like or X.11 configuration file syntax (https://www.w3.org/Style/CSS20/history.html) - XML was still too new (but look at https://www.w3.org/wiki/Xsl-fo if you want to see what the W3C came up with for "styling, but in XML format for XML documents"). My guess is that the declarative shape imitates SGML with a C syntax to make it easier to understand.
> It's too global. This is good for consistent styling but bad for modularity.
Yeah, that was an explicit design choice - one that we're now asking for (and getting) more control over as the web continues to expand, but it's not like it wasn't considered, it was considered and rejected for MVP as it were.
> Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
https://www.w3.org/TR/CSS1/#pseudo-classes-and-pseudo-elemen... were in CSS 1 released as a specification in 1998. Ugly-and-weird-and-special-cased ... sure, but what would you replace them with?
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.
https://en.wikipedia.org/wiki/Not_invented_here
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.
It's like wondering why this grape doesn't taste like fried catfish. They're both food. Why don't they taste the same?
Width and height are meaningless for inline elements, but automatically changing the display would be more confusing, not less.
Really not sure what you're trying to get at there, obviously any element that displays will have a width and height. Maybe you meant a user specified width/height, but the entire point of my post is an inline-block is an inline element with a specifiable width and height. And we've always had the IMG tag, which is also an inline element with a specifiable width and height. The obvious and intuitive choice would have been to not put artificial limits on inline elements.
You could even do something crazy like `* {display: block;}` if you really want, and then go from there. Nobody can stop you. The freedom is yours.