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 then we'll dive into a problem that almost had me remove the effect.
How to create the text background effect
The idea of this effect is to have a background on your text, which wraps neatly around the words.
I'll showcase the code in Tailwind, but I will also explain the essential parts.
The main setup will look like this:
<h1 class="bg-purple-600 text-white text-3xl rounded-md font-bold inline px-2">Your content here</h1>
This will already give us the effect as we saw in the image above.
The main effect is a combination of display: inline and the background color we set.
We use rounded corners to make it look a bit slicker.
The problem at hand
Of course, there had to be a problem with this fantastic effect.
And it quickly showed itself on mobile devices.
The idea is great, but it's super annoying that the text is cut off from the sides.
Well, I guess it was to be expected, right? π©
Since everything is only one element, with one line of text, the padding is only applied at the beginning and end of that line.
At this point, I considered removing the effect or changing how it looked.
Until a superhero arrived called: Box Decoration Break!
And it does exactly what we are looking for!
This amazing feature comes with two states:
-
slice: Elements are seen as one big element (So what we have seen happening) -
clone: Element is broken into fragments with each their own copy of the styles.
The clone feature is what we are looking for, and let's see how that looks.
To add it simply add the following classname: box-decoration-clone. (Or box-decoration-slice)
This, in return, will add the following CSS classes for those not using Tailwind.
.box-decoration-clone {
-webkit-box-decoration-break: clone;
box-decoration-break: clone;
}
And that's it, way better!
Super happy I found this fantastic CSS property, and it made my headers look amazing.
You can see the completed code example on this CodePen.
Browser support
The support is actually not bad, it has some partial support on certain browsers, but consider what it does I'm really happy to see such a wide support:
Thank you for reading, and let's connect!
Thank you for reading my blog. Feel free to subscribe to my email newsletter and connect on Facebook or Twitter
Top comments (14)
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).