[chrismorgan]

Nah, these aren’t obscure at all.

Covering a image with something (whether SVG or not) is very common, though most of the time the image’s size will be known, or at least known in one axis. We’re talking things like putting captions on top of images.

Needing hover effects to render on top of elements around is even more common—if you want a row of buttons that share borders, by far the easiest way involves this very situation. Example where `position:relative` does the magic:

  data:text/html,<style>button{border:2px solid red}button:is(:hover,:focus,:active){border-color:lime;position:relative}button+button{margin-left:-2px}</style><button>ⅰ</button><button>ⅱ</button><button>ⅲ</button>

[onethought]

If it's very common... how is it difficult?

[chrismorgan]

It isn’t.

[dmitriid]

It isn't difficult to you because you've memorised that particular hack, And, undoubtedly, many others.

It doesn't make them any less of a hack.

[chrismorgan]

Certainly neither technique for covering an image that I showed in another comment is a hack. They’re both logical, coherent and fairly obvious ways of doing it. Getting hover effects to render on top, well, I wouldn’t consider that a hack either, though it’s a little more subjective (“why does position:relative make it work?”). I say that of course those effects aren’t going to render on top by default, because rendering is done in order unless you fiddle with layers and z-indexes, so shunting the hovered element onto a new layer or increasing its z-index above its surrounds is the obvious thing and the only way it could work.

I know many things that are hacks and that I will acknowledge are hacks, but these two aren’t hacks at all. They’re straightforward and natural CSS, working in exactly the way it was designed (and in areas where that design is completely sensible).

[dmitriid]

> Certainly neither technique for covering an image that I showed in another comment is a hack. They’re both logical, coherent and fairly obvious ways of doing it.

The absolute "obvious ways":

- a wrapper div that has to be position: relative. And a display block/inline-block because otherwise it won't work. An svg and an image inside that div. The svg has to be position: absolute.

- a full-blown grid. Two elements must be forced to occupy the same cell in the grid

Ah yes. Absolutely logical and coherent and not hacks at all.

> Getting hover effects to render on top, well, I wouldn’t consider that a hack either, though it’s a little more subjective

"Not a hack": rendering is done in order, but you still have to "shunt the hovered element onto a new layer or increasing its z-index above".

And this still doesn't precisely solve the problem of "outlining a hovered element so that outline/shadow covers other items around". Because most likely you'll have layers on top of layers of "logical coherent" wrapper divs to make everything work together, and you have to spend some time figuring out how to make that particular problem actually work.

And god forbid you want to make it pretty: https://tobiasahlin.com/blog/how-to-animate-box-shadow/

[chrismorgan]

Yes, absolutely logical and coherent. I’m not saying it’ll be so to someone that knows nothing about CSS, but rather to someone that generally understands CSS, because these solutions I discuss are straightforward and built upon well-known CSS fundamentals; they’re not complex in any way. The only part that is arguably not quite so logical, coherent and obvious is display:inline-block in order to limit the width, but even that I reckon is fairly obvious, that you’ll need that or to contain the element in certain styles of flexbox or grid.

Not everything is straightforward, but the things I was talking of are. (Incidentally on the matter of performance on animating box shadows, that’s actually not fundamental; Firefox has proper GPU rendering of it all, via the WebRender project, so that advice is irrelevant and actually (negligibly) slightly harmful in Firefox; it’s just that Chromium and WebKit haven’t caught up.)