Show HN: Blunt – A CSS Layout Framework for Minimalists
github.com
github.com
<div class="container auto-center h-100 row v-center h-center">
<div class="card lg-w-30 md-w-40 sm-w-90 pt-2 pb-2 pl-2 pr-2">
<div class="sm-col md-row lg-row md-v-center lg-v-center">I've moved on though, I learned flexbox and css grid and some atomic design principals as well as ABEM (https://css-tricks.com/abem-useful-adaptation-bem/) and I'm happy.
Out of interest, that article goes out of its way to argue that the whole BEM format is changed to CamelCase, so that the atomic modifier can use "-".
Why wouldn't you just use the existing BEM component separator "__", and then nothing else need change.
The CamelCase version is prettier granted, but rather than an extra bit of information, it's a completely new format.
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.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/--*
[2]: https://drafts.csswg.org/css-nesting-1/
[3]: https://postcss.org/
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.
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.
Either 0 or 1 times. Use semantic classes `<a href="/path/to/create-stuff" class="button">` and use custom properties or the cascade from there:
:root {
--button-margin-block: 1ex;
--button-margin-inline: 1em;
}
dialog {
/*
* Modals buttons need more block space and
* less inline space.
*/
--button-margin-block: 1em;
--button-margin-inline: 1ex;
}
button,
.button {
margin-block: var(--button-margin-block);
margin-inline: var(--button-margin-inline);
}padding: p(‘s’) p(‘m’);
For that 8-px magic.
c for colors, bp for breakpoints, f for fonts etc.
This solves all the inconsistencies addressed by css frameworks and gives me slightly larger LEGO blocks.
<div style="margin-inline:auto">Center</div>
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.
(This SO answer summarizes why CSS injection is something to care about: https://stackoverflow.com/a/718614)
It's almost trivial to set up a keylogger with css that fires requests on keyboard input. Luckily there's CSP.
- http://www.thespanner.co.uk/2007/11/26/ultimate-xss-css-inje...
- http://archive.is/20150708191322/http://i8jesus.com/?p=10
- https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Sc...
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.
Edit: removing my snarkiness.
The 'simple' responsive card example uses 9 divs and 33 classes.
This is madness.
It's a case of combinatorial explosion, e.g. there is a style for every integer up to some max I didn't care to find out, for the height:
.pxh-558 { height: 558px; }
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 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.
also want to add: a good CSS thing to learn right now is the CSS grid. you can hammer out the blocking layout of your pages so quickly with a grid.
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).
/$.02
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.
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.
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
Is pretty good - similar to at least one version of bootstrap's grid, but just does the layout
...
.sm-pxh-676 { height: 676px; }
.sm-pxh-677 { height: 677px; }
.sm-pxh-678 { height: 678px; }
.sm-pxh-679 { height: 679px; }
...
And if you're truly minimalist,
A- you don't need a framework
B- you don't pollute every html tags with tons of classes.
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 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.
+1 Tachyons
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.
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.
E.g. of a recent project https://github.com/sagri/sagri.co
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.
Thanks!
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.
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.