Of course they don't, but since there is no magical way to make incompatible desires/workflow compatible, configuration is the only way out

I rarely need to configure something on my PCs, but rarely is not never, and when I do really need an option, it better be there. There's a gradient between unmaintainable multidimensional matrices of options and "one size ought to fit everyone" and both ends of it make the user miserable.

Indeed, people aren't paid to do the good things, only the easy ones

The famously ironic case of honesty in a study about honesty

https://retractionwatch.com/2021/09/14/highly-criticized-pap...

and BMP in this context is not BitMap, but Unicode Basic Multilingual Plane (BMP) of the first 65,536 code points of the Unicode

Amusingly, here it is also BitMap [1]. Why they use an obsolete noncompressed proprietary format instead of PNG I don't know.

Edit: looks like it's because BMP supports 1-bit packed pixels and ~~PNG doesn't~~ (Edit to edit: this is wrong). The file sizes are almost identical; the 8x difference in the number of bits is exactly balanced by PNG compression! On the other hand, PBM [2] would've been a properly Unixy format, and trivial to decode, but I guess "the browser knows how to render it" is a pretty good argument for BMP. macOS Preview, BTW, supports all the NetPBM formats, which I did not expect.

[1] eg. https://unifoundry.com/pub/unifont/unifont-17.0.03/unifont-1...

[2] https://en.wikipedia.org/wiki/Netpbm

Maybe they set everything up before png was popular and never changed the workflow since then (or didn't care about the website to adjust anything)? After all, the PNG is only about 2 years younger than the font

That's plausible. Or maybe they just liked the BMP vs. BMP coincidence.

> Edit: looks like it's because BMP supports 1-bit packed pixels and PNG doesn't. The file sizes are almost identical

That's nonsense, PNG supports 1-bit pixels just fine, and the resulting file is a lot smaller (when using ImageMagick):

    $ file unifont-17.0.03.bmp 
    unifont-17.0.03.bmp: PC bitmap, Windows 3.x format, 4128 x 4160 x 1, image size 2146560, resolution 4724 x 4724 px/m, 2 important colors, cbSize 2146622, bits offset 62
    $ magick unifont-17.0.03.bmp unifont-17.0.03.png
    $ file unifont-17.0.03.png 
    unifont-17.0.03.png: PNG image data, 4128 x 4160, 1-bit grayscale, non-interlaced
    $ wc -c unifont-17.0.03.*
    2146622 unifont-17.0.03.bmp
     878350 unifont-17.0.03.png
    3024972 total

Thanks! I definitely should've double-checked. Apparently it was just the image viewer that didn't bother converting the 1-bit BMP to 1-bit PNG.

"and yet didn't bother to swim to the nearest Apple store"

Except they're not keeping the font clean, just less legible

Indeed, and you'd think that over many decades of font design some basic fails like this would not happen as they'd be against the fundamental rules "that every single font designer knows by heart"

> There is no way for your keyboard to know you're in "hunt and peck" accuracy mode

But there is a way for your keyboard to simply show the real size/position of buttons so that in hunt and peck mode you'll be correct

>But there is a way for your keyboard to simply show the real size/position of buttons so that in hunt and peck mode you'll be correct

Yes, but the tradeoff in that case is that for most casual typing it will be less forgiving and you'll make more (uncorrected) mistakes

Why would showing real button sizes make casual typing less forgiving?

Because that would correspond 1 to 1 with the actual visible letter boxes, and the whole system of catching events outside the "real button sizes" was developed to be more forgiving than "you have to click precisely in the box".

My understanding is it's not just about including or not including some extra fixed clickable padding around each square (in which case it indeed wouldn't harm to show the whole area), but about dynamically adapting the area, based on frequent off-target clicks, probabilities, etc.

> That should be corrected if anyone invents a time machine. :P

Why can't this be dealt with with CSS versioning/features where you can opt into your current-color and a lot of more substantive style behavior while leaving currentColor functional?

A lot of the behaviors should just have a toggle to turn them off. For example, there are many situations where margin collapsing is in the way and I keep wondering why there isn't simply a `margin-collapse: none`. It would also be nice to have something like `default-styles: none` that will remove all the default styling for h1/h2/etc. and em/strong/cite/etc. so I don't have to deal with browsers having differing defaults.

> It would also be nice to have something like `default-styles: none` so I don't have to deal with browsers having differing defaults.

This already exists:

    *, ::before, ::after { all: unset }

> Remember having to put a 1px image in a table cell to avoid it disappearing

Isn't this a trivial problem to solve that doesn't require introducing any new layout mechanisms?