Most active commenters
  • bsenftner(3)

←back to thread

Aspects of modern HTML/CSS you may not be familiar with

(lyra.horse)
451 points todsacerdoti | 23 comments | 28 Aug 25 20:49 UTC | HN request time: 0.822s | source | bottom
Show context
b_e_n_t_o_n ◴[29 Aug 25 04:20 UTC] No.45060146[source]▶
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.
replies(11): >>45060383 #>>45060483 #>>45060957 #>>45061557 #>>45061852 #>>45062092 #>>45062151 #>>45062384 #>>45063859 #>>45067840 #>>45069507 #
1. tmpfs ◴[29 Aug 25 10:39 UTC] No.45062384[source]▶
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.

replies(6): >>45062607 #>>45062813 #>>45067326 #>>45067564 #>>45067844 #>>45068108 #
2. bsenftner ◴[29 Aug 25 11:14 UTC] No.45062607[source]▶
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.
replies(2): >>45062704 #>>45062710 #
3. darkwater ◴[29 Aug 25 11:31 UTC] No.45062704[source]▶
So, what is your proposal?
replies(1): >>45068896 #
4. yladiz ◴[29 Aug 25 11:33 UTC] No.45062710[source]▶
What secrets are you talking about?
replies(1): >>45063189 #
5. raxxorraxor ◴[29 Aug 25 11:50 UTC] No.45062813[source]▶
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).

replies(2): >>45067087 #>>45068191 #
6. bsenftner ◴[29 Aug 25 12:27 UTC] No.45063189{3}[source]▶
All the edge cases.
replies(1): >>45065292 #
7. yladiz ◴[29 Aug 25 15:20 UTC] No.45065292{4}[source]▶
Do you have any concrete examples?
replies(1): >>45077979 #
8. bobthepanda ◴[29 Aug 25 17:36 UTC] No.45067087[source]▶
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

9. pseudosavant ◴[29 Aug 25 17:55 UTC] No.45067326[source]▶
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.

replies(1): >>45068776 #
10. sensanaty ◴[29 Aug 25 18:15 UTC] No.45067564[source]▶
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.
replies(1): >>45068429 #
11. amlib ◴[29 Aug 25 18:41 UTC] No.45067844[source]▶
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.
12. jimbob45 ◴[29 Aug 25 19:06 UTC] No.45068108[source]▶
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!).
replies(1): >>45068879 #
13. seanclayton ◴[29 Aug 25 19:13 UTC] No.45068191[source]▶
What about CSS layers[0] doesn't solve your specificity issues?

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@layer

14. reaperducer ◴[29 Aug 25 19:36 UTC] No.45068429[source]▶
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.

replies(2): >>45068989 #>>45069002 #
15. pseudosavant ◴[29 Aug 25 20:05 UTC] No.45068776[source]▶
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.

16. mikestorrent ◴[29 Aug 25 20:13 UTC] No.45068879[source]▶
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?

17. mikestorrent ◴[29 Aug 25 20:15 UTC] No.45068896{3}[source]▶
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.

replies(2): >>45069011 #>>45069040 #
18. typpilol ◴[29 Aug 25 20:25 UTC] No.45068989{3}[source]▶
When the !important comes out it's all over
19. marcosdumay ◴[29 Aug 25 20:27 UTC] No.45069002{3}[source]▶
> 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.

20. typpilol ◴[29 Aug 25 20:28 UTC] No.45069011{4}[source]▶
That's a good solution in a perfect world. But that's magical thinking. What's a real solution?
21. peanut-walrus ◴[29 Aug 25 20:30 UTC] No.45069040{4}[source]▶
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.
replies(1): >>45069476 #
22. Klonoar ◴[29 Aug 25 21:15 UTC] No.45069476{5}[source]▶
That’s partly due to reach, though. The combination of the browser coupled with Electron eating away at those native UI layers means it unfortunately makes little sense to bother with alternatives, even if the alternatives are better.

I.e, the GP is trying to argue one thing and you’re kind of going down a different tangent.

23. bsenftner ◴[30 Aug 25 21:03 UTC] No.45077979{5}[source]▶
How's about the very existence of different layout engines, which can all be in-use at once on the same page?