Recent submissions

Comment · 4 years ago
This isn't how driving works in practice. Suddenly stopping on a fast freeway isn't a reasonable thing to do unless it's absolutely necessary, and it's not reasonable to expect the following driver to constantly be considering the possibility that the driver in front will slam on the brakes for no reason. Insurance companies (at least in some parts of the world) have a standing agreement to just hold the following driver responsible when there's a collision like this, because in the majority of these collisions, the following driver is at fault. It's efficient for them to agree to this convention to avoid the cost of investigating each collision individually. This has led to the common misconception that the following car is necessarily responsible if there is a front-to-rear collision.
Comment · 4 years ago
I thought I and all my colleagues were getting 500s, but then I checked the status page and saw a green check. Silly me!
Comment · 5 years ago
Comment · 5 years ago
Comment · 6 years ago
> fonts are larger than you might think because they need full Unicode support

Correct me if I'm misunderstanding, but don't the vast majority of fonts _not_ include full Unicode support, or even close to it? I know of GNU Unifont, but not many people are using that on the web...

I take your point on selectively downloading the relevant glyphs for the user's locale, but this could be done by the browser too - it is aware of the locale.

Comment · 6 years ago
Maybe I'm being naïve, but why don't browsers ship with more popular fonts bundled to avoid problems like these? I have no issue with any of my browsers taking up fractionally more space for an extensive cache of the most popular web fonts when the payoff is better performance on so many sites.

Of course, servers should still be capable of serving the fonts that the client requires to render the content correctly, but the browser should be equipped to make that happen as quickly as possible.

Comment · 9 years ago
Of course. I know even more who whitelist sites with ads that aren't overbearing.
Comment · 9 years ago
StackOverflow ads are not the same as typical ads that technical users tend to block - they are typically just simple text links to job offers. Additionally, SO has fantastic analytics on logged in users which would drive the cost per impression up - if you've ever filled out their developer survey, you've given them everything they need to sell employers very expensive targeted ads directed at you.
Comment · 9 years ago
Comment · 9 years ago
There are a few more for numeric types:

  var integer = 1;
  var long = 1l;
  var float = 1f;
  var double = 1d;
  var decimal = 1m;
  var unsignedInteger = 1u;
  var unsignedLong = 1ul;
Comment · 9 years ago
Fingers crossed it has desktop clients that aren't written in Electron...
Comment · 9 years ago
That's interesting, and a relief.
Comment · 9 years ago
If it's true that Chrome on Oreo genuinely prevents picture-in-picture for YouTube specifically, that's a troubling precedent to set. Why not allow all websites to enable/disable PiP (maybe via a meta tag, in the way that tab theme colours already work)? If I query https://m.youtube.com while emulating a Nexus 5X, the response contains:

  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, target-densityDpi=medium-dpi">
Is that what is preventing PiP on YouTube or is it some sort of underhanded inter-Google arrangement between Chrome and YouTube?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton