I find https://rscss.io/ to be a really nice design philosophy that takes the best parts from BEM.
And agreed: it's easiest to just work directly with flexbox (and grid if you can drop IE11), and a set of design principles is really valuable to avoid spaghetti.
I don't mind hand-writing CSS for a small project, but I feel like once you've got a decent team, it ends up being duplicative and wasting a lot of time. How many times do you really need to style button/link and write out your 8px margins (or is it 6?) Sass solves this too, but simply applying classes is even easier and faster for me at least. I thought BEM was horrible when I first saw it, but once I used it, the productivity just feels like magic.
Vanilla CSS has custom properties[1] (which are more powerful then SASS variables) and there is a proposal for the `&` nested selector[2] which you can get with PostCSS[3]. All you are missing are mixins, but there is a PostCSS plugin for that[4].
Who's to say you can't use Sass variables _and_ CSS variables?
My current shop is moving to switch our sass color function `color.get()` to either dump hardcoded hex or a css variable usage based on a param. It currently just does hex.
Well, it was a response to the parents claim that “[w]riting actual CSS is the waste of time”.
You might be happy to learn that CSS color module 4[1] will add `lab()` and `lch()` color definitions and CSS color module 5[2] will add the `color-adjust` function as well as other goodies.
Once I discovered utility classes, I found it so much better than BEM or any derivatives of such. I don't want my styles to know what my components are, I want my components to use predefined styles.
I feel like utility classes and BEM go well together, though. BEM for sort of atoms/molecules (to use the lingo from the linked css-tricks page), and then utility classes to tweak the components, and to make components play nicely together (Fixing up margins, etc so things flow right and are the right size.)
Sorry if I sound snarky, but why use this if you can just write:
<div style="margin-inline:auto">Center</div>
It looks like these are just single rule classes. In my opinion, If you are going to write one class for each style rule, you might as well use the style property.
On top of the strangeness of collapsing distinction between loading up markup with single-use classes and single-use style rules.... in the era of CSS mixins, it seems like it'd be easier than ever to come up with one or two class names that encapsulate the key document semantics (either semantics for presentational abstractions, or data semantics), and then if you really need a quiver full of fine-grained presentation-detail bundles, mix them in.
But instead it's really common to do what you've pointed out: something that's effectively inline styles in spirit.
The benefits of the semantic approach in terms of flexibility and abstraction seems really high. The only downside I can see is a bit of one common complaint about OOP, "everything happens somewhere else," requiring a context switch to figure out how markup is being told to present. But that seems like a problem better dealt with via tooling.
Inline styles can't include media queries so if you want your styling to be responsive (which you probably want) you are going to need to write some CSS in a file and not have it inline.
On top of what others are saying, on modern websites, inline CSS is usually forbidden by the Content-Security-Policy, to provide defense in depth against CSS injection.
I'm sorry if I misunderstand, but what you linked is related to allowing user created css to be displayed on a service? I don't think it's exactly relevant here. If you're just adding custom css on the page that'd displayed for you, there's no attack vector, but those links in the SO is about injected CSS where the attacker loads custom CSS for other visitors.
It's almost trivial to set up a keylogger with css that fires requests on keyboard input. Luckily there's CSP.
Inline CSS is in no way dangerous though. Its quite commonly used to defer loading the additional css files to stop render blocking the page. By inlining the above-the-fold CSS aka Critical CSS, you can shave considerable amounts of time in time to interactive clears.
Your critique applies to all of these modern "atomic CSS" frameworks, including Tailwind, Tachyons, and BassCSS. As another user pointed out, inline style attributes lack several of the features allowed by regular stylesheets.
How often are you planning on doing that? A little here, a little there, and suddenly your code is littered with inline styles, scoped JS styles, probably a style sheet for fun as well.
As often as you’d write `<div class="auto-center">` using atomic frameworks.
If you have one rule classes, you’ve really just shifted the problem away from the style attribute to the class attribute. The only benefit of atomic frameworks is fewer keystrokes for the developer. But those would be reduced even further if they would style semantically using proper CSS.
Classes can take advantage of cascading. So, I might decide the parent element class of ‘less-padding’ could affect all child ‘auto-center’ elements ‘.less-padding .auto-center { padding: 0 }’
If they can call any dumb statistics accumulator an "AI", then this certainly qualifies as "minimalist". Don't believe everything you read on the internet.
Use purgecss - https://purgecss.com/, its the same strategy employed by tailwindcss. It will filter out all the classes you don't actually use. Tailwind is over 2MB before its purged, and only a few KB afterward.
Yes. I assume he generated the stylesheet programmatically. I guess the intelligent way to use this would be to write some code that detects which classes are actually being used and only include those in a smaller stylesheet.
This all feels weird to me. Sort of like anti-compiling! But I guess it works.
I do like to avoid JS toolchains if I can though. Even though I am a webpack aficionado. But if you are going to have a css class for every possible style you might want to use, there is probably no other way.
I was thinking that this should go in reverse: since the class names follow a pattern, you should just be able to make up classes to do what you want, and code should generate the CSS file based on his pattern. That would be offline, and could be in any language
I did tons of web pre-CSS days (all my layouts were tables :-D) and have (clearly) been out of the scene for a long time other than the occasional CSS hacking when there wasn't enough backend/infrastructure work to fill the sprint.
I understand the theory behind CSS, but suck at the practice (for now). I've figured out how to do simple layout with divs, but I still suck at making it responsive to screen size changes.
Is something like Blunt for me? Or should I invest in something heavier like Bootstrap? I don't want my page to look like "just another bootstrap page" but I also won't be able to make it look good unless I have training wheels on.
I revere the "Arch way" but recognize it won't always yield the best fruit if the farmer doesn't know what they are doing. I tend to value elegance/simplicity over speed.
Unlearning is harder than learning; highest possible recommendation to start here: https://every-layout.dev
and get it right. You'll leapfrog 98% of FE "specialists" and 99.999% of "full-stack" devs.
That does look nice, though the price is pretty off putting. Maybe there'll be more content, maybe there won't be... I wish I was in a position to be able to support projects I wish to see come to fruition at that level, but personally I am not, especially for how little css I write.
I do hope it has or gets enough support to keep adding content though, as the level of quality is definitely a step above most free tutorials.
If I did have a complaint, it would be that i am unconvinced that using custom elements for layout is a great idea. It might work really well for apps, but isn't what I would think of as terribly semantic.
I can vouch for the paid content (and I paid the pre-pandemic price).
As for the implementation, it's possible to apply the axiomatic styles to standard HTML (directly, or via React, Vue etc). The examples happen to use web components (custom elements) bc of author preference, I think. I prefer React bc it has a better SSR story and doesn't require JS to be enabled.
As for semantic markup per se (a tangent, given my explanation above), your a11y efforts are waay better spent elsewhere.
I'm not affiliated in any way.
I found the free content on every-layout.dev to be extraordinarily helpful and useful. I was glad to pay for the "book" with the non-free portions of their work. YMMV.
I have some misgivings about css grid (vs doing everything w flexbox), in part bc it encourages designing to a (particular) grid configuration, whereas my responsive ideal is to build up from content first, w the design following somewhat organically from it, and the layout remaining as fluid as possible, according to the viewing context in which it's rendered.
This relates to similar thoughts about breakpoints being a sometimes-helpful crutch of sorts, vs their typical adoption as a "standard" set of predefined viewport dimensions designers should target. Because it ignores users who config their browsers to use larger fonts (a larger demographic than all IE users).
from a quick look, Blunt is mostly a (big) bunch of helpers for commonly used stuff like "lay the children out horizontally". i'm not sure if it'll be helpful if you're not very familiar with CSS – it seems to be aimed towards people
who know what to write, but just don't feel like typing "margin-left: auto; margin-right: auto;" a zillionth time :)
if you're not interested in designing your whole site's look & feel from the ground up, sth like Bootstrap or some minimal theme (bunch of those on HN recently) would probably be better. using a simple theme as a starting point and tweaking it to your liking might be the way to go
Sounds like using a subset of tailwind classes, focusing on positioning. This is what I’m doing on a nuxt project. I also use Sass for the visuals within each component.
That said I never found utility classes enough to handle breakpoints, it’s hard to read and understand when using only classes in the html. There is no space anywhere to document what the breakpoints achieve.
As usual, using multiple approaches is the best way to solve a problem rather than stubbornly sticking to some ideal like doing everything in tailwind, or using BEM naming religiously.
Also BEM syntax sucks. It’s really long and unsightly. SuitCSS is much nicer, plus it has a linter.
I love Tachyons, it was the first CSS library/tool that helped me feel comfortable tackling designing good looking pages.
I think its a great tool for someone not comfortable in the space. As you use it more and more you get a good understanding of what the properties are (using margins, paddings, headers, centering text, etc) + couple that with the VSCode plugin, it gives you the real css snippets for what the properties mean. Then over time you start to understand what properties make your html look that way, and then get comfortable writing css from scratch.
I love Tachyons as well, and am happy to see the project hasn't been abandoned in favor of far more complicated things (I mistakenly thought that was the case)
Tailwind has a class for almost everything, which makes it quite heavy: 1600kb minified. In my experience you end up with ≤ 15kb of minified CSS after running PurgeCSS anyway, so this is not an issue. Personally I prefer Tailwind because you practically don't have to write any CSS. With something like Blunt expect finding many edge cases where you will have to write custom CSS. I do write custom classes that wrap Tailwind classes using the @apply method.. e.g .card and .btn are typical examples (see https://tailwindcss.com/course/composing-utilities-with-appl...).
> ... Tailwind because you practically don't have to write any CSS.
Only until you want to apply a hover style change on a child element (ie: make that svg icon change color when you hover on the a tag that wraps it) and you discover that you need to write that css yourself.
Going slightly off topic but I wonder if anyone can point me to a tailwind "starter kit" - ie. a project with everything in place to get going with tailwind, postcss etc.
With a quick glance it looks like Blunt has fewer classes. It seems to be more of a utility + whatever-css-method you choose, e.g.BEM.
Blunt has utilities for margin, padding, height, width, font size, line height, grid and classes for row, column and some text alignment utilities.
Tailwind includes border, font color, transitions, background color, etc.
I'm using Tailwind on a project right now. My first one. I like it. But the big appeal to me is using the same classes on all of my projects. It's less cognitive overhead than coming up with names, dealing with scope creep on classes, etc.
That said, a buddy of mine that is a much better web developer than I uses Sass to make base utility classes and a BEM like approach for the rest.
Blunt looks like a simpler defined framework for styles.
Tailwind is a utility framework for your styles.
With Tailwind, I can do pretty much everything withotu having to write the "default" styles which I already know but don't want to.
Depending on my needs, team-size and flexibility, I can set Tailwind to be used without ever writing a single line of CSS or use it to define my custom classes.
> There seem to be hundreds of these things out there. So why bother with another one? Well, I was sick of fighting with the other options. Most are overly opinionated and result in spending time fighting the framework instead of it boosting productivity. I have tried so many different ones. Some do too much, others do too little. I needed some middle ground that worked for specifically what I wanted.
It genuinely doesn't feel like this boilerplate sentiment is ever necessary, but it seems to wind up in so many of these types of projects.
We get it, nobody who writes a CSS framework likes any other CSS framework enough to use it. If they did, this new framework wouldn't exist.
But it's a bad first impression to put an aimless rant the top of the readme of a project you're showing off, instead of talking about what makes this project unique, because there _never_ seems to be a good-enough reason to take a swipe at other people's work — especially when someone will inevitably start writing a CSS framework after liking 90% of Blunt but bouncing off one or two things Blunt intentionally does or doesn't do.
I can imagine maybe thinking it's relatable in some way, but to me, every time and without fail, it just poisons my sentiment before I've even looked at the implementation.
This seems to be highly subjective as I'm the exact opposite.
I guess perhaps I have an overly critical mindset, but when I see this, my feeling is more of relief that this is someone who considers the purpose and need of their projects carefully before starting, and is reluctant to "create more stuff" for the sake of it rather than leveraging idiomatic approaches.
There's also the added confirmation bias of reading a rant of frustrations you share.
NOTE:
This is a comment on the sentiment of your comment, not on the original article, the author of which I must say seems to be experiencing frustrations I do not share.
