Expected: a yellow line crossing an entire 236x236 image, in all three cases.
Explanation: svg default size is lunatic (300x150) and it doesn't care of your layout modes, so it clips all drawing beyond that, unless you specify either width/height attributes (not css properties!), or a viewBox, from which it infers missing width/height.
I lost a day to this once, when parent-filling svg clipped 3 of my 5 shapes for no fucking reason. Shapes coincidentally fell either fully into 300x150 box or fully outside of it -- no easy hint for you.
You can pre-calculate that in js, but if you specify .wrapper's dimensions in non-px, or use some aspect fit, you're screwed as well.
True, SVG itself can be surprising if you don’t know what you’re doing with it—it’s a powerful graphics format that supports flexible sizing and aspect ratio handling, which is much of the reason why width/height and viewBox are separate things, and in cases like this it’s important to understand what they each mean (and how any of them are inferred in the presence of the other).
For the sort of thing that you’re doing here, there are two most likely possibilities for what you want:
① Give the <svg> element a preserveAspectRatio attribute, most likely preserveAspectRatio="none" if you’re just trying to draw a diagonal line across the image. This’ll allow it to stretch the SVG, effectively throwing your stroke-width off a bit so that it could look wrong if you use it on multiple images of different aspect ratios.
② Accomplish a dynamically-sized viewBox with percentages: <svg width="100%" height="100%"><line x2="100%" y2="100%"/></svg>
Fortunately all of this stuff is nailed down pretty well now. IE always had trouble with these more unusual aspects of SVG, even to IE11. I fondly remember a design I implemented a decade or so ago that exercised just these sorts of fiddly areas, causing such issues on IE9 that I gave up and made it use the simpler, not-as-pretty non-SVG fallback that was necessary at that time because of IE6–8.
Technology is only as good as its outcomes are. I didn't instantly realize back then that width/height attributes are required, because SVG as an element (not as a powerful format) doesn't respect given CSS layout. You didn't instantly detect the issue to suggest a working solution, probably because you know too much recipes to pick one off the top of the head. This is the end result of such technology - we both spend much more time learning and/or explaining than it could be. Now multiply that by the factor of world and by general shortage of a single-person skill capacity and time.
If you pick any other technology, e.g. an airport gateway system or a shop checkout line, and apply this "can be surprising if you don’t know what you’re doing with it", you'll get a big congestion instead of a functioning airport or a shop. Users are not to blame when the system is based on some cryptic nonsense. Good systems just work, bad systems require custom effort to fly and never scale. These congestions induced by web tech only pull us back and I can't understand why you're so positive with it (if not condescending; sorry if I mistook that).
It indeed is [1].
Expected: a yellow line crossing an entire 236x236 image, in all three cases.
Explanation: svg default size is lunatic (300x150) and it doesn't care of your layout modes, so it clips all drawing beyond that, unless you specify either width/height attributes (not css properties!), or a viewBox, from which it infers missing width/height.
I lost a day to this once, when parent-filling svg clipped 3 of my 5 shapes for no fucking reason. Shapes coincidentally fell either fully into 300x150 box or fully outside of it -- no easy hint for you.
You can pre-calculate that in js, but if you specify .wrapper's dimensions in non-px, or use some aspect fit, you're screwed as well.
[1] https://codepen.io/mhmdqrn/pen/yLMvGJW