This solution uses 3 elements, a parent element, and 2 child elements, one for each row of text.
Using an absolutely positioned :before element, sized to the same size as the parent, sent behind using negative z-index, then then given further padding using negative margin values creates this effect. This solution probably gives the most control and least css
The secret sauce really lies in the display: table
property on the .text-row span. It stop the absolutely positioned :before element from taking up too much space.
The beauty of this solution is that the padding will always scale perfectly with the text (especially when using em values on the padding and negitive margin), also you can align rows as close as you want with line-height without the background ever clipping the text.
Spring @ParkHowever when we add a transform to tilt it we have problems with cutting off of the bottom of the text:
Span with :before bg Span with :before bgThis is because adding a transform creates a new stacking context, and the negative z-indexed pseudo elements rise to the top again.
But if we put the transform on the parent row instead it works great
With this setup we can now introduce some extra properties for styling flare, such as box-shadow and text-shadow.
Due to there being a span for each line you have to manually set the text ie. what text is on what line. In this respect it's non-responsive.
You can't add a border around all the rows... you can add a box-shadow to all the text-rows at the right and bottom, but trying to add a box shadow on the top or right will look wierd visually.
Can kinda visually break if you use the box-shadow and the second line isn't as long as the first... but that's probably an edge case seen as you can control the margin-left of the second line to push it across anyway.
Beware that things get wierd if the banner is smaller than it's container, make sure to appropriately size the text with media queries... if you've used em values for the padding and negative margin everything else should scale nicely based on the text-size.
The element that contains the text string must be set to display: inline.
This is the problem, if you want to adjust the line height so the text is more tightly set, the background clips the top and bottom of some text characters. Look at the lowercase g above.
You can see the other problem is that we need to add a padding on the text... but when set as inline block the text will only add left/right padding at the start and end of the text string, not the start and end of each line as rendered. Also, with this method any top/bottom padding will just increase the cropping / hiding of other lines of text.
So, how can we solve this? Luckily, CSS has thrown us a piece of candy in the box-decoration-break
property. Let’s take a look.
The box-decoration-break CSS property specifies how the background, padding, border, border-image, box-shadow, margin and clip of an element is applied when the box for the element is fragmented. Fragmentation occurs when an inline box wraps onto multiple lines…
Basically, this property is giving us a bit more granularity in how an inline element gets rendered.
By default, it’s set to box-decoration-break: slice
, which means that it treats the inline box as if it weren’t fragmented at all. I like to think of it like this.
Imagine that we took that multi-line inline element, stretched it out onto one line, applied the styling, sliced it into pieces, then moved each piece back to a new line. The result would be that the properties mentioned above would act on the entire box of the element, rather than each of its parts.
However, there is a second option for us, and that is: box-decoration-break: clone
When we set the property to clone, we can imagine a similar scenario as above, except one important thing. This time, let’s imagine that all the styles get applied after the element gets fragmented and distributed on multiple lines. In other words, paddings, borders, etc would be applied to each fragment almost as if they were separate elements.
The h1 has to be inline, that means you can't offset the lines in any way. You can't use text-indent. Also you couldn't use text-align: justify; if you wanted to do that sort of thing.
You also can't use psuedo elements such as :first-letter or :first-line because The pseudo element only works if the parent element is a block container box.
The problem is still with line-height causing cropping on the text :(
Also any top padding you add will result in a row cropping text in the row above.
So really this solution has limited appeal.
The advantages are that you can apply all these properties on one element, no need for a parent wrapper or new elements for each subsequent line of text. This solution is therefore also more responsive in that you can resize the container smaller and the line padding will still work as expected.
Fine when using a gradient from left to right
But not top to bottom
...However that shifts the padding over to the left and unless you use a parent element around it you can't shift it over again using padding or margin, because it'll just add it to the first line otherwise.
We control the top and bottom padding with a mix of line-height and padding-top/bottom. unfortunately this is a balancing act, you still can't have tightly set lines and large top/bottom padding.
This technique works much better with uppercase text, that way there arent hanging ligatures to be cropped off
This is working in Chrome and Safari, and now working in Firefox 32+, in my quick tests. Chrome and Safari require it to be -webkit-box-decoration-break.
With box-decoration-break:clone;
If we use the same technique as above but replace box-decoration-break:clone; with background-attachment:fixed we should see the same gradient being used across each line. NB: resize the viewport if below isnt visible.. think this is a codepen bug
This technique has limited use as a solution in this context due to the following issues: