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.
easyThrowaway 12 hours ago [-]
CSSdev has been the bread and butter of my last 10 years of work, and I still have the feeling that CSS as a language is never designed, just expanded.
A series of modules that are bolted on top of existing properties without actually improving on them, simply "well, here's another way of doing the same thing" often in ways contradicting each other (see the way the box model works in "display" vs "flex" layout) or just slightly diverging in ways that make extremely hard to debug them (e.g. how gap works in "flex" vs "grid" layouts[1]).
The awkward point-based cascading system means that once a layout is written it's basically frozen, unless you use some convoluted native or js-based encapsulation systems which once in a while gets leaky and, who knows, your component topbar font-weight mysteriously goes from "thin" to "extrabold" or your mobile menu appears even on your desktop breakpoints.
I disagree, I think most of these opinions I see about CSS are from people that haven't taken the time to learn it and particularly to understand the cascade.
Many years ago I did a very deep dive into the CSS specs as I was researching for a new implementation and it struck me as well designed for its purpose of separating style from the semantics of markup.
sensanaty 3 hours ago [-]
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.
reaperducer 1 hours ago [-]
As someone who works with many dozens of CSS files each day, I can say the problem isn't CSS. It's devs who are too lazy to document their work.
If everyone is working from the same spec/reference, it's fine, and you get consistent, reliable results.
When devs have to stumble around in the dark and end up reinventing the wheel every few months, that's when things go badly.
marcosdumay 35 minutes ago [-]
> devs who are too lazy to document their work
That's as bad a complaint as the one about cascading.
Your rules should be close to the object that uses them. It's really bad that CSS only supports global rules, and that is not a fault of the developers writing those rules.
typpilol 37 minutes ago [-]
When the !important comes out it's all over
raxxorraxor 9 hours ago [-]
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).
bobthepanda 3 hours ago [-]
In 2025 when starting from scratch all you really need is flexbox, css grid, and the box model and that will get you like 99% of the way on most layouts.
Specificity is really just
* ids take priority
* the highest number of specified classes, and if there’s a tie it’s the first one specified
* the highest number of types
The only problem is that most paths in frontend development say “slap a class on an element” and call it a day but you do need to be intentional about it and only specify what you need
seanclayton 2 hours ago [-]
What about CSS layers[0] doesn't solve your specificity issues?
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.
pseudosavant 57 minutes ago [-]
This problem is compounded by CSS kind of overlaying HTML in a way.
Lots of "real" devs treat HTML with similar "I don't need to really learn this toy markup" kind of attitude. The worst CSS issues I've ever had to deal with were often caused by horrible markup that was impossible to consistently style.
Basic stuff like how to make a good `<form>`. Putting `<label>` elements next to your `<input>` elements, or making sure the `for` and `ID` attributes are set. Hell, even using `<label>` instead of some `<span>` they threw a bunch of random framework classes on.
amlib 2 hours ago [-]
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.
jimbob45 2 hours ago [-]
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!).
mikestorrent 49 minutes ago [-]
The problem here is that it wouldn't matter if you made a better language for styling web pages, because you have no vector to get that language included in browsers; and even if you did it would take years for it to get enough market penetration for you to rely on it as something you can deliver an app in. So, you'd end up with some horrendous compatibility layer that compiles everything down to nasty CSS anyway.
Same problem with Javascript. Here we are compiling Typescript down into it... and running JS on the server with Node in order to avoid the classic impedance mismatch we all had back in the day writing backends in PHP etc.
Feels like the real solution would be to allow browsers to become more flexible with language implementations instead so we can make more progress. WASM might be the ticket there?
bsenftner 10 hours ago [-]
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.
yladiz 9 hours ago [-]
What secrets are you talking about?
bsenftner 9 hours ago [-]
All the edge cases.
yladiz 6 hours ago [-]
Do you have any concrete examples?
darkwater 10 hours ago [-]
So, what is your proposal?
mikestorrent 47 minutes ago [-]
Throw away the front-end of the Web and start over with a system actually designed to facilitate graphical applications instead of delivering styled documents.
HTTP can stay, and HTML/CSS can stay just like PDFs for delivering a document, but when it comes to UI components, we should be able to have things as fast and performant as e.g. RedLang / Processing / Enlightenment DR17 / etc without every developer having to shovel megabytes of shim-ware down to the client.
peanut-walrus 32 minutes ago [-]
We have a plethora of native frameworks for building UI-s. Some of them are quite well designed. And yet the Web front-end has won against all the UI frameworks designed specifically to build UI-s.
typpilol 34 minutes ago [-]
That's a good solution in a perfect world. But that's magical thinking. What's a real solution?
motorest 2 hours ago [-]
> I think it was a mistake to combine styling and layout (...)
Anyone who ever did any work on UI development knows very well that styling and layout are coupled and interdependent. I mean, think about it. Text string length, text size, text overflowing/breaking/clipping, margins, etc. You change border sizes/padding/spacing and the space left for child content changes as well. How exactly do you uncouple something that's fundamentally coupled?
nostrademons 2 hours ago [-]
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.
What doesn't really exist is the excitement about the web as a publishing platform. Those of us who still write CSS for a living probably do so in the context of a webapp, a product that's trying to help a user accomplish a task. We usually work with other developers, and writing CSS like you do on CSS Zen Garden would probably get you fired. If you are an indie publisher maintaining your own website where you can actually control the CSS - get ready for spam, and hackers, and bitcoin miners, and people using your server as a launchpad to do illegal things and get you blamed for it!
Social media won, and it's social media like Facebook or TikTok or Reddit where you have zero control over presentation, not even social media like MySpace or LiveJournal where you could do cool things with CSS.
DanielHB 8 hours ago [-]
The problem with CSS is the C: Cascading. Which is what you are calling "inheritance"
Cascading is a nice feature for documents, that present data in the same way over and over. It not good for anything interactive. A lot of modern styling techniques are all about making CSS _not_ cascade. UI components (which is the majority of modern frontend dev) is basically a pre-requisite to achieve that.
The layout system is a bit of a separate discussion, and it is a mess yes, but mostly for backwards compatibility. If we could live in a world where all layout is default flexbox or grid and never mix inline with non-inline in the same container it would work out just fine. In fact that is _exactly_ how it works in React Native and it doesn't cause problems there. Styling in React Native also doesn't cascade which also makes it a lot easier to manage.
tobr 16 hours ago [-]
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.
b_e_n_t_o_n 15 hours ago [-]
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.
ryanjshaw 11 hours ago [-]
I read up until the css color picker (which doesn’t work in Safari), clicked view source, and then scrolled… and scrolled… and scrolled… until my eyes glazed over and I tapped the back button to get here. It just looks so messy and hacky, but might just be me.
antod 16 hours ago [-]
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.
exodust 13 hours ago [-]
> "I think it was a mistake to combine styling and layout"
Perhaps because we can have different styles of layout, it fits with CSS better than you say. Carefully designed padding, margins and negative space is both a style and layout consideration.
Containers contain styles, but the container's relationship with other containers may tie with presentation such as border thickness, colour, shadows, and let's not forget animation and interaction effects on containers. Maintaining control of these aspects in one place makes good sense to me.
j45 11 hours ago [-]
Nothing's perfect, Javascript has evolved too as a core language the more it's used.
archerx 14 hours ago [-]
“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.
m-schuetz 12 hours ago [-]
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.
archerx 8 hours ago [-]
>I refuse to learn the tool properly and blame the tool instead of my laziness
Ok
m-schuetz 5 hours ago [-]
Yeah, of course I'm lazy, why would I want to do unnecessary extra work? If a tool has bad UX that demands more effort than it should, I will find a different one. I have a limited amount of time to spare. If there is no other tool, I'll do a "good-enough" job and move on to more important tasks. Luckily, alternatives usually exist. Krita instead of Gimp, Cuda&OpenGL instead of Vulkan, C++ instead of Rust, etc.
floydnoel 1 hours ago [-]
there's two types of workmanship, where one camp focuses on becoming more and more proficient with progressively more advanced tools and the other focuses on blasting through the piecework as quickly as possible. obviously the latter is much more common, but on a site such as this there still exist faint traces of the former.
8 hours ago [-]
wmil 13 hours ago [-]
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.
archerx 8 hours ago [-]
I’ve always found CSS trivial to use and I’ve done some complex styles. I really wonder what people who complain about CSS are doing.
bryanrasmussen 13 hours ago [-]
>Nested flexbox had bugs in IE11, which wasn't end of lifed until 2022.
how is I hate CSS because IE was poorly maintained a serious argument?
icedchai 8 hours ago [-]
For a long time, from the late 90's until roughly 2012, IE was the most popular browser. You had no choice but to work with it. If it didn't "work on IE", it didn't work.
archerx 8 hours ago [-]
Yea and people over exaggerated about it just like people over exaggerate things today like how hard CSS. The technology progress but people’s refusal to learn and desire to whine on the internet has stayed the same.
icedchai 7 hours ago [-]
This is true, but the dominance of IE and its quirks, especially during the early 2000's, should not be underestimated. The browser situation, especially on Linux, was absolutely abysmal then.
archerx 8 hours ago [-]
They will cling to any cope they can because it’s easier than learning the tool properly.
“It’s not MY fault, it’s a browser no has used in 10 years fault! I can do no wrong!”
b_e_n_t_o_n 14 hours ago [-]
You can apply that line of argument towards anything though, it's not particularly insightful.
archerx 8 hours ago [-]
Yes refusing to learn to program, draw, drive or whatever properly and then complaining about it is stupid and provides more insight on the person than the activity.
There’s nothing more arrogant than doing something wrong/badly and then blaming the tool for the outcome and not yourself.
b_e_n_t_o_n 2 hours ago [-]
Perhaps the only thing more arrogant is to assume someone who criticizes something simply doesn't understand it.
firefoxd 15 hours ago [-]
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.
locallost 14 hours ago [-]
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.
tankenmate 14 hours ago [-]
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.
easyThrowaway 10 hours ago [-]
The issue is you never really know which property "cascades" or not. There are special cases for block elements, flex elements, flex children elements, sometimes even the boring "a" link object. It's basically trial and error until you somehow remember the most common cases.
14 hours ago [-]
weinzierl 13 hours ago [-]
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.)
archerx 14 hours ago [-]
I have also been doing CSS for 20 years but it seems you have some skill issues?
noelwelsh 14 hours ago [-]
> 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.
bryanrasmussen 13 hours ago [-]
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.
grebc 11 hours ago [-]
You actually don’t let people use a bandsaw if they’ve demonstrated reckless behaviour.
noelwelsh 10 hours ago [-]
Yes, but that is not the same as telling competent professionals to exercise more care. Accidents are prevented by creating systems that make accidents hard, not by requiring more vigilance from individuals. This is why bandsaws come with guards and other safety features.
leptons 3 hours ago [-]
Someone who can't figure out how to use CSS effectively in about an hour is not a "professional". CSS is very simple, and very powerful. People's underdstanding of it seems to be lacking, and it almost seems like from these comments that it comes down to willful ignorance.
rebane2001 13 hours ago [-]
Would you hold another programming language, such as JS, to the same standard?
noelwelsh 13 hours ago [-]
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.
wmil 13 hours ago [-]
Are you implying that having both String.prototype.substring and String.prototype.substr is somehow confusing?
JS is in general better because by the time it came out people knew what to expect from a scripting language.
CSS didn't really have a lot of earlier styling and layout languages to copy. Also the original vision was much more limited.
timeon 11 hours ago [-]
> Also the original vision was much more limited.
Is this about CSS or JS (and things like Node)?
squigz 10 hours ago [-]
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?
timeon 11 hours ago [-]
> 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.
keeganpoppen 22 hours ago [-]
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.
inopinatus 19 hours ago [-]
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.
xenotux 17 hours ago [-]
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...
cbrozefsky 10 hours ago [-]
Old school flexing on us with the scheme. They don’t know about the sosofo!
b_e_n_t_o_n 17 hours ago [-]
The cost is increased complexity in both the CSS spec and browser implementations.
bee_rider 21 hours ago [-]
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.
hilbert42 17 hours ago [-]
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.
rebane2001 21 hours ago [-]
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
h4ny 17 hours ago [-]
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.
1vuio0pswjnm7 17 hours ago [-]
"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)
hilbert42 16 hours ago [-]
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.
keeganpoppen 18 hours ago [-]
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… :)
DANmode 18 hours ago [-]
The point of the post is helping change that perception.
Mars008 21 hours ago [-]
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.
typpilol 19 hours ago [-]
Isn't the tor browser insanely slow though?
Mars008 13 hours ago [-]
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.
1718627440 11 hours ago [-]
If duckduckgo bothers you, there is html.duckduckgo.com.
20 hours ago [-]
ajross 19 hours ago [-]
> 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.)
djtango 18 hours ago [-]
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
rebane2001 19 hours ago [-]
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
ajross 19 hours ago [-]
> 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.
Jach 18 hours ago [-]
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.
rebane2001 18 hours ago [-]
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
ajross 7 hours ago [-]
> i'm not a "parasite" for having a personal threat model
Of course not. You're a parasite because if everyone had your "personal threat model"[1] it would kill the platform you're using and you wouldn't even have the option of noscript. I think the metaphor is apt and I stand by it.
[1] FWIW, this conflation of legitimate security jargon with what amounts to wanting more settings tunables in your app is sort of a bad smell. It seems insincere, honestly.
hilbert42 15 hours ago [-]
"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.
jauntywundrkind 22 hours ago [-]
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.
lukan 20 hours ago [-]
"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.
exabrial 21 hours ago [-]
> some users dont want javascript
correct, nearly all dont
dmd 21 hours ago [-]
More than 99.9% of web users have never heard of javascript.
__MatrixMan__ 18 hours ago [-]
I'd believe 90. 99.9 seems aggressive.
ChrisRR 8 hours ago [-]
I think you massively overestimate how much the average user knows about computers
TheCoelacanth 6 hours ago [-]
The statement was 99.9%, so that's not talking about average users; it's talking about the top 1% or less of users.
If 99.9% percent of users don't know what JS is, that means even a majority of professional software developers don't know what it is.
pessimizer 21 hours ago [-]
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.
rafram 16 hours ago [-]
> javascript was probably responsible for at least half a dozen times their system has been ruined
What does this mean?
thedanbob 10 hours ago [-]
I didn't realize that nesting is official now, last time I checked it was still a proposal. Nice!
CSS has a lot of weirdness but I feel like it's been following the trajectory of Javascript toward becoming decent language. Flexbox and the :has selector, and now nesting, cover a lot of the pain points I've had over the years.
dsmmcken 19 hours ago [-]
Two of those wishlists css features already exist as specs:
Just want to drop in and say I love this site (With the name of Vega, I might be biased, but still <3 ). The entire site's style is great and this page's content is awesome and I'll definitely be linking it to anyone I know doing web-dev stuff in the future.
I also love https://lyra.horse/arrupted/ I've made some pretty cool pieces with it in the past, so it was really cool to see a domain I recognize on the front page today!
- Tabs also work (but unlike example in TFA, requires page load from server...)
- (The page is enhanced with JS; the JS version is smoother and includes fancier confetti)
atomicfiredoll 15 hours ago [-]
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.
rebane2001 13 hours ago [-]
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].
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.
8 hours ago [-]
japanuspus 14 hours ago [-]
Did you read the article? The author specifically addresses accessibility in multiple places, including taking extra steps to work around browser bugs [0].
Given how un-accesible this blog post is (the contrast is quite a crime against humanity, as someone who does web dev for a dsiability charity (well communcity interest company but similar)), I wouldn't go to this for a source on this.
rebane2001 5 hours ago [-]
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
mannyv 19 hours ago [-]
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."
lionelw 11 hours ago [-]
How many of those languages are declarative, or domain specific?
There's no use comparing CSS and assembly. It betrays a shallow understanding of CSS. Points to ponder:
- Assembly is superlatively imperative while CSS is the opposite. The difference can be jarring for some. It's commonly felt in day-to-day frontend work that switching to CSS (declarative) from almost anything else (imperative) -- JavaScript, PHP, etc. -- requires a significant mental shift, though it does get easier with experience.
- Lot of the vocabulary and concepts used in CSS come from outside the computing world, namely design and publishing. It's somehow a rarely shared factoid, but it's a hint at how too far away from Kansas we are to be making fair comparisons.
- A pervasive mistake that coders make (and unfortunately a lot of CSS teaching material out there too) is to approach CSS as a set of explicit, atomic instructions -- a fair coder-y assumption, but a bad mental model that leads to frustration. Understand that these instructions can affect one another; some switch entire layout algorithms[0] in a given scope, changing how other instructions behave (predictably).
> 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.
icedchai 19 hours ago [-]
I feel the same way. I find it the worst part of the HTML / CSS / JS trio.
jy14898 12 hours ago [-]
What do you mean by "CSS is basically pre-tokenized input"? Can you give an example of what you have trouble with?
leptons 3 hours ago [-]
How is "font-size: 12px" not human readable? I haven't found anything about CSS difficult to read or understand at all. It's really quite simple.
wildpeaks 2 hours ago [-]
Some people don't realize how far we've come in 20 years, CSS is so good now I even got rid of the last bit of preprocessing I was still using (CSS Modules, for generating globally-unique classnames at build time) now that I switched to Web Components for both frontend and backend (thanks to JSDOM) given they use already globally-unique tag names.
mosselman 11 hours ago [-]
Great to see another CSS > JavaScript enthousiast.
To do these things I use Tailwind which makes it easier for me to change and see what is happening. You can do so many things with just CSS. Dropdowns, animated sidebar menus, toggled areas, file-upload areas with resets to previous version or removing an upload, modals with and without backdrops, etc, etc.
I hardly use any JavaScript anymore and it is great.
maelito 12 hours ago [-]
Thanks a lot for this article. As a 10-year experience Web dev, we need this to shake our beliefs. The title is bad, though. Almost didn't read it.
CSS will not render maps ;)
timeon 12 hours ago [-]
> CSS will not render maps ;)
It could with CSS+SVG. You still need to control navigation somehow.
z3t4 2 hours ago [-]
I could do this 15 years ago. we're just adding more syntax and featurea so that we can do stuff in new ways and call it the modern way. Whats ironic is that the more featurea that are added the more frameworks are invented to manage it. There are even transpilers!
sbinnee 16 hours ago [-]
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.
1718627440 11 hours ago [-]
If your intention is to let the user choose between styles the best way would be Alternate Stylesheets: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... . Sadly Google can't be bothered to implement "legacy" standards (=standards not invented at Google).
If your intention is to adopt your styles slightly to user preferences then there are media queries.
Telaneo 3 hours ago [-]
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.
masklinn 15 hours ago [-]
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).
wjrb 3 hours ago [-]
DevTools in Firefox and Chrome both have a `prefers-color-scheme` override built in, no extension required.
exodust 12 hours ago [-]
> 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.
Sateeshm 16 hours ago [-]
Isn't it just `prefers-color-scheme`
wjrb 3 hours ago [-]
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.
rebane2001 16 hours ago [-]
that's the "auto" option, but the comment is taking about adding buttons to switch between the themes too
awongh 21 hours ago [-]
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.
You never needed JavaScript and this css is arcane and messy Mantra is entertaining. CSS has always been awesome.
draw_down 11 hours ago [-]
[dead]
edg5000 17 hours ago [-]
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?
1718627440 11 hours ago [-]
Native toolkits now also have CSS (the syntax, not the properties). They also long had an often XML based UI specification language.
rossant 3 hours ago [-]
Unpopular opinion, but I find it wild how much people dislike CSS around here. I learned it over 25 years ago and loved it. I still use it regularly and appreciate the constant evolution of the language. Like every language, it has its quirks, but it gets the job done.
graypegg 16 minutes ago [-]
Same! I can find the syntax to be a bit too vague sometimes (I'll never memorize the weird order of values for the shortcut animation property) but I could say that about a lot of technology I really enjoy. For me, I feel comfortable enough with working around it's quirks to be effective making web UI. That's good enough for me!
Saying that, if it just doesn't grok in someone else's head, I can't fault them for that, but my opinion isn't really going to shift... regardless of the superlative-riddled doom-saying.
ChrisRR 9 hours ago [-]
Arguably most sites don't need javascript or CSS trickery anyway just to show text and images
Dansvidania 17 hours ago [-]
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?
Kerrick 8 hours ago [-]
If you’re not turned off by its heft, CSS:The Definitive Guide, 5th Edition by Meyer & Weyl.
16 hours ago [-]
lemonwaterlime 22 hours ago [-]
Modern CSS is indeed great. I'm using modern CSS, htmx, and Haskell to develop apps and am loving it.
graypegg 12 minutes ago [-]
I haven't touched Haskell in quite a while! If you ever feel like sharing any info about your experience working with it for web service dev, I'd be really interested to read it!
frizlab 21 hours ago [-]
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.
interstice 20 hours ago [-]
> 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.
rebane2001 20 hours ago [-]
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
mixmastamyk 17 hours ago [-]
Hmmm, I thought you had to register these with JS first, but my browser seems to recognize them.
voat 19 hours ago [-]
And even if they don't contain a hyphen! You can just <use> <anything> <you> <want>
masklinn 16 hours ago [-]
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?
timeon 11 hours ago [-]
We could have that with XHTML+DTDs...
Quarrelsome 21 hours ago [-]
omg that's so much prettier than it used to be. What they've done with it is extremely impressive.
user3939382 22 hours ago [-]
Who would have thought UI layout and rich formatting would be the hard problem that destroyed personal computing.
apt-apt-apt-apt 17 hours ago [-]
That is the most beautiful meow button I've ever seen!
Animats 21 hours ago [-]
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.
wpollock 22 hours ago [-]
How can one learn modern CSS and is there an online reference that is up to date?
Do hardened browsers also disable Wasm? I suppose so since you need a touch of JS to kick it off… darn.
geokon 12 hours ago [-]
Not a webdev, so I'm curious: Have we reached the point where you can you make credit card payments without JS?
(if not, what are the blockers?)
chrismorgan 9 hours ago [-]
Credit card payments on the web are older than JavaScript, and I don’t think that anything even today actually requires JavaScript—all the fancy security things I know of could be done easily enough with additional form submissions and/or meta redirects (alas for multipart/x-mixed-replace, it was never reliable and its removal is almost complete). Unfortunately, PCI DSS makes it expensive now to direct things via your own server, so a typical business will be at the mercy of what their payment gateway provides: and I don’t know if any popular ones will support JavaScript-free operation any more, even though it’s theoretically pretty easy.
geokon 8 hours ago [-]
"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
chrismorgan 5 hours ago [-]
The Payment Card Industry has a set of Data Security Standards: if you want to accept cards, you must comply with their rules, or they may ban you. There are different degrees of compliance requirements. If someone else handles everything (e.g. external link or iframe), you get the easiest time: Self-Assessment Questionnaire A. If the data is actually in your DOM but you’re submitting to someone else (by form post or by JS), your burden is a little more, but still fairly small: SAQ A-EP. But if the card number is ever going to touch your server, you can’t use these things, and must go up to SAQ D which is several hundred questions long, and some of the requirements of which may be bothersome, involving things like quarterly penetration testing from approved vendors; and if you have a larger number of transactions, you end up needing mandatory full on-site audits.
(In practice, at the lower levels compliance is not typically validated, and I wouldn’t be surprised if less than 1% of e-commerce merchants were actually fully compliant even at SAQ A.)
newscombinatorY 12 hours ago [-]
I think for such a trivial task as submitting a form with some data (such as CC info), JS was never required to begin with.
ludicrousdispla 12 hours ago [-]
I believe you can do that without JS by using an HTML form containing the requisite user input fields.
adithyassekhar 19 hours ago [-]
Colour picker isn't working for me on android Chrome stable 139.0.7258.158.
rebane2001 19 hours ago [-]
the picker's touch area is really small on mobile, you can use it but you have to be accurate
adithyassekhar 19 hours ago [-]
It worked when I zoomed in, thanks. That's impressive.
futurecat 14 hours ago [-]
Fantastic post! Learned a ton.
throwaway81523 20 hours ago [-]
The great wheel of karma. All the stuff that made javascript despicable now makes css despicable as well.
ZYbCRq22HbJ2y7 20 hours ago [-]
Can you elaborate on what all that stuff is?
SoftTalker 19 hours ago [-]
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.
ZYbCRq22HbJ2y7 18 hours ago [-]
> 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?
SoftTalker 18 hours ago [-]
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.
tobyhinloopen 9 hours ago [-]
I love how some of the examples simply don't work or are partially broken.
wewewedxfgdf 20 hours ago [-]
JavaScript is for more than augmenting CSS.
nsonha 18 hours ago [-]
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.
lionelw 17 hours ago [-]
Ask your boss to hire someone better at CSS than you.
nsonha 15 hours ago [-]
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)
lionelw 13 hours ago [-]
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?
nsonha 12 hours ago [-]
design should be visual, you should not have to write code for it.
Even if you write code for it, you should be able to write code in a way that express your high level thinking, something similar to constrain layout in mobile dev. CSS has 4 levels of overlapping features so far and every new layout model comes out are slightly better but still a little bit off. The newer features like variables have bolted-on syntax that looks like garbage, nobody understand CSS grammar anyway (does it even have one?)
Given how convoluted CSS is despite how little it has to do, I consider it a poorly designed programming language, if you can call it that.
lionelw 8 hours ago [-]
So how do you deliver design on the web, if not without code?
Remember that designing for the web is not like designing for print, where the dimensions of your canvas, and the amount and nature of your content, are known quantities. A web page is expected to accommodate every possible device, agent and viewport -- watches, phones, tablets, laptops, desktops, TVs, screen readers, ebook readers, etc. * portrait and landscape orientations * browser window sizes -- and content that can change by the minute and whose size is unknown until all of it has arrived on the device.
Think about all these conditionals and variables, and how much instruction you need to provide, efficiently, for making it all look as good as possible, to the browser/agent. Doesn't all this seem like the necessary purview of a domain-specific programming language?
nsonha 4 hours ago [-]
I never said I don't like domain specific languages. Actually I said CSS sucks at being one.
> 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++.
SquareWheel 20 hours ago [-]
Maybe this only proves your point, but there is no float: clear. They're separate properties.
float: none;
clear: both;
paulddraper 5 hours ago [-]
You're right.
And the fact that yours was the only comment to point this out...
rebane2001 23 hours ago [-]
The sentence you quoted refers to the 'centering a div' example, not CSS as a whole.
nicoburns 21 hours ago [-]
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.
paulddraper 4 hours ago [-]
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.")
nicoburns 4 hours ago [-]
with, == (except certain idiomatic uses), __prototype__, eval, etc.
socalgal2 20 hours ago [-]
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+
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"
paulddraper 4 hours ago [-]
> pretty straight forward
Anything but. It combines whitespace collapsing and text wrapping in one property and makes a mess of both.
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.
whytaka 22 hours ago [-]
I haven't used float in at least half a decade. CSS is easy.
JohnFen 22 hours ago [-]
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!
moritz 29 minutes ago [-]
> 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.
Those languages happen to be "imperative"? – the few backend devs I know who at least sort of vibe with CSS are all used to declarative programming. I think that might be at least one of the reasons?
extraisland 20 hours ago [-]
> 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.
JohnFen 8 hours ago [-]
> It is probably because you haven't learned the basics.
That's not the case with me, honestly. It's just a poor mesh with my brain is all.
> So I am not sure what you are trying to say here.
I'm trying to say that I dislike the use of JS, at least for common websites, and I'm in favor of anything that could reduce its use.
extraisland 7 hours ago [-]
I don't understand how that is the case when you say you can figure out much more complicated programming languages. It strains credulity.
I am a former front-end developer that managed to figure out AWS, Go, C++, C#, JavaScript, Python, OpenGL and have done a LFS build. I am not some sort of mega genius. I just had to go through and read the correct material and learn the basics.
typpilol 19 hours ago [-]
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
b_e_n_t_o_n 13 hours ago [-]
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.
extraisland 13 hours ago [-]
I know what the issues are on a large CSS codebase. I specifically mentioned them.
You are over exaggerating the problems IMO. Yes it is a pain when you are left with a mess, but there are ways of dealing with that.
marssaxman 4 hours ago [-]
It probably seems easy to you because you are already familiar with the pitfalls. For me, CSS felt like an endless minefield of unexpected interactions. When you say that "CSS is easy", do you perhaps mean only the syntax and the basic language structure? I would agree, but that doesn't get you very far; actually trying to use CSS frustrated me so much that I simply don't touch anything related to the web at all anymore.
extraisland 3 hours ago [-]
I learned the basics in maybe a day almost 20 years ago now. I could make a page template with PHP and style that in maybe a day. This was back when IE6 was dominate, I don't think Firebug was even a thing.
At that time I was a novice, didn't know what a debugger was (I printed everything out the the console / page) and didn't know what an IDE was (I think I was using Notepad++). I managed this feat by following the tutorial.
The biggest problem I had was that I couldn't understand why centre, and colour didn't work. Once I realised that I had to spell everything in American English, that problem quickly went away.
paulddraper 4 hours ago [-]
The syntax of CSS is great.
Any problems have nothing to do with that.
Semaphor 19 hours ago [-]
I have used it recently, it’s now back to doing what it was supposed to, originally: Float objects into text.
paulddraper 21 hours ago [-]
> Unless you use the subset of CSS that you have decided to learn + use. Not unlike C++.
righthand 15 hours ago [-]
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?
dwd 20 hours ago [-]
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.
rebane2001 20 hours ago [-]
not my pronoun, and not what the section talks about
if you're going to disagree with something, please at least read it first
alt187 19 hours ago [-]
I agree, vw has been very useful in making sites work the same on mobile and desktop. Even vh, sometimes.
dwd 17 hours ago [-]
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.
socalgal2 20 hours ago [-]
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
ZYbCRq22HbJ2y7 20 hours ago [-]
That is just showing nesting with some older features
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
msie 17 hours ago [-]
text-shadow works. Was the use of box shadow a mistake?
rebane2001 17 hours ago [-]
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
A series of modules that are bolted on top of existing properties without actually improving on them, simply "well, here's another way of doing the same thing" often in ways contradicting each other (see the way the box model works in "display" vs "flex" layout) or just slightly diverging in ways that make extremely hard to debug them (e.g. how gap works in "flex" vs "grid" layouts[1]).
The awkward point-based cascading system means that once a layout is written it's basically frozen, unless you use some convoluted native or js-based encapsulation systems which once in a while gets leaky and, who knows, your component topbar font-weight mysteriously goes from "thin" to "extrabold" or your mobile menu appears even on your desktop breakpoints.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/gap
Many years ago I did a very deep dive into the CSS specs as I was researching for a new implementation and it struck me as well designed for its purpose of separating style from the semantics of markup.
If everyone is working from the same spec/reference, it's fine, and you get consistent, reliable results.
When devs have to stumble around in the dark and end up reinventing the wheel every few months, that's when things go badly.
That's as bad a complaint as the one about cascading.
Your rules should be close to the object that uses them. It's really bad that CSS only supports global rules, and that is not a fault of the developers writing those rules.
Nobody came up with a better alternative though (apart from the many dialects that transpile to CSS again).
Specificity is really just
* ids take priority * the highest number of specified classes, and if there’s a tie it’s the first one specified * the highest number of types
The only problem is that most paths in frontend development say “slap a class on an element” and call it a day but you do need to be intentional about it and only specify what you need
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@layer
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.
Lots of "real" devs treat HTML with similar "I don't need to really learn this toy markup" kind of attitude. The worst CSS issues I've ever had to deal with were often caused by horrible markup that was impossible to consistently style.
Basic stuff like how to make a good `<form>`. Putting `<label>` elements next to your `<input>` elements, or making sure the `for` and `ID` attributes are set. Hell, even using `<label>` instead of some `<span>` they threw a bunch of random framework classes on.
Same problem with Javascript. Here we are compiling Typescript down into it... and running JS on the server with Node in order to avoid the classic impedance mismatch we all had back in the day writing backends in PHP etc.
Feels like the real solution would be to allow browsers to become more flexible with language implementations instead so we can make more progress. WASM might be the ticket there?
HTTP can stay, and HTML/CSS can stay just like PDFs for delivering a document, but when it comes to UI components, we should be able to have things as fast and performant as e.g. RedLang / Processing / Enlightenment DR17 / etc without every developer having to shovel megabytes of shim-ware down to the client.
Anyone who ever did any work on UI development knows very well that styling and layout are coupled and interdependent. I mean, think about it. Text string length, text size, text overflowing/breaking/clipping, margins, etc. You change border sizes/padding/spacing and the space left for child content changes as well. How exactly do you uncouple something that's fundamentally coupled?
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.
https://csszengarden.com/
What doesn't really exist is the excitement about the web as a publishing platform. Those of us who still write CSS for a living probably do so in the context of a webapp, a product that's trying to help a user accomplish a task. We usually work with other developers, and writing CSS like you do on CSS Zen Garden would probably get you fired. If you are an indie publisher maintaining your own website where you can actually control the CSS - get ready for spam, and hackers, and bitcoin miners, and people using your server as a launchpad to do illegal things and get you blamed for it!
Social media won, and it's social media like Facebook or TikTok or Reddit where you have zero control over presentation, not even social media like MySpace or LiveJournal where you could do cool things with CSS.
Cascading is a nice feature for documents, that present data in the same way over and over. It not good for anything interactive. A lot of modern styling techniques are all about making CSS _not_ cascade. UI components (which is the majority of modern frontend dev) is basically a pre-requisite to achieve that.
The layout system is a bit of a separate discussion, and it is a mess yes, but mostly for backwards compatibility. If we could live in a world where all layout is default flexbox or grid and never mix inline with non-inline in the same container it would work out just fine. In fact that is _exactly_ how it works in React Native and it doesn't cause problems there. Styling in React Native also doesn't cascade which also makes it a lot easier to manage.
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.
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.
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.
Perhaps because we can have different styles of layout, it fits with CSS better than you say. Carefully designed padding, margins and negative space is both a style and layout consideration.
Containers contain styles, but the container's relationship with other containers may tie with presentation such as border thickness, colour, shadows, and let's not forget animation and interaction effects on containers. Maintaining control of these aspects in one place makes good sense to me.
from the article is talking about people like you, who refuse to learn something properly but have the arrogance to think they know better.
Ok
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.
how is I hate CSS because IE was poorly maintained a serious argument?
“It’s not MY fault, it’s a browser no has used in 10 years fault! I can do no wrong!”
There’s nothing more arrogant than doing something wrong/badly and then blaming the tool for the outcome and not yourself.
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.
And since documents "fit" trees way more often than not; I'd say CSS is a good fit.
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.)
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.
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.
JS is in general better because by the time it came out people knew what to expect from a scripting language.
CSS didn't really have a lot of earlier styling and layout languages to copy. Also the original vision was much more limited.
Is this about CSS or JS (and things like Node)?
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?
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.
Deep down inside, however, I miss DSSSL.
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.
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.
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 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.
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)
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.
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.)
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
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.
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.
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
Of course not. You're a parasite because if everyone had your "personal threat model"[1] it would kill the platform you're using and you wouldn't even have the option of noscript. I think the metaphor is apt and I stand by it.
[1] FWIW, this conflation of legitimate security jargon with what amounts to wanting more settings tunables in your app is sort of a bad smell. It seems insincere, honestly.
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.
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.
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.
correct, nearly all dont
If 99.9% percent of users don't know what JS is, that means even a majority of professional software developers don't know what it is.
edit: IE javascript was probably responsible for at least half a dozen times their system has been ruined, and they know what tracking is.
What does this mean?
CSS has a lot of weirdness but I feel like it's been following the trajectory of Javascript toward becoming decent language. Flexbox and the :has selector, and now nesting, cover a lot of the pain points I've had over the years.
> 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.
I also love https://lyra.horse/arrupted/ I've made some pretty cool pieces with it in the past, so it was really cool to see a domain I recognize on the front page today!
- Falling confetti animation
- Alert with functional close icon
- Dismissing alert also dismisses confetti
- Tabs also work (but unlike example in TFA, requires page load from server...)
- (The page is enhanced with JS; the JS version is smoother and includes fancier confetti)
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].
[0] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-...
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.
[0]: https://lyra.horse/blog/2025/08/you-dont-need-js/#fn:10
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
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."
There's no use comparing CSS and assembly. It betrays a shallow understanding of CSS. Points to ponder:
- Assembly is superlatively imperative while CSS is the opposite. The difference can be jarring for some. It's commonly felt in day-to-day frontend work that switching to CSS (declarative) from almost anything else (imperative) -- JavaScript, PHP, etc. -- requires a significant mental shift, though it does get easier with experience.
- Lot of the vocabulary and concepts used in CSS come from outside the computing world, namely design and publishing. It's somehow a rarely shared factoid, but it's a hint at how too far away from Kansas we are to be making fair comparisons.
- A pervasive mistake that coders make (and unfortunately a lot of CSS teaching material out there too) is to approach CSS as a set of explicit, atomic instructions -- a fair coder-y assumption, but a bad mental model that leads to frustration. Understand that these instructions can affect one another; some switch entire layout algorithms[0] in a given scope, changing how other instructions behave (predictably).
[0] https://www.joshwcomeau.com/css/understanding-layout-algorit...
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.
To do these things I use Tailwind which makes it easier for me to change and see what is happening. You can do so many things with just CSS. Dropdowns, animated sidebar menus, toggled areas, file-upload areas with resets to previous version or removing an upload, modals with and without backdrops, etc, etc.
I hardly use any JavaScript anymore and it is great.
CSS will not render maps ;)
It could with CSS+SVG. You still need to control navigation somehow.
If your intention is to adopt your styles slightly to user preferences then there are media queries.
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.
For testing there are extensions which allow overriding the browser’s scheme (for Firefox anyway).
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.
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.
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?
Saying that, if it just doesn't grok in someone else's head, I can't fault them for that, but my opinion isn't really going to shift... regardless of the superlative-riddled doom-saying.
RIP any semblance of using meaningful tags for machine readability I guess.
if an element that semantically fits your needs already exists you don't need to make up an element in the first place
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.
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/
(if not, what are the blockers?)
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
(In practice, at the lower levels compliance is not typically validated, and I wouldn’t be surprised if less than 1% of e-commerce merchants were actually fully compliant even at SAQ A.)
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.
Wouldn't that be a design or HCI issue, not something innate to a language? What is a behavioral standard?
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.
Even if you write code for it, you should be able to write code in a way that express your high level thinking, something similar to constrain layout in mobile dev. CSS has 4 levels of overlapping features so far and every new layout model comes out are slightly better but still a little bit off. The newer features like variables have bolted-on syntax that looks like garbage, nobody understand CSS grammar anyway (does it even have one?)
Given how convoluted CSS is despite how little it has to do, I consider it a poorly designed programming language, if you can call it that.
Remember that designing for the web is not like designing for print, where the dimensions of your canvas, and the amount and nature of your content, are known quantities. A web page is expected to accommodate every possible device, agent and viewport -- watches, phones, tablets, laptops, desktops, TVs, screen readers, ebook readers, etc. * portrait and landscape orientations * browser window sizes -- and content that can change by the minute and whose size is unknown until all of it has arrived on the device.
Think about all these conditionals and variables, and how much instruction you need to provide, efficiently, for making it all look as good as possible, to the browser/agent. Doesn't all this seem like the necessary purview of a domain-specific programming language?
https://justfuckingusereact.com/
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++.
And the fact that yours was the only comment to point this out...
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.")
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"
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.
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!
Those languages happen to be "imperative"? – the few backend devs I know who at least sort of vibe with CSS are all used to declarative programming. I think that might be at least one of the reasons?
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.
That's not the case with me, honestly. It's just a poor mesh with my brain is all.
> So I am not sure what you are trying to say here.
I'm trying to say that I dislike the use of JS, at least for common websites, and I'm in favor of anything that could reduce its use.
I am a former front-end developer that managed to figure out AWS, Go, C++, C#, JavaScript, Python, OpenGL and have done a LFS build. I am not some sort of mega genius. I just had to go through and read the correct material and learn the basics.
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
The syntax has never been the issue imo.
You are over exaggerating the problems IMO. Yes it is a pain when you are left with a mess, but there are ways of dealing with that.
At that time I was a novice, didn't know what a debugger was (I printed everything out the the console / page) and didn't know what an IDE was (I think I was using Notepad++). I managed this feat by following the tutorial.
The biggest problem I had was that I couldn't understand why centre, and colour didn't work. Once I realised that I had to spell everything in American English, that problem quickly went away.
Any problems have nothing to do with that.
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.
if you're going to disagree with something, please at least read it first
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.
-- update --
my bad - I think it was just subtle and I thought it wasn't doing anything. Thanks for all the replies
- 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
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 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