When I was working on redesigning this blog, I created this slick-looking header effect.
I'll explain how to re-create this effect in a bit, and...
For further actions, you may consider blocking this person and/or reporting abuse
That's great 👌
Agreed, super useful less known property
Chris! You are so awesome. You are writing articles every day. Love them! Keep up the good work
Thanks for the support 🙌
Thanks for sharing i dont know about this property
Glad you learned something new 🙌
Thanx you 👍
Thanks for the reply Amir 🙌
Nice to know! Always appreciate to learn about new and lesser known CSS properties!
Yep, was really surprised by this one, exactly what I needed.
Glad you enjoyed it Leonid 💖
tailwind suxx
Why do you say that?
because it is useless a little less often than always.
it is not easy to write, much more difficult to read.
We write code once and read it dozens and hundreds of times.
This was previously promoted under the name atomic-css and has already proven to be useless.
Let's take a simple example divorced from real life
Only 6 classes-properties, and the eyes are already starting to ripple.
But this is a very simplified demo button. In real life, you will need not 6, but ~ 15-20 properties. And then 4 more states - hover, active, focus, disabled. Would you like 30-40 classes, of which half are with state prefixes?
Magic numbers. I know this brilliant idea - "let's reduce all the indents to five sizes!". Practice says that such a system does not live for a long time, there are always exceptions, new sizes, the scale goes astray, crutches are used, and so on. I repeat, as auxiliary utilities, this is quite suitable. But for the foundation of the components, I prefer something more meaningful like $button-small__paddings. This is another harmless example, there is more fun in the dock.
Mixed styles of the block itself and its positioning. In BEM they are separated and believe me, this is not someone's whim, it really simplifies life.
How should I monitor the consistency of all buttons?
It is clear that writing all this happiness in html is possible only for prototyping. Okay, we pick out the classes from html and use the css preprocessor as mixins.
In my opinion, this approach looks much more interesting than the same BEM. We write the basic properties of the button, and we write all the modifications not in a separate class, but simply on top.
Convenient as long as these patch classes do not depend on the state of the button (colors depend) and / or on media queries (sizes, padding, positioning depend). As soon as yes - again we get noodles.
With classes like .btn.btn-red, it has become better - well, because we are moving towards accepted practices. But the meaning is slowly slipping away. If I drag all the styles into CSS, then why do I need TW, what problem does it solve?
Are the lines shorter? I don't care, the dialing speed is the same, autocomplete. Obviousness is more important for a random developer.
More clearly? The devil knows. Of course, there are obvious things like .font-bold, but let's say .flex-1 does not have an unambiguous interpretation without docks.
Confused by similar colors and fonts? There are variables in the preprocessor, there are native variables.
It turns out that there is no "new paradigm".
There is a parallel CSS language that does not bring anything new. It's just an extra layer that duplicates the native CSS layer. And besides, they will have to be mixed, because for some of the properties there is no analogue. Here semantic classes/mixins are higher abstractions, and this layer is additional, but not another (read unnecessary).