Tell HN: The “Y” logo in the top-left corner has been upgraded to SVG | Hacker News Reader

Tell HN: The “Y” logo in the top-left corner has been upgraded to SVG

news.ycombinator.com

579 pointsperihelions218 comments

Hey all, I wrote to dang a few months ago -- the non sharp upvote button was bothering me on mobile (and desktop when zoomed in), and I felt like the Y could be sharper too. These were the only elements that were fuzzy - everything else is text, and scaled perfectly!

We collab'ed on it together (more praise for dang as if he needs it -- he was incredible through and through) and I'm so happy to see it live!!

I built two micro tools to help nail it down if anyone is curious (aka make it visually seamless):

https://gregsadetsky.github.io/yc-logo-svg-comparison-editor...

https://gregsadetsky.github.io/yc-vote-button-editor/

(check the top right of both pages to see the UI controls)

Uh... AMA? Suggestions? Thoughts?

Thanks for the support -- so far nobody hates it? Does anyone hate it?

Cheers!

The Y shape is visibly different to me, even at 18 px. In the new version, the "leg" is longer and the "arms" shorter and at a more obtuse angle to each other. Compare vs. the favicon: https://news.ycombinator.com/favicon.ico

Manually tracing the favicon in Inkscape (and correcting what I believe to be an unintentional asymmetry) gives me this: https://news.ycombinator.com/item?id=35894797

The vote buttons look great. I noticed-but-didn't-notice after seeing this post.

EDIT: vs. the favicon, on my screen, the new version is "bolder" as well.

Correct. Also, at 1x (which is what matters the most on desktop & mobile for me, I think) the bottom-most extent of the "leg" is not far enough down. There is too much orange under the leg. There should be more white at the bottom. The Y is getting crunched or fuzzed out at 1x. The Y is not prominent enough. The whole point is the Y. It used to not look floating like this. It should be crisp and clear and that trademark shape.

"A" for effort and constant improvement and all that, but iteration required, I think.

A weird observation: At first, I didn't know how the "the Y is too fuzzy" problem (that I never had) could have been solved with a visibly much fuzzier replacement (shouldn't even say fuzzier, since the original was unfuzzy for me). Then I realized, I think it might have to do with solving the "fuzzy when zoomed" problem, without sufficiently regression testing the "do not degrade the non-zoomed look" checkbox. And, maybe SVG is good for large images, but not great for tiny ones (like this "Y" at 1x). Or something like that. I never zoom HN, so the fix does nothing for me, but I do notice the regression. I hope the feedback can be integrated somehow.

Thanks for the feedback! Ah and I also see you generated svg output that would be a bit shorter and more accurate.

I’ll try to collect all notes and follow up on them. Thanks for this!

I did a quick comparison at 1x and 10x in photoshop, using guides to compare the geometry: https://imgur.com/a/jWjtmtZ

The top of the "Y", at least optically, doesn't seem to extend as far in the PNG, and the intersection of the top legs seems to start higher in the SVG - it looks much higher in the 1x, IMO. I'm sure part of this is just the challenge/inherent mismatch of using a vector to "match" a lossy-compressed raster depiction of text.

That said I did this for fun and I don't imagine it will ever bother me - the sharpness is nice! Thank you!

Compare also vs. the favicon, which is much higher resolution, and still visible in the browser on the same screen as the SVG version: https://news.ycombinator.com/favicon.ico

Does the new icon need to match the old icon exactly? Was there something special about the arm length and angle?

I think the technical term is pixel f*cking. Personally, I could care less about a venture capital firm's brand identity, but I absolutely sympathize with wanting to make a technical improvement as seamless as possible, and respectful of its less technical content. Furthermore, there is a valuable art in doing so. Even something like the separation of view and model is beautiful in itself.

sorry im not a native english speaker, what does "f*cking" stand for

"Fucking", which in this context means, "messing about with".

