chrismorgan

From the code, it looks like it’s only broken if you have a browser more than about two and a half years old, JavaScript disabled, or fonts disabled. Even on HN, I would expect that to be under 5% of viewers, surely under 10%, and people that turn off JS are used to the occasional page not working (though it’s happily less common than it was five years ago).

That message is triggered by checking for support of the CSS light-dark() function and :has() selector:

  window.CSS&&CSS.supports&&CSS.supports('color','light-dark(#000, #fff)')&&CSS.supports('selector(:has(a))')

Are you sure your browser is fully functional and updated? Chromium shipped the last part of that incantation two and a half years ago.

The only reason I commented this was because the specific breakage was novel. And it’s rare for this specific type of comment to rank highly. Apparently this one is unusually interesting to others, or something? Beats me.

It’s currently at +39. I did not expect that! I expected it to settle at the bottom like something that settles at the bottom—I dunno, detritus, lees, Titanic, something like that.

Still, I’ll take the opportunity to advocate for turning off fonts. Firefox: Settings → Fonts → Advanced settings → Allow pages to choose their own fonts, instead of your selections above. I’ve been using the web so for 6½ years and it makes it so much better.

This website has the distinction of being the first basically-just-content website I have ever encountered to break when web fonts are blocked (or otherwise fail to load).

Other than the weird 5×5 colourful tile image thing near the top, all the content is in the document, but they go out of their way to break it in various baffling ways: ① if JS is disabled, it hides all the content behind a “Please enable JavaScript to view this website” screen; ② if fonts fail to load (fonts? fonts!?) it hides all the content behind a “Fonts didn't load. Reload the website.” screen; ③ even if you get it all, keyboard navigation (Up/Down/PageUp/PageDown/Space/Shift+Space) is broken because they went out of their way to not use the perfectly good document scroll area and make their own fixed-positioned one within, and they didn’t even make that focusable, so pressing Tab to get the focus inside it will in some browsers jump you halfway down the page.

(I would not have commented any of this were it not for its first-time status.)

Key UP!

(I confess I’m getting frustrated at the ridiculously large fraction of messages in this thread that have somehow completely misunderstood things.)

Under Linux, Firefox, Chromium and GNOME Web (which is WebKit-based; a.k.a. Epiphany) all have Tab cancel but not Esc.

The GTK 4 behaviour feels very much like a bug. I can reproduce it in gtk4-demo and in gtk3-demo. It leads to obviously-nonsensical behaviour, including messed up window focus. I’m tempted to file a bug report, but haven’t had such productive experiences with filing things on GNOME historically as with Firefox or even Chromium.

Why should Enter being a different key be a different discussion? They’re both used to activate buttons, and one is behaving like every single other keyboard interaction, while the other isn’t. (Related: if a link is focused, Enter activates it, Space doesn’t, just doing the normal scroll-down-one-page.)

The keypress event is an ancient mistake that I think never had any legitimate use case, and has been deprecated for quite some time now.

Maybe a decade ago, I decided to start a theme from scratch, named bland. Initially, it was just black on white, with keywords bold, comments, macro invocations and lifetime tokens (this was all focusing on Rust) italic, and escape sequences bold italic. I decided to wait a week before deciding if I would add any colours at all. As expected, after that week I made strings red, comments green and numbers blue. Since then, I’ve made number type suffixes light blue, macro-related things orange, and delimiters grey (I should try dropping that one again). But things like making type, async, function*, for, const, of, &c. different? No, they’re all just bold black, no need to try distinguishing between them.

I also subsequently made a dark variant of it for my website’s dark mode and for occasions I want to use an editor in a dark place.

The colours involved are all high-contrast, using the RGB channels provided rather than trying to be silly with low contrast: #fff, #000, #c00, #090, #00c to begin with.

But I have no particular interest in publishing this in a form others can consume in whatever editors they use. Plenty of small tweaks that I develop over time, half for my own Vim syntax files. I think the approach itself, of experimenting deliberately yourself, is worthwhile.

If only one case follows your rule, and everything else ever implemented from the start of personal computers is an exception, your rule is awry.

I am speaking specifically of keyboards. For mice, it’s release. (When I made a similar comment two months ago on Lobsters when this article came up there, I mentioned this, but decided to leave it out this time, thinking the context was clear enough. I think I was wrong.)

Give me an example. Any example beyond this Space one we’re discussing; because I don’t know of any.

(Esc while Space is held doesn’t cancel, but Tab does.)

You’re only answering half of the inconsistency: because Enter activates buttons like any other key, on keydown.

I’d just like to hear an explanation of why it is. Because if you handled “is key currently pressed” events with polling rather than events (which is how people almost always consume them logically), it would be the only thing in the entire world that I can think of that would/should use keyup.

Edit: I think people are misunderstanding me. I’m asking for an explanation of why, when you have a button focused, pressing Space activates on key up, rather than key down like literally everything else on the keyboard, including Enter on a focused button. (Mouse activates on release.)

