Every so often the site gets updated with a 5px black element above the header. I'm assuming because someone died. The site is currently in this state (Jan 19, 2024, ~6pm PT)
Can you make that a link to the post announcing the death?
You're not wrong that seeing a local tradition play out that you don't feel part of can feel unwelcoming sometimes, like not being on the inside of an inside joke. But that's not the same as gatekeeping, and I need carry no brief for HN to say I really don't recall seeing that around this, at least.
It's a tradition of mourning that does no one any harm. I hope there should be charity enough to spare for that in almost any heart.
As bmicraft said, I was calling out the use of the phrase "actual HNer" as being exclusionary, elitist, and toxic (harsh? Yes, intentionally so). Explaining the bar or posting a link to a relevant story or even just saying that it's a mourning band for someone impactful to the HN culture or history has passed away would have been a better approach than saying what amounts to "if you have to ask, then you don't deserve to know."
There are many things I don't love about HN. Obituary threads here are none of them. If this place has a heart, I think that's where you can see a lot of it, and Google's already got you covered anyway for Wikipedia and AP.
I would like to see this, and I would like the link text to always be the name of the person so honored, and nothing else. Horizontally centered, for preference, because nothing else nearby is.
These are names that should be known. If someone learn nothing else from a tradition here of doing them honor, then let him at least learn the names themselves. Everything else can follow from that, or I think would be wasted anyway.
I totally agree with this. It doesn't make any sense to honor someone without knowing who that person is or to know people are in mourning without knowing what they are mourning about. Usually, you can tell who it is because the story is trending on here. In this case, the black bar was put up a bit late, and the story isn't on the front page anymore.
Tooltips (hover text) are actually the title attribute, not the alt attribute, and they definitely do work on mobile. Head over to xkcd and long press on an image. I think it works not only for <img> but also <a> elements.
I think such ""user friendly"" features are alien to HN's attitude. You can find out with very little effort. Ask it even! And then write and publicise a userscript that does the above.
I don't think this is needed as it's very obvious who it's dedicated to.
If you don't know about the event, then all you need to do is to literally just go through the first two pages (probably just as you would when you're visiting the site which is why you cam in the first place) and you will see it mentioned.
I personally don't think there's a need for this as this is not Reddit and the average user should be able to figure this out on their own.
>Why disparage a useful feature by saying people should just settle for an inconvenient solution and search pages of HN titles?
The reason being that I'm against oversimplification and I believe it dumbs the community down. The beauty of HN for me is how primitive and free from clutter it is so that I can focus on the content.
>This is a news site. Why would you expect the people arriving to already know the news they came to learn?
I'm not, you can simply find the answer by going through the first few pages, I just don't believe an effort needs to be made to make it easier than that.
This is the same train of thought as saying we shouldn’t use debuggers because programmers will get lazy and stop thinking through the code, or that we shouldn’t have any programming layers higher than assembly because they’re less efficient and everyone should just write everything in assembly.
Keeping something more difficult just for the sake of “smarter people” will never be a compelling argument to me. Consider those same smart people could be doing something meaningfully challenging in the new time they’ve saved by having a brute force problem automated.
This is obviously not as time consuming, but the criticism is not based on an effective ideology.
i did exactly as you suggested and could not find a death announcement in the first couple of pages after seeing the black bar. I was unable to discover who died.
I love the simplicity of hn. Giving us a way to know who the black bar is for is not some scope creep that will slow down the site nor visually clutter it.
That's currently false - no mention is on the 1st 2 pages. So another suggestion: keep the death news on the front page for as long as the black bar is up.
Otherwise the bar becomes a kind of unfriendly cryptic ingroup signal – "sheesh, don't you already know?".
Semi-related (and hopefully if a link is added to the border, this could be implemented as well): some of us hate light mode so much that we set our browsers to force dark mode everywhere. However, in my experience, this makes the black bar nearly invisible. I'm not sure how this would be best handled, but is there any way that the black bar could be made more visible for dark mode users?
a different, related idea could be a hidden page (like https://news.ycombinator.com/highlights ) that lists all the people that have been honored with a black bar.
the black bar could link to that page, or it could remain hidden
That's like saying it's wrong to flank some plain text with underscores or asterisks if the UI is not parsing that into rich text; actually the parsing isn't necessary for successful conveyance of emphasis (and the convention predates such parsing). By analogy, parsing of the @username syntax into a ping isn't necessary for successful conveyance that the word is a username (although I'm not sure the convention predates parsing in this case).
Just as seeing underscores/asterisks is understood as "the author is emphasizing despite lack of formatting," seeing a leading at sign is understood as "the author is saying 'this word is a username' despite lack of ping."
Perhaps if someone emailed him to let him know this post existed, using the footer contact link to do so, then yes! But @dang doesn’t attract his (or anyone’s) attention on HN.
Same with Outlook, now when you @-someone it highlights them and even adds their address "To".
Just because HN doesn't currently support this syntax, doesn't mean we must not use it. As with the other examples, if enough people do it, I wouldn't be surprised if support is added later.
Thankfully, my username is pretty unique (like yours), and I can easily search for references to me, but if my name was a common word it would be really frustrating trying to weed out references to me, compared to where people are actually referencing me.
I don’t expect support to ever be added by HN actual. Some third-party may code it into search, but HN isn’t designed to be used as a “send a notification” platform in any regard. Expanding to support @username pings would be a serious undertaking and contradict the site’s minimalism and simplicity.
People have been reinventing this syntax here for a long time. It has remained useless here for a long time. There is no groundswell of rebellion opportunity. You’ll just have to send an email.
I bet you see this response, which demonstrates that it is a sort of engagement platform.
Same as in you profile you can view your own comments (and others) , scanning the message for an @ symbol and checking for a valid username I wouldn't consider to be a major undertaking.
As I said in my comment, searching for @username vs username is much easier already.
But yes, a third party could do it. Perhaps @dangrossman (yes, I did that) may be interested.
making a 5px black bar clickable or hover-able might be hard or not super discoverable. but maybe link the Y image to the HN link that's usually at the top of the page, accompanying the black bar. in this case, https://news.ycombinator.com/item?id=39051246
Technically it's very easy to add the black bar as it's already added manually and all that would be needed is to add a "data-id=" which would contain the news ID and a regular "id" to the black bar's "<td>" and once clicked it would send you to "https://news.ycombinator.com/item?id=[DATA-ID]" (perhaps also add "cursor: pointer" to the CSS as well to change the cursor when its hovered).
Again, this is trivial and can be done with minimal work, but it should not be needed at all.
Unfortunately, the answer to your question is very likely "No." There are a few subtle reasons why this is the case, and I'm going to attempt to explain them. I've seen this situation many times, and the outcome is almost always "HN doesn't change." This isn't due to laziness; adding the feature is two lines of Arc. The reason is social.
Social software is hard. In fact, it's one of the hardest types of software ever to be built. Things that might seem like small conveniences or improvements often have counterintuitive effects. These effects are not readily understood by people who aren't running the site, because only the people running the site can see them in detail.
For example, suppose we were to implement the black bar link. Firstly, this means that the black bar now becomes a "superslot", pinned at the very top of HN. It turns what was otherwise a subtle gesture into a feature. It will inevitably raise questions about whether the black bar is really warranted for so-and-so, or whether it's fair that they get the superslot. But criticisms like that can be ignored.
The bigger problem is one that Dan has pointed out many times: it's good to have readers dig a little for information. Only people who are motivated will end up showing up in the thread. And those are exactly the kinds of people who you want showing up in that thread, because the point is to honor whomever died, not to catapult the entire community (and then some) at the thread. After all, every single person who ever visits HN will immediately click the black bar if it was clickable. Are you sure this is the kind of effect that would be a Good Thing?
Then there is the truth that doing nothing leads to the optimal outcome. Suppose the black bar was changed, and it was a mistake. This mistake costs time, because now the moderator has to deal with the consequences. It's not just a matter of reverting the change; when stuff like that gets reverted, people get curious why. So it'd be natural to have to write an explanation, which ends up sparking discussion about very tricky subjects. Again, community software is hard, and explaining subtle reasons for doing X is a delicate process. All of this translates to the potential of wasting some unknown quantity of time; time you won't get back, and time that you won't be doing your duties of running HN.
Then there's the most subtle point: it would break tradition. pg was the originator of the black bar, along with the christmas colors. It might seem cheesy to people who haven't been here since 2006, but there's something magical about seeing HN behave exactly as it was originally written, even when that behavior is sometimes arguably less optimal than it otherwise could be. Because, again, every change has social effects, and these are very hard to predict.
Lastly, the person who died might not want all of the attention. Are you sure you really want to be spotlighted by the entire (tech) world when you pass? It wasn't till I had some uncomfortable moments in the spotlight that I realized that fame is sometimes something that people choose to avoid.
For all of those reasons and then some, the black bar is likely going to stay as it is. If only as a hat tip to the person who originally created the tradition.
I can understand remaining minimal, and not shuttling lookie-loos to an active thread.
But remaining mysterious kinda works against the "memorial" aspect, and making the editorial decision "this passing is worth noting". It creates an "in-the-know"/"not-in-the-know" division that's somewhat against the ethos of being fair & open with those who don't yet know something.
A simple, "RIP, [name] [YYYY]-[YYYY]" would be a kindness to readers, and enhance the respect paid the deceased, while avoiding the thread clickthroughs you're concerned about.
And otherwise, we'll keep having these threads every time the honoree's identity is sufficiently obscure, and any associated stories/remembrances scroll off the front page.
One (rather cold) way of viewing the situation is that if they spend their time adding this feature, it's at the expense of something else they could be doing. There are technical reasons it's not quite as straightforward as just setting a title attribute.
They uncomment that line of code by removing the semicolon, then deploy it. ("Deploy" is also known as "copy-pasting that function into a REPL," but devs like to overcomplicate it in other languages.)
If it were as simple as writing "Dave Mills [YYYY]-[YYYY]", they might actually do that. But Arc doesn't have keyword arguments, and tdcolor has no way of passing along a "title:" keyword in order to set the html attribute.
It's partly why I updated Arc with keyword arguments.
But, there's still that other aspect: figuring out [YYYY]-[YYYY] takes some amount of time, so it increases the activation energy of the black bar considerably. Right now it's a one-character deletion followed by a deploy. Honoring legendary hackers is a good thing, but the black bar already does that.
I understand tradeoffs & 'technical reasons'. But, a web framework that makes specifying tiny useful HTML edits noticeably harder in code than similar changes would be in plain-text strikes me as defective. That's especially true for a broadly-useful 'global attribute' – supported on all HTML elements – like TITLE.
Looking at the precedents in code near what you've linked, for how possibly-arbitrary STYLE and CLASS and COLSPAN and CELLPADDING and WIDTH attributes are set, it's hard to see why it shouldn't be as easy as something like:
; (tr (td bgcolor black vspace 5 title "RIP Name (YYYY-YYYY)"))
Of course, it might not yet be that easy.
But if that's hard to support, with a couple low-risk broadly-beneficial lines elsewhere, then rumors of Arc's concise expressive power seem exaggerated.
You could literally just remove the s.gif (assuming s stands for "spacer" which is a very very old school web development technique) since the text would give implicit height anyways.