Personally, one of the things I like best about this site is that in the ~15 years I've been here, its UI basically hasn't changed. It's refreshing in a digital world where most companies change their UIs and brand identity for seemingly no reason every few quarters. Keeping the appearance of "Y" identical is comforting.

Do you know Dang irl? Most suggestions for HN get ignored. This isn't a criticism, just an observation.

I don’t. I cold emailed him and absolutely didn’t expect a reply. This was also many many months ago.

Hey Greg,

Thanks for dropping in. It looks… unsettling! Like any UI change.

I am sure we will look back on the old page as it appeared someday and wonder how anyone tolerated such a thing.

My question is: how long was it bothering you before you emailed dang? How did you put it forward? Was it essentially an email version of a bug report?

As long as I’ve been surfing on a high resolution mobile device I think..! It might have been a few years ago.

I wrote an email which felt like throwing a bottle to the sea - this is/was a very non urgent issue. I described what was going on, included screenshots, and I did a prototype of an svg version which I also included.

As an active-ish member of this community, it felt nice to try to make it 0.000001% better ha :)

finally, new and improved upvote buttons for people with fat fingers like me

thank u

Sure, this question's probably pretty basic. Why draw it out with paths and all that instead of something like the following? Do SVG text elements not scale well?

    <svg>
      <text class="logo">Y</text>
    </svg>

Or even just <span class="logo">Y</span> with the style providing color and border.

And the arrows could be text too: 🞁 and 🞃.

Just curious about why even make them images, given the note that "everything else is text, and scaled perfectly!"

Unsure why, but the arrow examples you have there show up as unicode code blocks for me in Firefox on a Mac. Probably one of the reasons not to use them like that!

They don't seem to work in Firefox on Linux either (Ubuntu 20.04), seem to be Windows only for whatever reason.

The two arrows work perfectly here with Slackware 15 and Firefox 102.9.0esr.

They even work on the dinosaur age Firefox in Sailfish OS. I guess it's just whether the fonts used have the character or not, nothing to do with Firefox as such.

Probably, they don't show up on Firefox Android (Fennec on LineageOS 20)

Might be an Android thing. They don't show up in materialistic either, a native HN client.

The more commonly-used characters are ▲ and ▼, BLACK {UP/DOWN}-POINTING TRIANGLE (U+25B2, U+25BC).

