Hacker News Reader

Comment by 5- | Hacker News Reader

that's a lot of svg! svgo suggests the following without any manual tinkering:

  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><path fill="#F60" d="M0 0h100v100H0z"/><path fill="none" stroke="#FFF" stroke-width="8.79" d="M50 77V50m23.69-35.62L50 50M26.47 14.45l23.25 35.62"/><path fill="#F60" d="M0 0h100v23.74H0z"/></svg>

View on HN

I see your 258 byte svgo version and raise it my 171 byte hand optimized version:

    <svg viewBox="-32 -32 64 64" xmlns="http://www.w3.org/2000/svg"><path fill="#f60" d="M-32-32h64v64h-64z"/><path fill="#fff" d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

Better still, an inline SVG fragment is only 151 bytes - and will save 318 bytes of http header:

    <svg viewBox="-32 -32 64 64" width=18 height=18><path fill=#f60 d="M-32-32h64v64h-64z"/><path fill=#fff d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

118, can we beat it anyone?

It doesn't need to be valid XML if you embed it in the HTML, which was their point.

Edit: I stand corrected, it does parse correctly when embedded in HTML!

By the tiniest of margins, 115. Deleted two spaces and an `l`. Largely inspired by `svgo`. Using `rsvg-convert` to render them both to PNG shows identical output between this and the 118 version. https://rjp.is/hn-svg.html seems to render them identically in Safari and Chrome.

    <svg viewBox="-32-32 64 64" style="background:#f60"><path fill="#fff" d="m0-5-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

But not in Firefox :(

That appears to be trigged by "-32-32" (broken) vs "-32 -32" (working). Looks like this has been a long-standing weirdness in Firefox[1] where it is allowed somewhere but not other places.

On the other hand, the spec[2] does specify whitespace or commas between the viewbox numbers.

I rescind my 115 claim and reset it back to 116.

[1] https://github.com/svg/svgo/issues/12

[2] "a list of four numbers <min-x>, <min-y>, <width> and <height>, separated by whitespace and/or a comma"

We can move the fill to the style attribute and get it back down to 114:

  <svg viewBox="-32 -32 64 64" style="background:#f60;fill:#fff"><path d="m0-5-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

Oh, if you then switch to the comma-style for viewBox, drop the / from the path tag, and drop the quotes from the style attributes, that takes it down to 109.

Safari, Chrome, and Firefox are all perfectly happy with it but then rsvg-convert chokes on all of those changes. 114 is probably the best that can be done and still be "conforming" (for want of a better word.)

viewBox can be comma-separated, so you can loose the quotes but only for inline SVG

Well, that seems to work in everything (Firefox, Safari, Chrome, rsvg-convert) and drops it down to 114. Ta!

Transport compression should get it most of the way there, no? I think having human readable vector graphics is nice.

This the most HN string of replies I've seen. Cheers haha

Apart from being one-lined, the optimised version is more readable and roughly about as compressible. There’s really no reason to have transformation matrices for 2 squares and a simple polygon

transport compression isn't going to help with the unnecessary high precision coordinates.

There are also a bunch of things that are just the result of it being automatically generated by some vector package, such as the transforms, separate paths, masking of a bunch of strokes rather than just flattening the shape etc.

Reply on news.ycombinator.com