I think that these four characters are being used:
U+2581 LOWER ONE EIGHTH BLOCK
U+2594 UPPER ONE EIGHTH BLOCK
U+258E LEFT ONE QUARTER BLOCK
U+1FB87 RIGHT ONE QUARTER BLOCK
(Sorry, no actual glyphs, HN is gobbling them.)
Notice anything different about the last one? It was added in Unicode 13 in a new block. This means very much reduced font support, and if absent, it generally means the use of a fallback font, which is very likely to mean a wider glyph, which means that the right edge of your box is displaced and probably the wrong thickness, and in some environments (though no proper terminals) anything following it will be offset too.
I use Triplicate as my monospace, and yeah, it lacks U+1FB87 RIGHT ONE QUARTER BLOCK, so this technique looks awful.
It gets a little worse when you consider line-heights. Some fonts design these things to fit line-height 1, others their default line-height, I think. The concepts are a bit fuzzy and implementations inconsistent and I don’t actually know the full details of what I’m talking about. Still worse, in browsers I don’t think the font’s proper preferred line-height (if that’s a thing?) is actually exposed, so you can’t actually get the correct result (the closest you’ll get is hard-coding the font metrics and hoping that font gets used, but that’s never guaranteed). But the end result is that you might get your box not neatly lining up in a terminal and probably won’t get it lining up in a browser, either squished more than it should be or with gaps, and in either case it’s going to be visually unbalanced in quite a disconcerting way, whereas the regular box-drawing characters are more likely to line up due to more care and even if they don’t the gaps (or maybe-visible-with-the-wrong-sort-of-antialiasing overlaps) will be balanced.
Conclusion: stop trying to be fancy, block element support isn’t good enough and the technique’s failure modes are quite bad; just stick with box drawing characters and no clever backgrounds, because that will work much more consistently, and wastes less space too.
You can just use U+258A LEFT THREE QUARTERS BLOCK and inverse colour settings. I use U+258B (LEFT FIVE EIGHTS BLOCK) in my editor that way (inverse of what you'd "expect", to get 3/8th's instead of 5/8ths)
Hmm, good idea. Wonder why a couple of the redundant-with-inversion ones made it in and others didn’t. Could be some historical reason, could be just “we had a few spots left over in the block of 32”. Can’t be bothered looking it up.
Certainly do this rather than using U+1FB87. SGR 7 to reverse colours and SGR 27 to cancel reverse, hopefully it’s pretty universally supported by now. I definitely expect it to be better supported than U+1FB87 in the chosen font.
To get these "drawing" type glyphs to look good and avoid unwanted gaps etc, terminal emulators generally just ignore the font and use their own custom rendering instead.
Conclusion: Demand more from your terminal emulator, including direct support for more of the Unicode drawing characters.
It's weird to me that in 2022 terminals are largely limited to text and text-based hackery. You'd think more terminals would support actual graphics, even if a bit limited compared to a full-blown windowing system.
Notice anything different about the last one? It was added in Unicode 13 in a new block. This means very much reduced font support, and if absent, it generally means the use of a fallback font, which is very likely to mean a wider glyph, which means that the right edge of your box is displaced and probably the wrong thickness, and in some environments (though no proper terminals) anything following it will be offset too.
I use Triplicate as my monospace, and yeah, it lacks U+1FB87 RIGHT ONE QUARTER BLOCK, so this technique looks awful.
It gets a little worse when you consider line-heights. Some fonts design these things to fit line-height 1, others their default line-height, I think. The concepts are a bit fuzzy and implementations inconsistent and I don’t actually know the full details of what I’m talking about. Still worse, in browsers I don’t think the font’s proper preferred line-height (if that’s a thing?) is actually exposed, so you can’t actually get the correct result (the closest you’ll get is hard-coding the font metrics and hoping that font gets used, but that’s never guaranteed). But the end result is that you might get your box not neatly lining up in a terminal and probably won’t get it lining up in a browser, either squished more than it should be or with gaps, and in either case it’s going to be visually unbalanced in quite a disconcerting way, whereas the regular box-drawing characters are more likely to line up due to more care and even if they don’t the gaps (or maybe-visible-with-the-wrong-sort-of-antialiasing overlaps) will be balanced.
Sample (remote since HN is gobbling all these Block Elements characters): https://temp.chrismorgan.info/2022-10-16-hn-comment-33217918..., also try copying it to your terminal to see if it differs from the web layout technique.
Conclusion: stop trying to be fancy, block element support isn’t good enough and the technique’s failure modes are quite bad; just stick with box drawing characters and no clever backgrounds, because that will work much more consistently, and wastes less space too.