Using keyup makes no sense and is inconsistent with user expectations. For triggering actions (which includes normal typing), you only ever use keydown. (Well, there’s one exception for reasons unclear to me: activating a button by pressing Space. That triggers on keyup like how clicks are on release, while Enter triggers on keydown.) Keyup is limited to things where you’re constantly reacting to the state of a key, as is common in games.

This affects the functionality, too. It is in fact introducing latency by using keyup instead of keydown. Feels bad.

Looks like this is Italy-only.

I’m pretty sure (though I have no record of it) that I asked ASUS Australia through their online channels before I bought my current laptop six years ago, and they said no. I never tried following it up more closely. In truth at that stage I didn’t mind having a Windows license, it was convenient for testing certain things occasionally. But I haven’t booted into it for at least three years now other than a couple of times to verify that the keyboard problems are hardware, not software.

The example shown at the top is really bad.

“Before (Without the delay of 200ms)” shows obvious delay in appearance. I think this is because of the very inappropriate fade-in.

“After (With the delay of 200ms & instant tooltips)” doesn’t show the instant behaviour at all, only one tooltip.

The question then will be whether you are willing to be exposed to the toxic waste.

Under the law of Moses, if your bull gored someone, you were not responsible; but if it was known to be a gorer, you were responsible if you didn’t ensure it couldn’t gore someone.

I don’t know exact parallels in current law, but I presume there will be things like that.

The OpenAI/Hugging Face case sounded rather like OpenAI building a fence around their bull that was known to be a gorer, and then thumbing their nose at it and saying “nyaa! bet you can’t break the fence!” and walking away while listening to loud music.

In Australia, if you have a fire and leave it unattended and it escapes, it’s your fault, you were supposed to keep watching as long as it was burning.

Yeah, that was the first one my eyes went to. The only scenarios I can think of where it is acceptable to hide scrollbars are infinite canvases where you’ll draw your own non-linear ones (and even then be disappointed because they can’t look or behave natively), and things like maps where you remap scrolling to zoom and might want to use a backing invisible scroll area for that rather than consuming scroll events (which are somewhat more limited).

In short: unless the native scroll bar will be wrong, do not under any circumstances hide it.

Completely seriously, and I don’t think this is particularly controversial: outperforming React is not impressive. React was never particularly good at performance—VDOM is fundamentally overhead, and there are a variety of faster and lighter techniques employed by various competitors, and even among VDOM libraries it’s not as fast as it could be. React sold itself as fast initially, but what it was faster than (rebuilding the entire DOM on any update) was a strawman.

It’s not hard to be faster than React while exposing broadly similar functionality. If you’re making something for your own usage only, it’s even easier to beat it.

Consider https://en.wikipedia.org/wiki/Superior_orders (the Nuremberg defence, “we were only following orders”).

Of those that have banned it outright, I think I have seen at least as many say it’s about maintainability and social reasons as legal.

Most large open-source projects banning AI contributions have been doing it for social and technical reasons, not legal.

As for the copyright infringement angle, it’s well and truly too late for that to be a meaningful problem, socially and politically. It’s easily in “too big to fail” territory now—any striking down of the “fair use” exemption claim would kill the entire industry dead, because every one of them would have to throw away all their models and synthetic data and start again, and that’s geopolitically untenable. They moved too fast for judiciary to regulate them, and I think the window of opportunity for legislature to regulate them closed no later than 2024.

> There are no '0 search results' anywhere.. each search yields thousands of results.

I’ve encountered “no results” on DuckDuckGo at least half a dozen times in the last couple of months when I know there should be relevant results, and Google gives me relevant results (sigh; I think I had gone for more than a year without using !g). Most of these have been exact keyword matches.

Are you thinking of some other company? The most Fastmail has done in LLM directions is offering an MCP API: https://www.fastmail.com/blog/an-mcp-server-for-fastmail/.

Have you tried requesting it? As a former developer there, I would expect you to get a response of “sorry, we didn’t know about that because none of us use it and no one has requested it before, fix incoming” or “yeah, unfortunately in our current architecture it’s not possible to do this because of [some specific reason]”.

Works on Firefox for Android.

> hit hide on the domains that I never want to see anything from

You could convert this into content blocker filters for the likes of uBlock Origin:

  news.ycombinator.com##.submission:has([href^="https://example.com/"]),.submission:has([href^="https://example.com/"])+tr,.submission:has([href^="https://example.com/"])+tr+.spacer

(You can append `:style(color:orange)` or such to apply a different style instead of hiding, if you want to be able to hit the hide link in order to get a new thirtieth item—though you could automate that by writing a user script instead.)

Or user stylesheets (I use Stylus in Firefox to manage such things):

  .submission:has([href="from?site=example.com"]) {
      &, & + tr, & + tr + .spacer {
          display: none;
      }
  }

(I showed two different selectors: [href^="https://example.com/"] will match the complete origin, [href="from?site=example.com"] will match the domain as presented by HN, including any subdomains.)

I’m curious where you start it. I was thinking about it a couple of weeks ago and decided “more than a decade” was safe to say, but I was thinking towards fifteen years, not twenty.