IMO the cascade is the exact problem with CSS. It worked fine when all it was dealing with was super simple documents with a few rules here and there, as soon as we started making applications the cascade causes endless headaches, and most modern methods of handling CSS like modules or libraries like Tailwind are made specifically to avoid cascade/specificity issues. Conceptually CSS is not really all that complicated, but in practice when you have dozens or even hundreds of CSS files for an entire app, it simply becomes a herculean nightmare to deal with and to wrap your head around.

I think developers nowadays being coerced into being a jack of all trades, master of none contributes to CSS being the least studied and practiced by full stack devs. Such devs would also be much more inclined to put their time into, for example, learning and practicing databases rather than improving their skills regarding UIs, and for webdev that means skimping on CSS while just doing the bare minimum, mediocre thing to get it working.

It has been my experience that those that complained the loudest about CSS, expected to know it without actually studying or learning it. They already know a "real" language, so why should they have to study a "toy" styling language.

When it comes down to it, making a great looking and maintainable page is just as much work and planning as building a good backend codebase. Neither one just happens.

I is certainly true for me that I didn't take the time to learn the intricacies of CSS behavior and I still think the cascading properties are the worst feature, namely concepts like specificity. It is hard to keep a mental model of styling rules and at some point it is just degrades to trial and error.

Nobody came up with a better alternative though (apart from the many dialects that transpile to CSS again).

Video games became a lot better when developers stopped saying, "You just haven't taken the time to learn it and don't understand it", and started saying, "That's my fault for designing it that way. Let me redesign it so that it's accessible to everyone in my target audience". I wish programming languages would be humble enough to do the same (although many are!).

All that complexity is a trap. It creates a need for people that have spent the unreasonable time to grasp a poor design, and then they have the secrets that others simply do not have the time to waste learning yet another poorly designed reindeer game. That complexity eats time, energy and is pointless. CSS is a shit show of poor design, poor documentation, and secrets.

I think that's true, but I think there's a more fundamental mistake in thinking that you can uncouple the HTML structure from layout, particularly when the layout rules make explicit reference to "parents" and "siblings".

The dream of CSS was that you could decouple styling from semantics. Your HTML would tell you what the page meant, and then your CSS would let you present it in whatever format was prettiest, and you could swap out CSS to let different users view it differently. But in practice, what happened was that the page ended up meaning nothing - it was just an app, a way for the user to accomplish a task, so instead of <h1> through <h6> and <p> and <em> and <cite>, everything is a <div>. The very concept of CSS was flawed, because we still thought of websites as documents at the time it was invented, rather than as an app platform.

That's perhaps why newer reactive frameworks like React or Jetpack Compose ditch this separation. The style in React is to just include CSS inline on the components. In Compose, you have Modifiers that let you specify the styling as explicit attributes on the component. They admit that they're building a UI framework, not a document overlay, and get rid of the content/presentation separation as a result. It's all presentation.

Tailwind is the closest popular thing to that and it's no wonder it's become so liked. Not so much in terms of providing a better layout system, but it just removes so much of what's wrong with CSS, at least for those who don't like it.

I haven't seen anything out there that provides an alternative but it does seem like CSS has almost added enough features you could actually build something that works. Alternatively it could be done through higher level abstractions built on something like React: <Flex>, <Grid> etc.

I don't have the time to spend weeks for every little tool to study its details and edge cases, I simply want to use them and get stuff done. If a tool is actively counterintuitive and hostile to its user, then it is flawed and it is no wonder users will seek out alternatives.

That's incredibly arrogant phrasing by both you and the author.

Here's a better explanation of the hostility towards CSS.

Nested flexbox had bugs in IE11, which wasn't end of lifed until 2022. The nested CSS in the article came out in December 2023.

CSS first came out in 1996.

The current state is much improved, but don't pretend there wasn't a solid 20+ years of sucking before that.

You can apply that line of argument towards anything though, it's not particularly insightful.

What do you mean it's not possible?

I love the fact that CSS is cascading; inheritance is a great idea, "where it fits". The main reason I like the cascading in CSS is because it is inherently a tree, and when it comes to parsing documents (using context free or non context free languages) a tree is very often a good fit. That and humans have long used trees (abstract or otherwise) to organise knowledge.

And since documents "fit" trees way more often than not; I'd say CSS is a good fit.

I learned it 30 years ago and back then and for some time it was not clear whether it will prevail.

There used to be DSSSL and JSS. The former came out if the SGML world, like HTML itself, and it was kind if the obvious solution to adapt it for the web. The latter used JavaScript syntax and was Netscape's favourite, which also made sense, them being JavaScript's inventors.

(A maybe interesting aside to this story is that JavaScript actually predates CSS, at least if we go by the dates each shipped in a browser.)