Parent comment used much newer characters 🞁 and 🞃, BLACK {UP/DOWN}-POINTING ISOSCELES RIGHT TRIANGLE (U+1F781, U+1F783). These were added in Unicode 7, June 2014, where the others have been around for thirty years. I’m mildly surprised at lack of font support on macOS. For me they’re being rendered with Noto Sans Math, and completely wrong: they’re not being drawn as right-angled triangles at all (the angle is about 53° rather than 90°)! I’m guessing the commenter also had a bad font on them, because as a right angle it’d look all wrong for this purpose. (I’ve filed a bug report at https://github.com/notofonts/math/issues/47. Curiously, Noto Sans Symbols 2 also includes the character and gets its shape right, but Noto Sans Math is higher in the font fallback list (`fc-match sans-serif --all`: 881 lines, NotoSansMath-Regular.ttf is 52nd and NotoSansSymbols2-Regular.ttf is 89th.)

There are also ⯅ and ⯆, BLACK {UP/DOWN}-POINTING TRIANGLE CENTRED (U+2BC5, U+2BC6). And more, but of roughly-these-sized ones, these are the ones.

There are lots of triangles in Unicode.

Ah, yes, those are the right ones! I was looking at the wrong code block.

There are lots of triangles and also arrows, so commonness of font support would definitely be something to be careful of.

Mac doesn't support nearly 10 year old unicode standards?

Interesting, only the old triangles work for me on Firefox (Android 12). They all show correctly on Firefox in Windows 10

It's common to save the outline of text elements so that they don't have to ensure a certain font is present in the browser.

Yes, that makes sense. But then you still have the same issue with the rest of the text on the site (and it's a text heavy site).

It all appears to be Verdana, which has near 100% support across Windows and Mac.

https://www.cssfontstack.com/Verdana

I think the parent's solution (given the simple nature of the logo), is the best way to go.

Please leave some space between the upvote and downvote buttons. I often hit the wrong button with my big thumbs…

There is an "unvote" clickable link/button available if you tap the timestamp, though I agree HN isn't great UX on mobile.

I use it as a personal challenge. Growth mindset!

I seperated them by adding the following line to my uBO filters:

  news.ycombinator.com##.votearrow:style(margin-bottom:12px !important;)

I've also added the following lines to highlight comments that I've upvoted or downvoted to make it easier to see:

  news.ycombinator.com##a[id^="un"]:has-text(unvote):upward(4):style(border-left: 1ch solid green !important; padding-left: 1ch !important;)
  news.ycombinator.com##a[id^="un"]:has-text(undown):upward(4):style(border-left: 1ch dotted red !important; padding-left: 1ch !important;)

the whole point is to make it easier on mobile, not desktop!

Indeed, that's what I created those filters for. I run ubo on mobile.

Ahh, Android then, not iOS.

Or just add the text "upvote" and "downvote" where "unvote" or "undown" currently appear after voting (and maybe move "on: ..." to a new line in the individual post view). I've found the text navigation (root|parent|prev|next) to be excellent and the text upvote and downvote would fit in well.

They look great to me. Thanks for sprucing them up

Nice work!

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):

    <svg width="18" height="18" viewBox="-32 -32 64 64" 
        style="background: #f60; border: 1px white solid;">
        <rect x="-3" y="-2"  width="6" height="24" fill="white" id="rc1"/>
        <use href="#rc1" y="-22" transform="rotate(-34) scale(1, 1.2)" id="rc2"/>
        <use href="#rc2" transform="scale(-1,1)"/>
        <rect x="-30" y="-30" width="60" height="12" fill="#f60"/>
        </svg>

Cool! Here is a little smaller version of yours. Spaces and color abbreviation. That word “background” sure is big here.

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!

Is it really worth it? Is it?!?!

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.)

But is it an optimisation to send the SVG contents in every request, instead of just letter the browser cache the image?

Since the svg is not inline but rather loaded externally it is being cached aswell. (source https://stackoverflow.com/questions/37832422/how-can-we-cach...)

Yes, retrieval from disk caching is not as fast as one would expect. Detailed article: https://simonhearne.com/2020/network-faster-than-cache/

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)

When optimizing for lighthouse pagespeed metrics, yes.

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.

What does “ungolfed” mean?

It's a reference to "code golf", where you try to make your code as compact and the least number of bytes possible.

"Ungolfed" in this context means that it was cleaned up to make it more readable, at the expense of adding a few more bytes to the size.

And "code golf" got its name because better scores are a lower number of (key)strokes.

For completion: https://en.wikipedia.org/wiki/Kolmogorov_complexity

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

> unminified refers to a program doing that

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.

This one is based on yours, which is quite elegant, and the total payload is only 115B:

  <svg viewBox="-32-32 64 64">
   <path fill="#f60" d="m-31-31H31V31H-31z M0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/>
  </svg>

It assumes a white canvas, otherwise a background must be added at line 2

  <path fill="white" d="M-32-32 h64 v64 h-64 z"/>

Spaces can be deleted of course.

Is it intentionally a very bright orange to stand out from the background?

Might be inconsistent color space handling on your browser.

This is correct; it ended up being Noir darkening the topbar but not the SVG.

The downvote button always renders slightly larger for me than the upvote button. I suppose that's not intentional? 8)

