> In fact, even each z can be dropped, provided no stroke is being used, removing three edges.
While that may be true according to the spec, I can tell you from a practical standpoint that it will break in Lightburn. It's SVG handling does unexpected things with implicitly closed paths, which suddenly go away when you explicitly move/stroke back to your starting point or "z".
I have not looked deeper into why, but if I had to make a WAG, I'd suspect it comes from their implementation trying to bridge the gap between SVG generators (which are optimized for "shape looks correct") and machine control instructions (which target the lower level "here are the steps to make this shape look correct"). You're then having to take something simple like a path and adding in the complexities of making machine control instructions for the practical rendering of that path, accounting for things like miters, etc. Seems like a complex layer, prone to tons of annoying little bugs like this.
I presume YouTube's designers/coders aren't worried about being able to run their UI widgets through a laser engraver, but I tend to chalk up these kind of "missed optimizations" to having some similar backstory of "we found this bug in this implementation, so here's the workaround".
M21 5H3v1h18m0 5H3v1h18m0 5H3v1h18For compression purposes, mine is going to be kinda like this:
‹M21 ›5‹H3v1h18›‹M21 ›11‹H3v1h18›‹M21 ›17‹H3v1h18›
M21‹ 5H3v1h18›m0‹ 5H3v1h18›m0‹ 5H3v1h18›
I’d lowercase that M, too; it doesn’t need to be uppercase, so it might as well be lowercase like the others!
• It has three extraneous points: each rectangle is comprised of five points, because it draws to the start point manually (V6/V11/V17), and then says draw to close the path (z). The V6/V11/V17 should just be dropped: z covers that. In fact, even each z can be dropped, provided no stroke is being used, removing three edges.
• It misses compression opportunities, by having the first one go counterclockwise and the remaining two go clockwise, and by using absolute coordinates in places where the same relative coordinate could be used (e.g. V11/V17 could both have been v-1, and if the first one’s direction was sorted out then that V5 could also be v-1; but we’re eliminating these vees anyway, so—).
All up, that hamburger menu data of this:
Could be replaced with this path data which is more compact, more compressible, and faster to draw by probably at least a femtosecond or two: Note in that how `M21 ` and `H3v1h18` are each repeated three times, with `5`, `11` and `17` being the only things that appear once. This attention to maximising exact repetition will save another few bytes.Depending on how you do things, it could even be better to replace the 12-point fill with a 6-point stroke (though I freely admit that more care is required because of stroke-width, stroke-linecap, stroke-linejoin, mixing fill and stroke, &c.):