Hacker News Reader

Comment by spyckie2 | Hacker News Reader

This needs a part 2 on the history of the philosophy of CSS code. It should go through 4 eras:

Table and Frames - how layouting dominated the CSS school of thought

Grids and Frameworks - the mighty grid frameworks that gave you lots of stuff for free at the cost of the language itself (and your freedom)

CSS Themes - how SASS, naming conventions, and framework customization created the era of CSS theming

CSS Components - how we realized everything we did in the past was wrong, fixed up the language itself, and made styles servants to modular components, the way it should have been all along (spoiler alert: Javascript helped).

View on HN

> CSS Components - how we realized everything we did in the past was wrong

Not really. This was born out of necessity - deeply nesting components within other components doesn’t work so well when styling with broadly defined CSS selectors. So, we generate class names (or inline styles) directly in our application.

It comes with its own trade offs. I don’t know that adding a build step and tightly coupling your styling with your DOM counts as “fixing” css, but I suppose it all depends on your perspective.

It’s more like we kind of threw away one of the main principles of CSS and forced a completely new philosophy upon it.

This is the fundamental issue with most of the web technologies, though: we’ve taken a platform intended to essentially display documents with a tiny bit of interactivity and turned it into an operating system.

> It comes with its own trade offs. I don’t know that adding a build step and tightly coupling your styling with your DOM counts as “fixing” css, but I suppose it all depends on your perspective.

It is a fix. While creatively combining CSS rules to accomplish layouting is a tenant of past CSS history, it was terrible for coding in the language itself. Using tables for layouting or vertical centering hacks is the same kind of pain as using single letter characters for all your variables.

In the same way, using flexible selectors to select any grouping globally was historically a positive feature of CSS, but we've done it enough to know that it creates extremely painful bugs related to improper scope and needless amounts of copy paste code fixes. The real fix is properly scoping css, which is what BEM is about, but what modular components does better.

Sometimes I feel flexbox was created in order to get back some cool features of table-based layouts without using tables. Technology tends to run in circles.

There is some overlap, but display: table and friends already covered that without flexbox.

<table> was built for displaying tables.

But table layouts just happened to be very similar to grid layouts, which was what web developers wanted in the first place but CSS as a language didn't explicitly support.

Flexbox was built for dynamic grid layouts, and is a huge step above display:table, creating rules that are explicitly meant to do what you could somewhat hack with table rules.

CSS has this strange acceptance of hacks being a part of the language when it shouldn't be. The fact that you vertically center things with pos: absolute, top: -50%, and it is considered normal is abnormal for a language. Good language design is not to find hacks that allow you to accomplish your goal (robust layouting) - its to fix the language to give you a proper toolkit to accomplish your goal.

Reply on news.ycombinator.com