Hmm, it's the same svg (https://news.ycombinator.com/triangle.svg) with the same votearrow CSS class on it; the down one just has an additional rotate180 class on it:

    .rotate180 {
      -webkit-transform: rotate(180deg);  /* Chrome and other webkit browsers */
      -moz-transform:    rotate(180deg);  /* FF */
      -o-transform:      rotate(180deg);  /* Opera */
      -ms-transform:     rotate(180deg);  /* IE9 */
      transform:         rotate(180deg);  /* W3C complaint browsers */
    
      /* IE8 and below */
      -ms-filter: "progid:DXImageTransform.Microsoft.Matrix(M11=-1, M12=0, M21=0, M22=-1, DX=0, DY=0, SizingMethod='auto expand')";
    }

on smaller screens (@media only screen and (min-width : 300px) and (max-width : 750px)) you additionally get:

    .votearrow { transform: scale(1.3,1.3); margin-right: 6px; }
    .votearrow.rotate180 {
          -webkit-transform: rotate(180deg) scale(1.3,1.3);  /* Chrome and other webkit browsers */
          -moz-transform:    rotate(180deg) scale(1.3,1.3);  /* FF */
          -o-transform:      rotate(180deg) scale(1.3,1.3);  /* Opera */
          -ms-transform:     rotate(180deg) scale(1.3,1.3);  /* IE9 */
          transform:         rotate(180deg) scale(1.3,1.3);  /* W3C complaint browsers */
    }

same scale, though

Rasterization can still lead to different sizes due to rounding, if the edge (or the rotation point) just happens to coincide with the raster edge between pixels (or something like that). You can't just rely on the shape being the same mathematically, you have to take quantization effects into account. Using dedicated shapes instead of the transform may also be more reliable.

> Uh... AMA? Suggestions? Thoughts?

Now that the Y is SVG rather than being an image, it shouldn't be too tricky to adjust the background color from orange to whatever the user has set for their topbar? I use blue for the topbar, and it kind of annoys me that the logo stays orange.

Heck, my instinct tells me that if we're lucky a transparent background would do the job without needing to make the SVG dynamically defined.

Edit: I see you're drawing the background color over the Y to give it flat tops. That makes the transparent background difficult. But I'd still like it if the background color was taken from the user's topcolor instead of always being orange.

I made my top bar the same as the page color, so that might make the logo basically invisible for me or others with a brighter color defined.

How are you changing it? I don't see an option anywhere...?

Go to your profile page (by clicking on your name at the right of the topbar).

You should see a field labeled `topcolor`. You can set the color of the topbar through that.

On your user page. It may require some karma? I like it as it tells me whether I'm logged in, and if I had multiple accounts they would be easy to differentiate.

I hated the pixelated up/down buttons. Thank you for the vectors!

Nice update. Btw. UX-wise on mobile the upvote / downvote arrows are so close together that you have to pinch-zoom first to be able to select the right one with your finger. A real improvement would be to add some extra spacing between them.. somehow, without spoiling visual appearance.

> I built two micro tools to help nail it down if anyone is curious (aka make it visually seamless)

Huh I would have thought they'd have some sort of document somewhere that gives clear dimensions and angles of the logo. Did someone just draw that freehand in Photoshop, saved it to png and then that was that?

I mean, when you first build something like this and you have no idea whether it will die in 6 months or live the next 20 years, do you really want to bother with the logo's format?

Nice, and thanks.

I'll say as someone who began on HN feeling contrarian and somewhat underepresented in viewpoint that dang is exceptionally responsive to all manner of suggestions. Not all have been implemented, though a few I've suggested have been picked up. Collapsable comments being one that comes to mind.

