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.
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.
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.
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.)
Interesting, I never realized the Y wasn't symmetrical. The left branch is slightly lower and to the left of the right branch in the Y. This also creates a gap in the center of it at high resolutions: https://i.imgur.com/vwPnz2j.png
If this wasn't intentional, here's a symmetrical version:
Fun fact: "Y" in your comment is not symmetrical either. Letter shapes are usually not symmetrical, Y/X/etc. even in gothic sans typefaces add asymmetries that make text easier to read.
This is some excellent planning. When a future request comes in for east votes and west votes, they can just update the rotate() parameter and push the changes straight to prod.
It would be good to have native dark mode without the need for different browser extensions or hacks. This way we would be able to read HN from mobile, tablet, computer no matter what the browser or OS is.
Sounds like a nightmare to check the logo in every combination of OS and rendering engine to make sure the 'Y' is perfectly centered in the box and has the same weight.
It doesn't have the same weight or even shape as the old one, so I'm honestly not sure this was a priority. But in principle you are right, SVG is the correct choice.
In this case the extra request to the server (and associated response) to check if the file has been modified is several times larger than the minified size of the SVG inline. It's literally faster and fewer requests to inline it.
For the benefit of people who don't follow such things attentively: /y18.svg has been /y18.gif for — at least 16 years, as a lower bound [0]. Some have filed bug reports [1] about it. The old one was rasterized and slightly fuzzy when zoomed.
Oh that ship already sailed. Click on the "parent" link. Notice that it breaks your browser history now because instead of being a link to an element in the document it runs some javascript to scroll the page… commence teeth gnashing.
This is why, on almost every website I visit where I know I'll be opening multiple links (which would normally require hitting the back button to view them all), I just open every link in a new tab and then close the tab when finished.
I suspect many people use HN (and similar) this way.
It's always a fun time when I occasionally use the browser/website "as intended" and hit the back button, but the scroll position has been completely lost so it takes a bit to find the exact place I was looking originally.
> the Y is not bold enough to look much different than a plain orange square
Seconded, it feels like the spacing between the Y and the borders is a bit too large. I would make the Y a bit thicker.
Other than that, it looks good. Voting arrows particularly so. I have memories of browsing HN on the TV at >200% zoom, the logo was very blurry in that situation.
229 comments
[ 2.8 ms ] story [ 248 ms ] threadThere 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.
<svg viewBox="-32 -32 64 64" style="background: #f60"><path fill="#fff" d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>
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"
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.)
If this wasn't intentional, here's a symmetrical version:
https://news.ycombinator.com/triangle.svg
Truly incredible developments.
Now if the mobile view could space items out a touch more so I don't periodically fat thumb the tiny flag/hide article links it would be perfect!
I check mine every now and then, and I always find some I fat fingered.
It drives me NUTS that I am adding noise to this system.
https://gist.github.com/selcuk/00948de9717b25d0d5e824c3e80da...
SVG doesn't change the way positioned text does.
The raster 'Y' is definitely more acute than the new one. The vertex is lower. But those old voting arrows look terrible now.
[0] https://web.archive.org/web/20230201012035/https://news.ycom...
EDIT: since we're code golfing/bikeshedding, here's my own attempt, which matches the original proportions [1].
[1] Actually, the original is slightly asymmetric -- the right leg is slightly narrower. I've "corrected" this, making the right leg mirror the left.<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg"><path fill="#F60" d="M0 0h100v100H0z"/><path d="M50 77V50M73.685 14.377 50 50M26.465 14.449l23.26 35.623" fill="none" stroke="#FFF" stroke-width="8.787"/><path fill="#F60" d="M0 0h100v23.743H0z"/></svg>
Wonder if it can be made any smaller?
Disclaimer: from memory and tongue in cheek. May not work!
[0] https://hn.algolia.com/?query=y18.gif&type=all
[1] https://news.ycombinator.com/item?id=21544141 ("Can whoever is in charge of HN's site design convert this to an SVG image?" 'octosphere, 3 years ago)
I suspect many people use HN (and similar) this way.
It's always a fun time when I occasionally use the browser/website "as intended" and hit the back button, but the scroll position has been completely lost so it takes a bit to find the exact place I was looking originally.
White square border looks good though.
1920 x 1080 on Firefox, plain orange square even more so on the browser tabs.
Seconded, it feels like the spacing between the Y and the borders is a bit too large. I would make the Y a bit thicker.
Other than that, it looks good. Voting arrows particularly so. I have memories of browsing HN on the TV at >200% zoom, the logo was very blurry in that situation.