yaml VS 960-Grid-System

Back in the day, web designers were hand-writing CSS, which, trust me, was a journey full of twists (for more on this, see CSS The Good Parts). Then the 2000s hit, bringing with them CSS frameworks like Blueprint, 960 Grid System, YUI Grids, and YAML (probably not the YAML you’re thinking of). These frameworks introduced responsive grids and clean UI elements, changing the game.

yamlcss/yaml - YAML (Yet Another Multicolumn Layout) is a modular CSS framework for truly flexible, accessible and responsive websites. It is based on Sass and has a very slim framework core that weights only ~6kB.

Back in the day, web designers were hand-writing CSS, which, trust me, was a journey full of twists (for more on this, see CSS The Good Parts). Then the 2000s hit, bringing with them CSS frameworks like Blueprint, 960 Grid System, YUI Grids, and YAML (probably not the YAML you’re thinking of). These frameworks introduced responsive grids and clean UI elements, changing the game.

However I just got a new job in the past year and wow I realized my knowledge is way behind. Like, as far behind as somebody in the IE9 days would've been who was stuck doing table-based design. Like, as far behind as somebody in 2013 would've been if they were still stuck using 960.gs for their layouts.

> Statistically, we do. Sass won the precprocessor wars and nearly every developer prefer SCSS variables over the var(--oh-god) that is CSS syntax.

This isn't about which preprocessor is the most popular; it's about the syntax that's going to be used for CSS that we're going to have to live with for a long time.

Look, best practices come and go. Table-based layouts, 960 grid [4], Dreamweaver, special hacks for IE6—we don't do those things any more. With all of the enhancements that have already been added to CSS (CSS Grid, Flexbox, Container Queries, :has() parent selector) and the ones coming—CSS nesting, style queries, conditional, new/better color spaces—using Sass will seem as old-school as including jQuery in every project.

To quote Denzel Washington's character in the movie Training Day: "We don't roll that way any more." [5]

If you want to go on using Sass, then nothing changes for you; you can even use custom properties in your Sass files. It's not an all or nothing situation.

> How are they more powerful? Does that offset their downside?

Seriously?

There's no functional downside compared to the alternative. The syntax isn't bad once you understand what's going on, but that's subjective anyway. Even if you don't love the syntax, the functionality they enable for developers more than makes up for that.

Sass variables are just static placeholders for values; they're just a step above doing a search and replace in an editor. Very handy when Sass was developed 16 years ago, but very limiting today.

The real question can the dynamic web experiences people come to expect be done only using Sass variables? Are taking full advantage of everything the web platform has to offer by only using Sass variables? The answer is no in both cases.

- they're not part of the DOM and they can't be accessed via JavaScript

- they can't be changed at runtime, such as responding to media queries or other state changes

- can't be used for passing values to and from web components

There are dozens of articles about why custom properties are superior to preprocessor variables:

[1]: https://css-tricks.com/difference-between-types-of-css-varia...

[2]: "Practical Use Cases For CSS Variables"—https://ishadeed.com/article/practical-css-variables/

[3]: "DRY Switching with CSS Variables: The Difference of One Declaration"—https://www.codeinwp.com/blog/css-variables/

[4]: https://960.gs

[5]: https://movie-sounds.org/ghetto-movie-sound-clips/quotes-wit...

960.gs

nathansmith/960-Grid-System - The 960 Grid System is an effort to streamline web development workflow.