Hacking on HN itself can be fun. (I've got a few CSS tweaks linked from my profile page, so far no take-up, though I much prefer how the site looks using them.) That includes a dark mode, which though I don't usually use it, testing just now ... it's not bad if I may say so myself.

Your SVG tweak reminds me that it's possible to do such things in CSS (inline data attributes) as well.

A bolder reinterpretation of your "Y" adding rotational symmetry.

  <svg viewBox="0 0 64 64">
   <path d="m1 1v62h62v-62z" fill="#f60" stroke="#fff" stroke-width="1"/>
   <path id="|" d="m32 28v28" stroke="#fff" stroke-width="8"/>
   <use transform="rotate(120 32 28)" xlink:href="#|"/>
   <use transform="rotate(240 32 28)" xlink:href="#|"/>
  </svg>

I noticed this when the logo was missing (I have SVG disabled in the browser for security reasons). upvote/downvote buttons are totally invisible to me now as well and unlike the logo in the corner they don't show up as broken, just missing (although they can still be clicked on)

I don't expect many people will have these issues, I know I'm running in a very locked down environment that most people wouldn't want to put up with, and it shouldn't be very hard for me to fix this with a little custom css, I just thought I'd give the feedback since I was impacted and I do try to encourage sites to fail gracefully.

I find it funny that everyone is bikeshedding the symmetry of the "arms" and the length of the "leg" on the logo in an attempt to be pixel-perfect with the original low-res image.

While it's fine and funny to be doing so - I can't help but realize how little any of this matters. Imagine an alternate reality where the icon was changed for SVG and not announced. There might be 2 people max that complain about it for a day, and then it would blow over and be the new normal.

Also imagine if a whole stylistic remake of the website was done - I doubt anyone would notice if the icon was ever so slightly different.

Reminds me of memes about how a 10 line PR gets 10 comments, but a 1,000 line PR gets an "LGTM"

Here it is, in its full glory!

    <?xml version="1.0" encoding="utf-8"?>
    <svg viewBox="0 0 100 100" width="100" height="100" xmlns="http://www.w3.org/2000/svg">
      <rect x="0" y="0" width="100" height="100" fill="rgb(255, 102, 0)"></rect>
      <path d="M 50 77 L 50 50 " fill="none" stroke="rgb(255, 255, 255)" stroke-width="8.78662150719729" stroke-linecap="butt">
      </path>
      <path d="M 94.93056731583404 35.622745513916016 L 71.2454833984375 71.2454833984375 " fill="none" stroke="rgb(255, 255, 255)" stroke-width="8.78662150719729" stroke-linecap="butt" transform="matrix(1 0 0 1 -21.2455 -21.2455)">
      </path>
      <path d="M -78.93056731583404 36.17028045654297 L -55.67118835449219 71.79300689697266 " fill="none" stroke="rgb(255, 255, 255)" stroke-width="8.78662150719729" stroke-linecap="butt" transform="matrix(1 0 0 1 105.396 -21.7213)">
      </path>
      <rect transform="" width="100" height="23.742591024555463" stroke-width="1" stroke="none" fill="#FF6600" stroke-opacity="1" fill-opacity="1" stroke-linecap="butt" stroke-linejoin="miter" >
      </rect>
    </svg>

so many butts!

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>

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.

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!

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:

    <svg width="100" height="100" viewBox="0 0 100 100" fill="none" xmlns="http://www.w3.org/2000/svg">
        <rect width="100" height="100" fill="#FF6600"/>
        <path fill-rule="evenodd" clip-rule="evenodd" d="M62.1762 23.7426H72.6857L54.3948 51.6515V76.9391H45.6048V51.6554L27.3143 23.7426H37.8233L49.9988 42.3233L62.1762 23.7426Z" fill="white"/>
    </svg>

Perhaps the asymmetry is there to subtly evoke a dip and recovery of a company's stock price. The subtext could be "we build resilient companies".

Imperfections in vector images make me twitch

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.

Why use such un-round numbers though?

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.

[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)

Excellent.

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 thought I was the only one

HN on mobile is a usability nightmare.

I would make the fold-a-post-button a bit bigger and with more space to the left. The rest seems clickable to me.

How's your vision, hand-eye-coordination, and fine motor control?

The accidental Hide is the worst because you can’t just undo… it’s gone (unless you go to the Hidden page)!

A long-press for flagging/hiding would be great (or even a confirmation-screen).

My weekly accidental “flag” scares me the most. What if I don’t notice it?!

https://news.ycombinator.com/flagged?id=Waterluvian

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.

Or accidentally logging out when you wanted to click on your profile to see if your comments had any responses / votes.

Why not click on "threads" in the top bar?

TIL... :-) Thanks...

