My only suggestion is to optimise it, which we have :) (Lifting this from lower down in the thread). The following SVG fragment is a drop in replacement for the <img> tag and produces the same result, albeit completely symmetrical as a side effect of quantising the coordinates:
<svg width="18" height="18" viewBox="-32 -32 64 64"
style="background: #f60; border: 1px white solid;">
<path fill="#fff" d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/>
</svg>
This reduces the total payload from 1448 bytes to 172 bytes including whitespace (I ungolfed it slightly to make it less hacky). By comparing both the inline <img> tag, and the svg file and it's HTTP header (which disappears when you inline).
Choosing a viewBox of size 64 as you have, is a much better choice than 100, because 64 is a power of 2. Symmetry is hard to achieve by hand with a path, and even harder if the origin is at the top left (0,0) instead of in the center (as you also have), because it's obvious that -3 is symmetrical to 3, and less immediately obvious that 47 is the opposite of 53 for example.
That said, if working entirely by hand, using elementary shapes can be easier to write and understand (I think); here's an attempt with using one rectangle three times for the Y (and another rectangle to mask the edges at the top):
Stop it! If you bastards optimize this any more, you'll hit the fractal limit, and drop into negative optimized space, renting local spacetime, killing us all!
Ok, but my point was to be readable and easy to understand by using elementary shapes (rectangles), not to be as small as possible. (My version is much bigger than the comment it was replying to.)
Speed is not the only criterion. Using network is a waste of energy and materials when the local cache was enough (even more when nobody sees the perf difference)
That's a valid point, for subsequent loads in this case the inline svg is so small that when compared to the image tag it's replacing the difference is pretty small.
But the other side of this is cache latency, this depends on the caching policy defined in the http header, for example some modes require validating caches with the server which incurs a round trip even if it doesn't require always reloading the resource. If it's fully offline caching then as a sibling comment pointed out, disk caching is not free either, under some threshold (which definitely applies here) inline is going to be the fastest way to get an svg rendering.
Oh I use 'unminified' for that. Even though someone deliberately wrote minified code rather than automatically, so sometimes people disagree. Maybe 'ungolfed' is better.
there's a difference. unminified refers to a program doing that, using single letter function names and such, but the underlying logic is unchanged. code golf is different from that because the human can make changes to the underlying logic if it saves some lines of code, so long as the output is the same.
more advanced minifiers do that as well, but the point remains, as a historical artifact because until we have AGI, there's still a difference between if a person did it vs a human
I personally also use 'unminified' to refer to a horrible person that doesn't care about anyone else maintaining their code doing the same thing, like they're
manually minifying their code to obscure it from their colleagues and future selves.
I wanted to make that definition more popular as there is no reason to write unsearchable code that requires someone else to maintain a mental map of meaningless names to their actual meanings while reading code.
A lot of people (you're one, nothing personal, but I explained this already in a parent comment) don't realize I'm deliberately calling attention to bad behavior and just think I'm confused though. I'll swap to ungolfed.
My only suggestion is to optimise it, which we have :) (Lifting this from lower down in the thread). The following SVG fragment is a drop in replacement for the <img> tag and produces the same result, albeit completely symmetrical as a side effect of quantising the coordinates:
This reduces the total payload from 1448 bytes to 172 bytes including whitespace (I ungolfed it slightly to make it less hacky). By comparing both the inline <img> tag, and the svg file and it's HTTP header (which disappears when you inline).