I really do appreciate the nesting they've added but looking at it as a whole, CSS is a really strange and in my humble opinion, a terrible language. Perhaps I'm just holding it wrong, but it's just so complicated and messy, it sometimes feels like you're just arranging arcane runes in different ways until you make it sort of work for you. It's both a system for styling text based on inheritance, and a layout system for block and inline elements, nested recursively but without inheritance, only containment. I think it was a mistake to combine styling and layout, and I don't feel like adding more and more capabilities to something fundamentally broken can fix it.
This is all true. But it is what we have. I’ve found myself wondering if a model with stronger conceptual integrity could be designed and use CSS as a compilation target. For example, with container queries and calcs you could probably implement a more coherent layout system with just math.
Unfortunately the preprocessor languages we have just add even more half-baked ideas on top of the half-baked ideas already in CSS, according to the principle that syntax sugar = good.
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.
CSS1 circa 1996 was (practically) styling only. It's main purpose was decluttering HTML of all the font tags etc.
CSS2 included limited layout, but support in popular broswers lagged for so long that practically nobody learned the standard, just the vibe styling voodoo to get certain browsers to kinda partially work.
“I believe a lot of the negativity towards CSS stems from not really knowing how to use it. Many developers kind of just skip learning the CSS fundamentals in favor of the more interesting Java- and TypeScript, and then go on to complain about a styling language they don’t understand.”
from the article is talking about people like you, who refuse to learn something properly but have the arrogance to think they know better.
> The worst thing about CSS is that a lot of people don't bother learning it
How dare people use CSS without learning in-depth all 20+ specifications! It's an outrage!
When people have problems using a tool, you should look at the tool rather than blaming the people. People aren't going to change. You don't tell people to be more careful using a bandsaw; you install safety features.
Of course. I think JS is full of mistakes. To be fair some of the more egregious ones have been fixed, but there are still plenty left.
I'm a big believer in learning new stuff, when that stuff has lasting value. However it is far more efficient to fix things, a one time cost that benefits everyone, than to ask everyone to learn the quirks of a tool, a cost that is paid every time someone new comes along.
I learned CSS 20 years ago. My strong opinion is that it should be renamed Crappy Style Sheets, but that would take away from its primary fault, that it's cascading. As we learned in many other things, "inheritance" is not a great idea. Especially for something that gets applied globally, by a team of five people. "I will now adjust this thing over here, which will mess up everything my colleague is doing over there" is not a good feature. Its main feature is to give you complex rules how to overrule a certain rule. As a feature it's a a headache, when that's what you base everything around, it's bad. It gives you complex ways to target things, and over time it became even more complex. If you're a sane person, you've learned to avoid most of these otherwise you'll end up with .foo > .bar:nth-child(2n) ~ .baz . Then you will adjust that and come full circle to my argument, which is that it will break Mark's completely unrelated thing.
At the same time doing the simplest imaginable layout was a headache. I've done it, and it was interesting as in, this is a challenge and I am taking it head on, but it never should've been a challenge. Things have improved exponentially here, but it should've been the idea all along. Not how to cascade rules.
All other criticism, the syntax etc. is nitpicky and not important. As long as it's allowing you to do something useful without much fuss, I am ok with any syntax. But it didn't and it never did. Making a webpage layout should not be a full time job.
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 will say that though i am predisposed to appreciate and agree with an article like this, any sort of value proposition around "some users don't want javascript" just doesn't... hit for me. and, mind you: i am a card-carrying arch user and have spent more time messing with browser scripting and web crawling, and am more of a True Believer than most. it's just such a niche user preference that i think it should largely be simply ignored. yes, i would love the world to be better for the "noscript" universe, no, i don't think that any individual "grassroots" effort should stake itself on "no javascript" being any part of its utility. i think there are a million other reasons why CSS should win out that are more compelling than an appeal to what feels, extremely ironically, like a callback to the "but 10% of your users use IE6" days... all in all, yes: this is somewhat of a minor point wrt. to the article (which btw i think is great), but i am just calling the "trend", such as it is / has been, for what (i think) it is.
The drawcard for me is that I can do in a few bytes of declarative CSS things that take many lines of imperative JS to get right, with fewer weird misbehaviours, fewer framework compatibility issues, and a lower time-to-interactive. Working under noscript conditions is just a cherry on the cake.
They mention the users who don’t want JavaScript as an aside, but most of the post is devoted to just showing the CSS functionality off.
The other motivation mentioned is performance. But they don’t belabor the whole motivation thing anyway. IMO that’s a good, focusing on showing off the tech seems more productive anyway.
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.
fwiw, i've been using the internet with noscript and i find it perfectly usable
for any sites that do need js, i simply enable it for them from the extension, so it never gets in the way with sites i use regularly
it's pretty nice for performance/battery and security
have you ever tried living with noscript for over a week? i feel like your perspective could be a bit mislead, because i felt the exact same way as you before i started using noscript
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.
Exactly, I too have been sans JS for as long—before it came on the scene.
As I implied in my earlier post most users these days don't realize the advantages of turning off JS. Trouble is, most browser manufacturers make it difficult to disable JS, either there's no switch in the settings or it's buried so deep it's essentially dysfunctional. Here I'd especially single out Mozilla with Firefox, one could once easily disable JS but the function was removed I suspect after pressure from Google—as you would know without JS ads are almost a non event.
On Android I use Privacy Browser which makes it dead easy to turn JS off and on, and on Windows and Linux it's Pale Moon with a plugin that provides a one-click switch.
Seems to me too little is made of these advantages in tech sites such as HN—although that's not surprising given that many here make a living from JS programming and are paid by companies who financially benefit from sending mega-sized JS-loaded pages to web users.
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.
Not anymore. It's very usable when JS is not needed. I've seen more than 5MB/s Tor downloads. The good, or bad, thing is you don't control the exit point. You can only change it by resetting the circuit. Some websites are sensitive to user's location.
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… :)
> 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.)
I enjoy the opt-in experience for interactivity when using noscript. There's a few cases where it can be janky in particular payment flows but I've been noscript for almost 10 years so I am used to it and the workarounds don't bother me as much as CPU hogs and random sites bombarding me with all kinds of video ads
i have js enabled for webapps such as discord and bluesky - having js disabled by default for sites i haven't visited is very good for limiting attack surface
for sites such as facebook, i don't really use them that often, so i only run js on them when i feel like consenting to it
yes, i use programs/apps, but attack surface and threat models aren't binary, so it's still better to make things more secure
> yes, i use programs/apps, but attack surface and threat models aren't binary, so it's still better to make things more secure
But again, the point is that market decisions aren't microeconomic. The world where everyone uses noscript by default is a world where no one builds web apps anymore (because the platform sucks by default) and everyone uses native apps from whoever the dominant vendor happens to be. And that's worse (much worse, by basically every metric, including privacy and security) and not better.
Your logic only works if you're a parasite: you can use noscript to "protect" yourself only if most people don't.
Worse for whom? Not the end user, where again they just permanently enable the app once if they are going to use it often. This makes it little different to the consent for browser permissions, like notifications or access to a microphone or camera, which everyone does use. If everyone used noscript you might even see a change to the default interface to make it more like the permissions flow.
Separately, we already live in a world where people tend to pick "native" apps (e.g. Discord, Slack) that are just wrappers around the webapp, and on the phone you have similar behavior where people often prefer the "native" app (e.g. twitter/X) over the mobile web version. Despite this asymmetry, web apps continue to be built, and they would continue even if everyone used noscript.
i'm not a "parasite" for having a personal threat model - i'm a person with a double digit number of browser CVEs, and i think it makes sense to take extra precautions because of that
and like, noscript doesn't mean you can't run javascript - it just means you have to consent to it, just like it was in the past with flash and java applets
your argument kind of assumes noscript users never run javascript, which is false
"Because you still want to use (and not just "look at") Facebook or WhatsApp or BSky or Drive or CoD:BO6 or... everything."
For many people that's true and good luck to them.
For others, myself included, I can't think of anything worse online than being locked into mega corporations such as Google and Facebook. I don't have a Google or Facebook account and I de-Google my Android phone by either disabling or removing all Goolge apps (there are pleanty of alternatives).
I'd bet that if you did a survey you'd find that those who can live without scripts are also those who can essentially live without Social Media and or Google apps. However, for many, the imperatives of Social Media are so strong that no argument would ever convince them to go script-free.
In essence, here we're dealing with diametrically opposite worldviews and there's little point or value in trying to reconcile them.
I agree; I don't find the noscript-ians to be useful or worth targeting.
At the same time, I want to emphasize more strongly the flip side that I think you don't at but don't go much I to: I do find that writing less code & using the platform is enormously valuable! Doing less & letting the browser do the thing is a very nice win.
"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.
I think that if you want to follow WAI-ARIA practices, the aria-selected, tabindex and aria-controls need to be updated via JS when the active tab changes? I'd love to be wrong about that.
Accessibility is often an afterthought. And, sometimes there's an assumption that by working with HTML/CSS directly, accessibility comes built in. Just Something to keep in mind when choosing an approach.
I am aware that people who read the blog might base parts of their websites on my examples, so I definitely want to make sure they're accessible as to not cause a negative ripple effect on the web.
I don't have a background in accessibility, but I try to do the best I can. I try out what I make with various accessibility tools (e.g. keyboard navigation, screenreaders), and also read up on how things should be handled.
For the radio tabs specifically - they are keyboard navigable, work with screenreaders, and follow the tabbing to content practice mentioned in the WAI-ARIA example[0].
Did you read the article? The author specifically addresses accessibility in multiple places, including taking extra steps to work around browser bugs [0].
I know like 10-15 different languages, and CSS is by far the hardest to read and understand. It's easier to understand x86 assembly than CSS. CSS is basically pre-tokenized input that drives a renderer, but they sort of went halfway and didn't really make it real tokens or really human-writable.
I'd say that it should take the place of ASN.1 in the RFCs as an example of "what not to do."
> I know like 10-15 different languages, and CSS is by far the hardest to read and understand.
CSS is hard to know, even if you know 15 languages.
I can understand many programming languages and write in a subset of many of their features, but I wouldn't claim to know them. That would require a monumental amount of day to day effort, in my opinion (see https://en.wikipedia.org/wiki/Illusion_of_explanatory_depth).
To me, the best way to understand CSS is to evaluate it after rendering, and I have been writing it for decades.
I always knew that there should be a way to have a button to change light and dark mode on my website without javascript. But I couldn’t figure it out (pre llm era) and gave up and just used javascript. Now it’s time to make an update on that. This blog motivated me.
I do wish we would start to move further towards a sane set of front-end application (logic) technologies (I don't think the current leader, Typescript NextJS is it)
But I do appreciate that CSS is starting to feel a lot more sane these days.
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.
is there a book that you'd recommend to a CSS noob so that a hypothetical backend developer could learn modern CSS that allegedly does not suck in a curated and guided, not pick-your-own-adventure via blogpost and tutorials way?
For making UIs, web or not, I always go for HTML+CSS. It can be a bit awkward to interact with native code (e.g. C++), since you'll have to generally do message passing which involves serialisation/deserialisation.
Given that HTML+CSS is really damn powerful as this post makes clear, how do other UI toolkits compare? I've always wanted to do more with Qt, but probably it won't come near HTML+CSS in terms of functionality and flexibility?
This article has lots of nice stuff in it but ... that first example in the tweet at the top,
cool-thing {
display: flex;
&[shadow] {
box-shadow: 1px 1px #0007;
}
@media (width < 480px) {
flex-direction: column;
}
}
and html like
<cool-thing shadow>wow</cool-thing>
I pasted it into a file and it doesn't work. I honestly didn't expect it to work. I thought you needed more to get a cool-thing element but in any case, it's not encouraging to see the first example fail. Am I missing some context?
-- update --
my bad - I think it was just subtle and I thought it wasn't doing anything. Thanks for all the replies
that snippet of code was never meant to be used, it was supposed to be illustrative code that fits in a tweet
text-shadow does make more sense if you're actually trying out the code, but the original intention was to demonstrate a more complex element having a shadow modifier
Same but with Swift instead of Haskell.
I’m an iOS/macOS developer, but I have to do a web app currently, and I was pleasantly surprised by how powerful and relatively easy CSS is.
I think the hardest part of CSS is the weird specific lingo. I recently had to do some flexbox work, and while it's pretty easy to understand the naming conventions are just screwy. JustifyContent, AlignContent, JustifySelf, AlignSelf, etc. These all have to do with different axis depending on how you set FlexOrientation (column or row). This makes it difficult for Anyone to jump into CSS work. Is this intentional?
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.
This should make WYSISYG HTML/CSS editors possible again.
Here's a thought. Build a WYSISYG tool like that. HTML/CSS only. Round trip; that is; it reads its own HTML/CSS and works on that, rather than using some separately stored representation.
If you want to use Javascript with this, it has to be inside a manually edited IFRAME or FRAME. If you have Javascript, it's probably for interacting with a server or doing something graphical. Or, more likely, for ads, tracking, and such. Not for layout.
Still waiting for "you no longer need CSS". Can we offload it entirely to figma, AI, or the designer? It's such a dumb thing to have to write code for, even lamer than CRUD, at least that does something.
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)
Alright, if you say so. But what stupidity do you mean? What do you mean offload it to figma etc? Why is it dumb to write code for... the job CSS is built for?
IMO it's more like PHP or JavaScript than C++. With C++ there are lots of different dialects in common use and you kinda have to learn them all to be good at C++. Whereas with PHP/JavaScript/CSS there are still ugly corners, but everyone pretty much agrees which the good bits are and which the ugly bits are, and you can mostly just ignore the old legacy bits.
vertical-align, yea, alignment in general is hard and IMO it's hard because it's a hard topic in general, CSS or native. but yea, it's not "vertical-align"
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 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.
No that often isn't the case. What is usually the case is that people don't bother the learning the basics. CSS is very easy. You can literally mess about with it on the fly in the browser and instantly see the result.
It is easier now than it has ever been. Since all the browsers for the most part implement the standards properly. Safari is the only standout and all the issues with that are well known.
> 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.
It is probably because you haven't learned the basics.
Whenever anyone has issues understanding CSS, they haven't bothered learning the basics and think they can flub their way through doing it.
I don't understand what is ugly about the syntax.
<some element selector> {
property_1: <some value>
property_2: <some other value>
}
It is about as straight forward as it could be. The difficulty with CSS is organisation as the web app becomes larger. There are well documented strategies on how to do this.
> 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!
Non-trivial functionality requires JS. Basic Websites rarely require JS. So I am not sure what you are trying to say here.
CSS is easy, but it's not simple - it's enormously complex. Imagine the worst sins you could commit in a Ruby or Python codebase, multiply that by 100x and that's a normal CSS codebase.
Honestly the best thing I tell people to get some decent css basics is try to build a few stylus themes.
You can instantly see the results in devtools. I can't think of any other language that does that besides html, and even then you have to save and refresh.
Css is pretty easy to pick up in the chrome devtools at least because it has built in autocomplete. Showing you exactly what you can set the values too etc
I really do appreciate the nesting they've added but looking at it as a whole, CSS is a really strange and in my humble opinion, a terrible language. Perhaps I'm just holding it wrong, but it's just so complicated and messy, it sometimes feels like you're just arranging arcane runes in different ways until you make it sort of work for you. It's both a system for styling text based on inheritance, and a layout system for block and inline elements, nested recursively but without inheritance, only containment. I think it was a mistake to combine styling and layout, and I don't feel like adding more and more capabilities to something fundamentally broken can fix it.
This is all true. But it is what we have. I’ve found myself wondering if a model with stronger conceptual integrity could be designed and use CSS as a compilation target. For example, with container queries and calcs you could probably implement a more coherent layout system with just math.
Unfortunately the preprocessor languages we have just add even more half-baked ideas on top of the half-baked ideas already in CSS, according to the principle that syntax sugar = good.
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.
CSS1 circa 1996 was (practically) styling only. It's main purpose was decluttering HTML of all the font tags etc.
CSS2 included limited layout, but support in popular broswers lagged for so long that practically nobody learned the standard, just the vibe styling voodoo to get certain browsers to kinda partially work.
“I believe a lot of the negativity towards CSS stems from not really knowing how to use it. Many developers kind of just skip learning the CSS fundamentals in favor of the more interesting Java- and TypeScript, and then go on to complain about a styling language they don’t understand.”
from the article is talking about people like you, who refuse to learn something properly but have the arrogance to think they know better.
You can apply that line of argument towards anything though, it's not particularly insightful.
The worst thing about CSS is that a lot of people don't bother learning it, then have a strong opinion after they were forced to use it for a day.
> The worst thing about CSS is that a lot of people don't bother learning it
How dare people use CSS without learning in-depth all 20+ specifications! It's an outrage!
When people have problems using a tool, you should look at the tool rather than blaming the people. People aren't going to change. You don't tell people to be more careful using a bandsaw; you install safety features.
Would you hold another programming language, such as JS, to the same standard?
Of course. I think JS is full of mistakes. To be fair some of the more egregious ones have been fixed, but there are still plenty left.
I'm a big believer in learning new stuff, when that stuff has lasting value. However it is far more efficient to fix things, a one time cost that benefits everyone, than to ask everyone to learn the quirks of a tool, a cost that is paid every time someone new comes along.
I learned CSS 20 years ago. My strong opinion is that it should be renamed Crappy Style Sheets, but that would take away from its primary fault, that it's cascading. As we learned in many other things, "inheritance" is not a great idea. Especially for something that gets applied globally, by a team of five people. "I will now adjust this thing over here, which will mess up everything my colleague is doing over there" is not a good feature. Its main feature is to give you complex rules how to overrule a certain rule. As a feature it's a a headache, when that's what you base everything around, it's bad. It gives you complex ways to target things, and over time it became even more complex. If you're a sane person, you've learned to avoid most of these otherwise you'll end up with .foo > .bar:nth-child(2n) ~ .baz . Then you will adjust that and come full circle to my argument, which is that it will break Mark's completely unrelated thing.
At the same time doing the simplest imaginable layout was a headache. I've done it, and it was interesting as in, this is a challenge and I am taking it head on, but it never should've been a challenge. Things have improved exponentially here, but it should've been the idea all along. Not how to cascade rules.
All other criticism, the syntax etc. is nitpicky and not important. As long as it's allowing you to do something useful without much fuss, I am ok with any syntax. But it didn't and it never did. Making a webpage layout should not be a full time job.
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 have also been doing CSS for 20 years but it seems you have some skill issues?
i will say that though i am predisposed to appreciate and agree with an article like this, any sort of value proposition around "some users don't want javascript" just doesn't... hit for me. and, mind you: i am a card-carrying arch user and have spent more time messing with browser scripting and web crawling, and am more of a True Believer than most. it's just such a niche user preference that i think it should largely be simply ignored. yes, i would love the world to be better for the "noscript" universe, no, i don't think that any individual "grassroots" effort should stake itself on "no javascript" being any part of its utility. i think there are a million other reasons why CSS should win out that are more compelling than an appeal to what feels, extremely ironically, like a callback to the "but 10% of your users use IE6" days... all in all, yes: this is somewhat of a minor point wrt. to the article (which btw i think is great), but i am just calling the "trend", such as it is / has been, for what (i think) it is.
The drawcard for me is that I can do in a few bytes of declarative CSS things that take many lines of imperative JS to get right, with fewer weird misbehaviours, fewer framework compatibility issues, and a lower time-to-interactive. Working under noscript conditions is just a cherry on the cake.
Deep down inside, however, I miss DSSSL.
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.
They mention the users who don’t want JavaScript as an aside, but most of the post is devoted to just showing the CSS functionality off.
The other motivation mentioned is performance. But they don’t belabor the whole motivation thing anyway. IMO that’s a good, focusing on showing off the tech seems more productive anyway.
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.
fwiw, i've been using the internet with noscript and i find it perfectly usable
for any sites that do need js, i simply enable it for them from the extension, so it never gets in the way with sites i use regularly
it's pretty nice for performance/battery and security
have you ever tried living with noscript for over a week? i feel like your perspective could be a bit mislead, because i felt the exact same way as you before i started using noscript
disclaimer: i'm the author of the blogpost
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)
Exactly, I too have been sans JS for as long—before it came on the scene.
As I implied in my earlier post most users these days don't realize the advantages of turning off JS. Trouble is, most browser manufacturers make it difficult to disable JS, either there's no switch in the settings or it's buried so deep it's essentially dysfunctional. Here I'd especially single out Mozilla with Firefox, one could once easily disable JS but the function was removed I suspect after pressure from Google—as you would know without JS ads are almost a non event.
On Android I use Privacy Browser which makes it dead easy to turn JS off and on, and on Windows and Linux it's Pale Moon with a plugin that provides a one-click switch.
Seems to me too little is made of these advantages in tech sites such as HN—although that's not surprising given that many here make a living from JS programming and are paid by companies who financially benefit from sending mega-sized JS-loaded pages to web users.
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.
Isn't the tor browser insanely slow though?
Not anymore. It's very usable when JS is not needed. I've seen more than 5MB/s Tor downloads. The good, or bad, thing is you don't control the exit point. You can only change it by resetting the circuit. Some websites are sensitive to user's location.
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… :)
The point of the post is helping change that perception.
> 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.)
I enjoy the opt-in experience for interactivity when using noscript. There's a few cases where it can be janky in particular payment flows but I've been noscript for almost 10 years so I am used to it and the workarounds don't bother me as much as CPU hogs and random sites bombarding me with all kinds of video ads
i have js enabled for webapps such as discord and bluesky - having js disabled by default for sites i haven't visited is very good for limiting attack surface
for sites such as facebook, i don't really use them that often, so i only run js on them when i feel like consenting to it
yes, i use programs/apps, but attack surface and threat models aren't binary, so it's still better to make things more secure
> yes, i use programs/apps, but attack surface and threat models aren't binary, so it's still better to make things more secure
But again, the point is that market decisions aren't microeconomic. The world where everyone uses noscript by default is a world where no one builds web apps anymore (because the platform sucks by default) and everyone uses native apps from whoever the dominant vendor happens to be. And that's worse (much worse, by basically every metric, including privacy and security) and not better.
Your logic only works if you're a parasite: you can use noscript to "protect" yourself only if most people don't.
Worse for whom? Not the end user, where again they just permanently enable the app once if they are going to use it often. This makes it little different to the consent for browser permissions, like notifications or access to a microphone or camera, which everyone does use. If everyone used noscript you might even see a change to the default interface to make it more like the permissions flow.
Separately, we already live in a world where people tend to pick "native" apps (e.g. Discord, Slack) that are just wrappers around the webapp, and on the phone you have similar behavior where people often prefer the "native" app (e.g. twitter/X) over the mobile web version. Despite this asymmetry, web apps continue to be built, and they would continue even if everyone used noscript.
i'm not a "parasite" for having a personal threat model - i'm a person with a double digit number of browser CVEs, and i think it makes sense to take extra precautions because of that
and like, noscript doesn't mean you can't run javascript - it just means you have to consent to it, just like it was in the past with flash and java applets
your argument kind of assumes noscript users never run javascript, which is false
"Because you still want to use (and not just "look at") Facebook or WhatsApp or BSky or Drive or CoD:BO6 or... everything."
For many people that's true and good luck to them.
For others, myself included, I can't think of anything worse online than being locked into mega corporations such as Google and Facebook. I don't have a Google or Facebook account and I de-Google my Android phone by either disabling or removing all Goolge apps (there are pleanty of alternatives).
I'd bet that if you did a survey you'd find that those who can live without scripts are also those who can essentially live without Social Media and or Google apps. However, for many, the imperatives of Social Media are so strong that no argument would ever convince them to go script-free.
In essence, here we're dealing with diametrically opposite worldviews and there's little point or value in trying to reconcile them.
I agree; I don't find the noscript-ians to be useful or worth targeting.
At the same time, I want to emphasize more strongly the flip side that I think you don't at but don't go much I to: I do find that writing less code & using the platform is enormously valuable! Doing less & letting the browser do the thing is a very nice win.
"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.
> some users dont want javascript
correct, nearly all dont
More than 99.9% of web users have never heard of javascript.
I'd believe 90. 99.9 seems aggressive.
A lot of people haven't heard of pancreatic cancer either. Explain it to them and see if they approve.
edit: IE javascript was probably responsible for at least half a dozen times their system has been ruined, and they know what tracking is.
> javascript was probably responsible for at least half a dozen times their system has been ruined
What does this mean?
Okay, but are those radio tabs accessible?
I think that if you want to follow WAI-ARIA practices, the aria-selected, tabindex and aria-controls need to be updated via JS when the active tab changes? I'd love to be wrong about that.
Accessibility is often an afterthought. And, sometimes there's an assumption that by working with HTML/CSS directly, accessibility comes built in. Just Something to keep in mind when choosing an approach.
I think so?
I am aware that people who read the blog might base parts of their websites on my examples, so I definitely want to make sure they're accessible as to not cause a negative ripple effect on the web.
I don't have a background in accessibility, but I try to do the best I can. I try out what I make with various accessibility tools (e.g. keyboard navigation, screenreaders), and also read up on how things should be handled.
For the radio tabs specifically - they are keyboard navigable, work with screenreaders, and follow the tabbing to content practice mentioned in the WAI-ARIA example[0].
[0] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-...
Did you read the article? The author specifically addresses accessibility in multiple places, including taking extra steps to work around browser bugs [0].
[0]: https://lyra.horse/blog/2025/08/you-dont-need-js/#fn:10
Ugh, the syntax for CSS is just so crappy.
I know like 10-15 different languages, and CSS is by far the hardest to read and understand. It's easier to understand x86 assembly than CSS. CSS is basically pre-tokenized input that drives a renderer, but they sort of went halfway and didn't really make it real tokens or really human-writable.
I'd say that it should take the place of ASN.1 in the RFCs as an example of "what not to do."
> I know like 10-15 different languages, and CSS is by far the hardest to read and understand.
CSS is hard to know, even if you know 15 languages.
I can understand many programming languages and write in a subset of many of their features, but I wouldn't claim to know them. That would require a monumental amount of day to day effort, in my opinion (see https://en.wikipedia.org/wiki/Illusion_of_explanatory_depth).
To me, the best way to understand CSS is to evaluate it after rendering, and I have been writing it for decades.
I feel the same way. I find it the worst part of the HTML / CSS / JS trio.
I always knew that there should be a way to have a button to change light and dark mode on my website without javascript. But I couldn’t figure it out (pre llm era) and gave up and just used javascript. Now it’s time to make an update on that. This blog motivated me.
It’s nice but probably not that useful as you still need JS to persist the setting.
For testing there are extensions which allow overriding the browser’s scheme (for Firefox anyway).
Isn't it just `prefers-color-scheme`
that's the "auto" option, but the comment is taking about adding buttons to switch between the themes too
Two of those wishlists css features already exist as specs:
> n-th child variable
See sibiling-index() and sibling-count() https://developer.mozilla.org/en-US/docs/Web/CSS/sibling-ind...
> Reusable blocks
See @function and @mixin draft spec, https://drafts.csswg.org/css-mixins-1/ and https://css-tricks.com/functions-in-css/
Both are available in chrome already.
TIL about baseline widely available.
I do wish we would start to move further towards a sane set of front-end application (logic) technologies (I don't think the current leader, Typescript NextJS is it)
But I do appreciate that CSS is starting to feel a lot more sane these days.
Vite (which is used by a large portion of modern frontend frameworks) by default builds the production bundle for baseline widely available: https://vite.dev/guide/build.html#browser-compatibility
> You are allowed to just make up elements as long as their names contain a hyphen
RIP any semblance of using meaningful tags for machine readability I guess.
it's a lot more readable than a bunch of divs
if an element that semantically fits your needs already exists you don't need to make up an element in the first place
Hmmm, I thought you had to register these with JS first, but my browser seems to recognize them.
And even if they don't contain a hyphen! You can just <use> <anything> <you> <want>
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.
What's the use case for machine readability these days?
is there a book that you'd recommend to a CSS noob so that a hypothetical backend developer could learn modern CSS that allegedly does not suck in a curated and guided, not pick-your-own-adventure via blogpost and tutorials way?
For making UIs, web or not, I always go for HTML+CSS. It can be a bit awkward to interact with native code (e.g. C++), since you'll have to generally do message passing which involves serialisation/deserialisation.
Given that HTML+CSS is really damn powerful as this post makes clear, how do other UI toolkits compare? I've always wanted to do more with Qt, but probably it won't come near HTML+CSS in terms of functionality and flexibility?
This article has lots of nice stuff in it but ... that first example in the tweet at the top,
I pasted it into a file and it doesn't work. I honestly didn't expect it to work. I thought you needed more to get a cool-thing element but in any case, it's not encouraging to see the first example fail. Am I missing some context?-- update --
my bad - I think it was just subtle and I thought it wasn't doing anything. Thanks for all the replies
That is just showing nesting with some older features
- https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting...
- https://caniuse.com/css-media-range-syntax
- https://caniuse.com/css-nesting
- https://caniuse.com/flexbox
Seems to work fine https://plnkr.co/edit/Sor4x5BlMwmyRqZw?open=lib%2Fstyle.css&...
it should work, did you put the css between <style> tags?
also the box-shadow is a box shadow, you might wanna change it to text-shadow if that's what you'd expect from it
text-shadow works. Was the use of box shadow a mistake?
that snippet of code was never meant to be used, it was supposed to be illustrative code that fits in a tweet
text-shadow does make more sense if you're actually trying out the code, but the original intention was to demonstrate a more complex element having a shadow modifier
Fantastic post! Learned a ton.
That is the most beautiful meow button I've ever seen!
Do hardened browsers also disable Wasm? I suppose so since you need a touch of JS to kick it off… darn.
omg that's so much prettier than it used to be. What they've done with it is extremely impressive.
Who would have thought UI layout and rich formatting would be the hard problem that destroyed personal computing.
Modern CSS is indeed great. I'm using modern CSS, htmx, and Haskell to develop apps and am loving it.
Same but with Swift instead of Haskell. I’m an iOS/macOS developer, but I have to do a web app currently, and I was pleasantly surprised by how powerful and relatively easy CSS is.
How can one learn modern CSS and is there an online reference that is up to date?
MDN is what you're looking for https://developer.mozilla.org/en-US/docs/Learn_web_developme...
There are a number of sites that aggregate some things, here is one
https://moderncss.dev/topics/
Recent survey of what people use to learn CSS:
https://2025.stateofcss.com/en-US/resources/
CSS Tricks article on this:
https://css-tricks.com/how-to-keep-up-with-new-css-features/
JavaScript is for more than augmenting CSS.
Colour picker isn't working for me on android Chrome stable 139.0.7258.158.
the picker's touch area is really small on mobile, you can use it but you have to be accurate
It worked when I zoomed in, thanks. That's impressive.
I think the hardest part of CSS is the weird specific lingo. I recently had to do some flexbox work, and while it's pretty easy to understand the naming conventions are just screwy. JustifyContent, AlignContent, JustifySelf, AlignSelf, etc. These all have to do with different axis depending on how you set FlexOrientation (column or row). This makes it difficult for Anyone to jump into CSS work. Is this intentional?
The great wheel of karma. All the stuff that made javascript despicable now makes css despicable as well.
Can you elaborate on what all that stuff is?
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.
> GUIs are successful when they follow visual and behaviorial standards.
Wouldn't that be a design or HCI issue, not something innate to a language? What is a behavioral standard?
Yes technically but the language enables it.
A behavioral standard would be that scrolling always works by sliding the scroll bar or using the arrow or page-down keys.
Or that the back button takes you to the previous page.
Just two examples.
Many sites break these and you have to discover what they replaced them with.
This should make WYSISYG HTML/CSS editors possible again.
Here's a thought. Build a WYSISYG tool like that. HTML/CSS only. Round trip; that is; it reads its own HTML/CSS and works on that, rather than using some separately stored representation.
If you want to use Javascript with this, it has to be inside a manually edited IFRAME or FRAME. If you have Javascript, it's probably for interacting with a server or doing something graphical. Or, more likely, for ads, tracking, and such. Not for layout.
Still waiting for "you no longer need CSS". Can we offload it entirely to figma, AI, or the designer? It's such a dumb thing to have to write code for, even lamer than CRUD, at least that does something.
Ask your boss to hire someone better at CSS than you.
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)
Alright, if you say so. But what stupidity do you mean? What do you mean offload it to figma etc? Why is it dumb to write code for... the job CSS is built for?
Unfortunately we are stuck with trash tailwind.
> Yes, the syntax isn’t the prettiest, but is it really that hard?
Explain float: clear?
Does that have anything to do with display: flow-root?
And white-space is not actually whitespace?
And when does vertical-align work vs not?
---
^ That is all CSS (and not particularly edgy CSS, except for flow-root).
So....yes, CSS is really that hard. Unless you use the subset of CSS that you have decided to learn + use. Not unlike C++.
Maybe this only proves your point, but there is no float: clear. They're separate properties.
IMO it's more like PHP or JavaScript than C++. With C++ there are lots of different dialects in common use and you kinda have to learn them all to be good at C++. Whereas with PHP/JavaScript/CSS there are still ugly corners, but everyone pretty much agrees which the good bits are and which the ugly bits are, and you can mostly just ignore the old legacy bits.
The sentence you quoted refers to the 'centering a div' example, not CSS as a whole.
is float:clear still a thing? I remember being a thing 15-20 years ago? I can't remember needing it in the last 10+
white-space seems pretty straight forward: https://developer.mozilla.org/en-US/docs/Web/CSS/white-space
vertical-align, yea, alignment in general is hard and IMO it's hard because it's a hard topic in general, CSS or native. but yea, it's not "vertical-align"
I haven't used float in at least half a decade. CSS is easy.
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 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.
No that often isn't the case. What is usually the case is that people don't bother the learning the basics. CSS is very easy. You can literally mess about with it on the fly in the browser and instantly see the result.
It is easier now than it has ever been. Since all the browsers for the most part implement the standards properly. Safari is the only standout and all the issues with that are well known.
> 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.
It is probably because you haven't learned the basics.
Whenever anyone has issues understanding CSS, they haven't bothered learning the basics and think they can flub their way through doing it.
I don't understand what is ugly about the syntax.
It is about as straight forward as it could be. The difficulty with CSS is organisation as the web app becomes larger. There are well documented strategies on how to do this.> 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!
Non-trivial functionality requires JS. Basic Websites rarely require JS. So I am not sure what you are trying to say here.
CSS is easy, but it's not simple - it's enormously complex. Imagine the worst sins you could commit in a Ruby or Python codebase, multiply that by 100x and that's a normal CSS codebase.
The syntax has never been the issue imo.
Agreed.
Honestly the best thing I tell people to get some decent css basics is try to build a few stylus themes.
You can instantly see the results in devtools. I can't think of any other language that does that besides html, and even then you have to save and refresh.
Css is pretty easy to pick up in the chrome devtools at least because it has built in autocomplete. Showing you exactly what you can set the values too etc
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++.
I don't agree with his "Do not the vw/vh".
I find vw very useful for a scaling pixel-perfect mobile portrait view that looks identical whether your mobile is 320px or 440px viewport width.
not my pronoun, and not what the section talks about
if you're going to disagree with something, please at least read it first
I agree, vw has been very useful in making sites work the same on mobile and desktop. Even vh, sometimes.
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.