Doesn't help for viewing your submissions.

Commenting from Materialistic on Android, it's a great app ime.

I use Octal on iOS. Highly recommended.

Shameless plug: You can improve the mobile view a bit using this userscript (works on Firefox Mobile + Tampermonkey):

https://gist.github.com/selcuk/00948de9717b25d0d5e824c3e80da...

Going to take a while getting used to, but thanks.

If you are running Firefox then you can add the following uBO rules to help: https://news.ycombinator.com/item?id=35899184

The proportions have changed. Compare e.g.: https://news.ycombinator.com/favicon.ico

EDIT: since we're code golfing/bikeshedding, here's my own attempt, which matches the original proportions [1].

    <?xml version="1.0"?>
    <svg xmlns="http://www.w3.org/2000/svg" width="18" height="18" viewBox="0 0 192 192">
      <rect x="4" y="4" width="188" height="188" fill="#f60" stroke="#fff" stroke-width="8"/>
      <path d="m 57,47 h 15 l 24,50 24,-50 h 15 L 102,109 v 40 H 90 v -40 z" fill="#fff"/>
    </svg>

[1] Actually, the original is slightly asymmetric -- the right leg is slightly narrower. I've "corrected" this, making the right leg mirror the left.

Golfing SVG happens to be one of my passions. Your path definition can be further reduced to

    m57 47h15l24 50 24-50h15l-33 62v40h-12v-40z

Wow, let's not get carried away with crazy new technologies and radical redesigns.

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.

Sure, and I do that too. This is for navigating within the page though, and no I'm not going to open a new tab per comment I want to read.

Now we just need the little up and down arrows to go SVG and HN can look crisp at any resolution.

Well, have I got some news for you!

https://news.ycombinator.com/triangle.svg

...and it's already implemented! I thought this day would never come.

And the down arrow is using the same SVG with a `transform: rotate(180deg)` too!

Truly incredible developments.

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.

If it's just a background-image, why not just build the triangle in CSS? Saves a network request (and a whopping 525 bytes)

I just want them bigger on mobile.

Why work so hard?

  ▲  U+25B2  BLACK UP-POINTING TRIANGLE
  ▼  U+25BC  BLACK DOWN-POINTING TRIANGLE

[0] https://en.wikipedia.org/wiki/Geometric_Shapes_(Unicode_bloc...

At least for me those are different sizes.

Same here, something funky going on with unicode triangles?

Which browser? So far, everything seems fine in Firefox, Chromium, and Nyxt, which uses WebKit.

Safari and Chrome

Looks fine on Edge/Windows too.

Safari 14

I feel like this unicode approach may be a better fit for how the rest of Hacker News is constructed (e.g. the use of the pipe character).

267 bytes vs 1026 :)

I mean really you should measure it after gzip/brotilli since that is the size that matters.

You're right - still smaller but now 199 vs 448 bytes.

Wonder if it can be made any smaller?

    <div style=“background-color:orange;color:white;border:1px solid white”>Y</div>

Disclaimer: from memory and tongue in cheek. May not work!

It matters client-side in RAM. ;)

For anyone who wants to see the logo in action, I'd like to recommend checking out the SVG Playground link. It's a great tool for exploring and manipulating SVG code, and it makes it easy to see how the logo looks on different backgrounds and at different sizes.

https://svgplayground.com/#encodedsvg=PHN2ZyB3aWR0aD0iMTAwIi...

