Blink and WebKit implement content: url() allowing to replace an element with an image.
However the behavior differs and doesn't look quite intentional, and WebKit's behavior looks different if the image is already loaded or not (the second image would display alt text after a relayout, wat).
Consider this test-case:
<!doctype html>
<img src="broken" style="content: url(https://www.w3.org/2008/site/images/logo-w3c-mobile-lg)" alt="This is my alt text">
<img src="https://www.w3.org/2008/site/images/logo-w3c-mobile-lg" style="content: url(broken)" alt="This is my alt text">
How should this render? Should content: url() apply or not? If it does, should it display the alt text? Why only for <img> (if the image is broken in a <div>) it just doesn't render?
Also, note that in Blink at least, if the image is already loaded for the second <img>, or if you toggle display manually, suddenly it displays the image instead of the alt text.
cc @lilles
Edited on 2018-08-22 with a better screenshot.
Tested with http://la-grange.net/2018/07/31/content/ in

'content' should definitely work on img; there's nothing particularly special about it that would make this not true, I think.
Now, what to do when the 'content' URL is broken, but a 'src' url exists, is an interesting question. It seems like it makes the most sense to have 'content' fully win, so that if it's specified but the URL is broken, you just get the "0x0 transparent image" that's specified in the spec? This appears to be what falls out of the definitions, at least. We could instead specify that there's some notion of an "intrinsic image" coming from the element that it can fall back if possible, but that seems like complexity for complexity's sake; if we want to do fallback, we should just implement image() properly, not rely on this weird hack.
Notably, tho, <content-list> defines a different behavior for invalid images - browsers are allowed to display "broken image" icons in their place. I'm not sure why <content-replacement> is defined differently, and I'd be okay with harmonizing them.
Assuming that, ignoring the relayout bugs, Safari's behavior would be correct (showing a broken image, since no alt was provided in content). Chrome's would be incorrect.
I changed the screenshot in https://github.com/w3c/csswg-drafts/issues/2831#issuecomment-414527801 as Chrome and Safari seem to be consistent.
'content' should definitely work on img; there's nothing particularly special about it that would make this not true, I think.
Well, image is a replaced element, and content: url() on other elements like <video> or <iframe> doesn't replace them. So I'm not think it's that obvious.
Slightly related: #729
(edit: wrong issue)
Well, image is a replaced element, and content: url() on other elements like
Take this as my assertion that content should work on those elements, too. ^_^ It not working is probably an accidental detail.
Most helpful comment
Take this as my assertion that
contentshould work on those elements, too. ^_^ It not working is probably an accidental detail.