I have also been doing CSS for 20 years but it seems you have some skill issues?

You obviously don't need to learn 20+ years of specs, just as with any programming language, markup language there is some stuff you need to use it in a modern way, the other stuff you can pick up as time goes on.

You actually don’t let people use a bandsaw if they’ve demonstrated reckless behaviour.

Would you hold another programming language, such as JS, to the same standard?

You don't tell people to be careful when using a saw?!

How about we do both? We expect people to be able to use the tools, you know, properly, and make sure the tools are well-designed?

> How dare people use CSS without learning in-depth all 20+ specifications! It's an outrage!

Is strange reaction to:

> ... then have a strong opinion after they were forced to use it for a day.

There is not problem with using something without understanding all complex rules. Point is about forming strong opinion based on superficial knowledge.

People are not humble these days.

It's moving in the right direction, but I'd still say that CSS has more quirks and misbehaviors than the common subset of JS...

The cost is increased complexity in both the CSS spec and browser implementations.

Old school flexing on us with the scheme. They don’t know about the sosofo!

Well, I'm one who defaults to browsing with JavaScript off and turning it on only when strictly necessary. For me, the advantages of no JS are so compelling that I can't see me changing unless some major paradigm shift in browsing were to take place to upend the advantage.

It's not JavaScript that I'm against but the many abuses that websites inflict on users—privacy violations, pages of many tens of megabytes long but which only contain some 10k or so of text, the incredibility slow page load times, etc., etc.

As far as I'm concerned CSS is capable of just about anything I require of a webpage.

It seems a shame that not more users are aware of browsing sans JS with a button to turn it on and off. After experiencing the advantages it's quickly habit-forming. The increase in speed of page loads alone justifies killing JS.

I have been using NoScript for years and I find calling it "perfectly usable" is a bit of a stretch at least for my use case. I can only see it being "perfectly usable" if you only visit mostly the same sites most of the time and have already enabled whatever you need to enable.

I visit new websites all the time because of HN and Reddit, and without JavaScript many sites just don't work or look too broken for me to want to read anything. Unless we collectively decide to stop using buttons instead of anchors for navigation and stop having external, unrelated JavaScript blocking the actual site (that, sometimes funny enough, doesn't require JavaScript to function), it's not going to get any better.

I went through a phase where I think JavaScript is bad and have used CSS instead of JavaScript for a lot of things (mostly because I enjoy writing CSS). The thing is if you have ever tried developing any substantial and moderately complex feature for an actual product with CSS instead of JavaScript, while keeping them readable, maintainable and scalable, you will realize that they are good for different things and talking about them in a mutually exclusive way isn't helpful.

Both CSS and JavaScript are constantly evolving, I agree with you that there are now things that we should do with CSS instead of JavaScript and increasingly more so.

"have you ever tried living with noscript for over a week?"

I have been living without Javascript, and without a mouse, for over 20 years

When I began using the web, Javascript did not exist

Extracting text for reading and downloading files keeps getting easier every year

I generally avoid using a browser to make HTTP requests; I sometimes use a text-only browser to read saved HTML (offline)

that’s great! for the record, i am “pro noscript” (whatever that means). and i hope you didn’t take my comment personally. i think it’s more round what others will find compelling. for me, personally, i view “noscript” as valuable per se. i just don’t think it resonates well beyond our nerd-dom, such as it is. love the article brw, and feel ashamed that ancillary stuff like this dominates the discussion on these topics… :)

Same here, I have noscript almost always on. The problem is some things don't work without JS. Google and Bing search, youtube, even duckduckgo in plane FireFox. The later works in Tor browser, that's what I'm usually using. I usually skip on most other things that require JS to drive blinking ads.

> fwiw, i've been using the internet with noscript and i find it perfectly usable

Genuine question though: you just run a ton of apps instead, right? Windows apps, iOS apps, whatever. Right? Because you still want to use (and not just "look at") Facebook or WhatsApp or BSky or Drive or CoD:BO6 or... everything. And all that stuff runs in an environment with the same privacy-compromising power (generally much more dangerous, frankly).

I just don't see a situation where "use noscript" doesn't really just mean "use your phone so you don't have to use your browser". I mean, why bother? You're not winning anything.