What framework does this use and how can I turn it into monthly revenue?

Can we have valid[0] HTML5 with semantic HTML instead of table layouts next?

[0] https://validator.w3.org/nu/?doc=https%3A%2F%2Fnews.ycombina...

On the other hand, my friend was showing me his Facebook page, and I noticed the Facebook logo is heavily pixelated on his 4K monitor.

How SVG is still not the default for site logos is beyond me.

Launching a pixel-based competitor for people that like HN the way it used to be, like and subscribe for more important announcements

Glad to see technology is finally here for it

Mostly just amused that this gets 50+ comments

People pushing xml in 2023 is news and highly relevant.

Can we get a yaml or json based image format or maybe some rust based web assembly to get on with the times?

I prefer using table cells for pixels. I saw a script once that took an image as input and output html code to send those who had pictures blocked...

The wider angle of the open "arms" of the Y is noticeable to me. The character of the logo is lost in the new design, imo.

Also, the top of the border line of the icon is not aligned with the "Hacker News" on mobile. It displays similarly to the desktop page zoomed in at 250%.

I have noticed this a little when using the site from across the room while very zoomed in. I like to check HN sometimes while I am on the couch in between episodes of shows. Sometimes I simply read a bit and sometimes I have Speechify read articles to me in the voice of Snoop Dogg.

Does it look right?

It's a relief, especially the arrows.

Arrows look sharp but the Y is not bold enough to look much different than a plain orange square now.

White square border looks good though.

1920 x 1080 on Firefox, plain orange square even more so on the browser tabs.

> 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.

Oh, bravo! Hacker News now has its very own shiny favicon. How avant-garde! Who knew we were so desperate to keep up with the Kardashians of the digital world? But hey, it's just a favicon, right? Nothing to get all hot and bothered about. Except that it's not just about the favicon, it's about the principle of the thing!

Remember when Hacker News was the final fortress of the internet where content was king, and design was as minimalistic as the wardrobe of a monastic hermit? A place where intellectuals could congregate without being assaulted by the visual diarrhea that characterizes every other website on the planet. Those were the days when it was the text that mattered, not the tiny, shiny icons. But alas, those days are as dead as dial-up!

Once you start prioritizing style over substance, it's a downhill race on a greased slide. Today, it's just an innocuous favicon. But who's to say tomorrow we won't be suffering through animated logos, retina-burning background images, and God knows what other visual atrocities? Before we know it, we'll be swimming in a sea of unnecessary UI elements, auto-playing videos that nobody asked for, and a homepage that's more ad than actual content.

And they say progress is a good thing...

reminds me of http://n-gate.com/hackernews/

You certainly raise some valid points about the evolution of Hacker News, and indeed many other digital spaces. Minimalism and content-focus have traditionally been valued in certain corners of the internet. For these spaces, adding a favicon or any other aesthetic elements can be perceived as a step away from these principles.

However, it's important to remember that design and aesthetics are also a part of the user experience, and can contribute to usability and accessibility. A favicon, for instance, can make it easier to distinguish between tabs in a browser, improving navigation and efficiency. While it's true that overdoing it with design elements can lead to clutter and distract from the content, there is a balance to be struck.

Your concerns about this being a slippery slope towards a more ad-heavy, visually cluttered site are understandable. However, it's also possible that the addition of a favicon is merely a small design tweak to improve usability, rather than a sign of a larger shift in priorities.

Ultimately, it's crucial that the community voices these concerns and helps steer the direction of the platform. After all, it's the users who make a platform like Hacker News what it is, and their input should be valued and considered.

I zoom this site at 200% for my old eyes and the old logo was very blurry. Finally everything is sharp, so I like it.

Any reason it isn't just a text Y with a CSS border around it? Is this for Y Combinator branding reasons?

Dark mode too please?

The “Dark Reader” browser extension works fine for most websites, including HN.

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.

