DEV Community

Cover image for CSS Box Decoration Break to the rescue

CSS Box Decoration Break to the rescue

Chris Bongers on March 04, 2022

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...
Collapse
 
mhadi2003 profile image
Mahdi

That's great 👌

Collapse
 
dailydevtips1 profile image
Chris Bongers

Agreed, super useful less known property

Collapse
 
posandu profile image
Posandu

Chris! You are so awesome. You are writing articles every day. Love them! Keep up the good work

Collapse
 
dailydevtips1 profile image
Chris Bongers

Thanks for the support 🙌

Collapse
 
anitaparmar26 profile image
anitaparmar26

Thanks for sharing i dont know about this property

Collapse
 
dailydevtips1 profile image
Chris Bongers

Glad you learned something new 🙌

Collapse
 
amircahyadi profile image
Amir-cahyadi

Thanx you 👍

Collapse
 
dailydevtips1 profile image
Chris Bongers

Thanks for the reply Amir 🙌

Collapse
 
ingosteinke profile image
Ingo Steinke, web developer

Nice to know! Always appreciate to learn about new and lesser known CSS properties!

Collapse
 
dailydevtips1 profile image
Chris Bongers

Yep, was really surprised by this one, exactly what I needed.

Collapse
 
dailydevtips1 profile image
Chris Bongers

Glad you enjoyed it Leonid 💖

Collapse
 
jt3k profile image
Andrey Gurtovoy

tailwind suxx

Collapse
 
dailydevtips1 profile image
Chris Bongers

Why do you say that?

Collapse
 
jt3k profile image
Andrey Gurtovoy • Edited

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

<button class="px-4 py-2 font-bold text-white bg-blue-500 rounded">Submit</button>
Enter fullscreen mode Exit fullscreen mode
  1. 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?

  2. 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.

  3. 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.

  4. 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.

<button class="btn">Submit</button>
<button class="btn px-6 py-4 bg-red-500">Submit</button>
Enter fullscreen mode Exit fullscreen mode

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).