(Quite frankly most of the people I see in this argument eventually admit this straight up: "no javascript" really means "no Google" to them, and their goal isn't privacy at all except as a proxy thing; it's the destruction of the World Wide Web as a platform in favor of Apple's offerings.)

"Doing less & letting the browser do the thing is a very nice win."

If only they would do it nice and consistently, I would agree. Sadly they don't. On one plattform you get sliders in this color who pop in when the mouse moves there, on another you have fixed size sliders of a different color and style. Impossible to make a coherent style like this.

More than 99.9% of web users have never heard of javascript.

Thanks! Sorry if I came off as brash, time has been tight recently. You've already put a lot of work into a very informative article, and it's appreciated. The outlook is solid. I'd like to find an opportunity to revisit some of my own code with your writing in mind.

Part of the reason for mentioning the radio-tabs is because I was working on my own implementation for a personal project a few weeks ago. My goal was specifically using the role="tab"/role="tabpanel" pattern, but my read of the guidance left me feeling like I was trapped with using JS to set those. Since it was timeboxed, I bailed out to augmenting it with JS for and moved on.

My hope was maybe somebody on HN with more of a background on accessibility could interject some thoughts here.

could you give any examples of how the page's accessibility could be improved - apart from your dislike of the background color

you're calling the post un-accessible and telling people to not use it as a source - i'd like to know why you think that, and if there's any way to improve the accessibility

Alternate stylesheets don't persist (at least in Firefox), which is really annoying.

Media queries are really nice though. Being able to provide a night mode alternative without even asking the user, assuming they've set the OS to their preference, is really seamless.

DevTools in Firefox and Chrome both have a `prefers-color-scheme` override built in, no extension required.

> JS to persist the setting.

Yes, local storage is crucial functionality. I don't get people who disable JS, but I suppose if they have a bunch of sites they whitelist it's less painful... but then they must trust those sites all the time? How do they know if those sites haven't installed new scary scripts?

Perhaps one possible solution is for browsers to offer a setting to enable all the "safe" functionality of javascript such as button events for fancy carousels, but block the stuff that causes anxiety. I suppose then we'd all argue about what aspects are safe vs scary.

that's the "auto" option, but the comment is taking about adding buttons to switch between the themes too

That would be the media query; sort of a long-hand way. I learned about the color function for settings the vars from the article, never saw those in use before.

Hmmm, I thought you had to register these with JS first, but my browser seems to recognize them.

The soft-requirement for hyphens is a form of namespacing: nothing precludes whatwg from adding <use> or <want> elements to HTML in the future, and that would conflict with and possibly break your page.

It worked when I zoomed in, thanks. That's impressive.

My interpretation is that although making your site a unique snowflake is fun, it's ultimately a burden on the users.

GUIs are successful when they follow visual and behaviorial standards. With everything that CSS and JS can do, every website becomes an exercise in discovery just to be able to use it for its intended purpose.

"makes it expensive now to direct things via your own server"

can you expand on this? why expensive..?

i figured Visa and company would mandate some JS monstrosity. However ive had some really ancient weird credit card online forms in Asia that i suspect have no JS

I am pretty comfortable with CSS, enough to find tailwind useless. I've done front-end work exclusively too (not anymore). Just because one has the skill doesn't mean they can't acknowledge the stupidity of it. People bash CRUD code not because they can't write it, it's just boring and sometimes wrong too (crud API, don't get me started on that)

You're right.

And the fact that yours was the only comment to point this out...

What part of JavaScript language should you not use?

The only one that comes to mind is is `with`, which is officially discouraged in the spec.

I suppose the other one is type coercion. (Like [] + [] stuff. That's no end of "ha ha JS weird.")

> pretty straight forward

Anything but. It combines whitespace collapsing and text wrapping in one property and makes a mess of both.

See https://drafts.csswg.org/css-text-3/#white-space-property to get an idea of how complicated it is.

The MDN article is self-contradictory, e.g. note how the example don't match the "syntax" section.

Plus, it has inconsistent quirks with HTML textarea.

I suspect, as with programming languages, some people think in a way that makes it easy for them and others think in a way that makes it hard.

Personally -- and I'm no web dev, so I probably don't count -- I think CSS is hard (maybe more irritating than hard, but in any case I wouldn't call it easy). In large part because the syntax is ugly, but also because it just doesn't "mesh" with me. If I'm reading it or writing it, I always feel like I'm having to decode it. But I can easily and happily work with some programming languages that most devs would cross the street to avoid.

Maybe that's also why some people are attracted to being web devs and others aren't?

As a user, nothing would thrill me more than if web pages just stopped using JS, though, so I am very happy that there is a feasible alternative to doing that that web devs could enjoy!

I have used it recently, it’s now back to doing what it was supposed to, originally: Float objects into text.

> Unless you use the subset of CSS that you have decided to learn + use. Not unlike C++.

Definitely sometimes.

I generally avoid vh, and rely more on calc and vw to calculate any height that needs cropping, padding or scaling.

For example dynamically equalising the height of boxes with unequal content - used to be something you did need JavaScript for.

Another is setting widths, heights and gaps using a css grid to create responsive mosaic image layouts.

text-shadow works. Was the use of box shadow a mistake?