Looks like the colors are SVG fill properties, that could be refactored to be controlled with CSS instead and swap on readers using dark mode

In Firefox on my iPhone XR, the logo looks too small in portrait mode. It’s being dwarfed by the title and rows of text. Switching to landscape mode looks better because the logo takes up the entire height of the top bar.

Glad to see it, but it probably could have just been a "Y" and some CSS too

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.

SVG doesn't change the way positioned text does.

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.

Weird, I didn't notice that at all, but comparing the current look to one from February [0], yeah, it's changed.

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...

Vote buttons look different too (on mobile at least)? Slightly darker & bigger?

Is this really an improvement? The logo is tiny enough that I'm guessing we are better off keeping the old logo as it may use fewer resources (not that this page is slow, unlike most of the web today).

Anybody knows about a svg renderer written in plain and simple C?

printf(3)

Upvote/downvote buttons were converted to SVG recently too?

    date: Thu, 11 May 2023 01:32:07 GMT
    last-modified: Wed, 10 May 2023 21:41:52 GMT

A day old. You were quick to notice, wow.

I had CSS tweaks that were anchored to the YC logo (to identify the topbar), so they broke when its URL changed!

I always assumed it was created with html/css. After all it is just a capitol Y.

``` <a class="logo" href="https://news.ycombinator.com">Y<span class="sr">combinator Logo</span></a> ``` ``` .logo { display: block; width: 18px; background: #ff6601; border: 1px solid white; color: white; text-align: center; ```

I love that this has more upvotes than things like, Google releasing full 3d models of the earth for public access.

Why on Earth didn't you just inline it?

So that it gets cached by the browser?

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.

The day has finally come. Thank you YC.

Quite funny to see a major website adopt tech I was playing with almost 20 years ago.

Nearly 15 years late is better than never. Congrats on the upgrade :)

did anyone else visually notice it? i feel like i could tell something was different recently but couldnt tell for sure

Move slow and keep things as usual.

The site feels way faster now!

i was surprised to notice a few weeks ago that links2 has svg support now

Save on that bw cost!

The designer who did this had to invest really so much time... :-)

Great. Now fix the light gray on white

why we do like svg?

zoom in without image aliasing?

sweet!

Wow, amazing. It's a shame I can't downvote this post.

Good. Now HN just needs to add video embedding, limitless scrolling and social media sharing.

Don't even joke about those things!

Don't forget the promise of running on Helion(tm) fusion power!

Don't forget GIF replies. That's what makes Twitter such a swell place, everyone is just so hilarious.

But we could have <blink> on some important text to be truely different...

We just got rid of a Gif - let's jump straight to SVG replies!

Well they did just add some JS scrolling crap. Come on HN I thought you were better than that.

The Chromium "force dark mode" feature (at least from Opera) turns the Y logo into a darker shade of orange now. Any chance this could be fixed?

...I mean, if the browser is purposefully changing the styling of the website to something not provided, that seems like the browser's problem.

Off topic for this post. This may sound snarky, but I’m saying in all seriousness. HN needs more people to volunteer their time and effort for free to improve its UX, which has been terrible on mobile/tablets, really bad for accessibility, and so on. All this while retaining the core of HN’s simplicity on any web browser (without extensions or HN specific apps). I’ve been waiting for years to see some change, but now this logo change gives me hope.

maybe a bookmarklet that loads some css? I would be interested in collaborating on this

or were you thinking about having dang actually implement changes to the site natively

That's already happened, the forum UI is atrocious, but the Hack mobile app is one of the best forum reading app out there, so it's not a matter of more people volunteering time, it's about HN not willing to implement any improvements

Use materialistic

Thank you! I don't care for logos personally, if you'd like to hide it on HN add this to your userstyle:

    a[href='https://news.ycombinator.com'] img,
        display: none !important;
    }

These can be managed with a plugin like Stylish.

Reply on news.ycombinator.com