Preferred formats | Lists

Technical decisions I usually make.

Conventions

Character encoding: UTF-8, because everything else sucks.
Dates: ISO 8601, because it's better than the alternatives.
Information units: base 10 (i.e. 1 kB = 1000 B), because it's more intuitive for people using base 10 numbers (everyone).
Line endings: LF, because that's what Unix does.
Physical units: metric, because it's easier to do conversions in it.

For borders, shadows, and icons: px, because those are usually small, and it's nice when they're pixel-perfect.
For element sizing and spacing: rem, because it scales with the :root font size and is easier to keep consistent with other elements than em when dealing with different font sizes.
For font sizing: em, because it's easily adjustable and handles nesting well. Make sure to use it for :root as well in order to respect the user's system font size.
For viewport media queries: em, because it scales with the user's system font size, and it doesn't make sense to use rem here because media queries don't respect the :root font size.

For captions of UI elements: Sentence case, because Title Case makes them look noisy, especially when there are many of them in a row.
For filenames and interactive commands: kebab-case, because it's easy to type (unlike snake_case) and easy to read (unlike camelCase). If I was making a programming language, this is what I'd choose for variable names.
For instant messages: all lowercase, because it requires less effort than Sentence case and is a good way to convey a casual tone.
For names of programming projects: Title Case or kebab-case, depending on which one looks cooler, because that's what nerds do.
For titles of articles, videos, and sections: Sentence case, because those tend to get long, and when they do, Title Case gets hard to read.
For titles of other works of art: Title Case, because those are usually short, and it looks cool.

Image dithering: Floyd-Steinberg, because it's reasonably good and widely implemented.
Video deinterlacing: yadif, mode 1, because putting each field on a separate frame better mimics what happens when you look at a real CRT.

When compositing or resampling images: linear sRGB, because it matches real world color blending better than gamma sRGB.
When adjusting the colors of an image: Oklab, because it handles everything, especially hue, better than CIELAB and CIELUV.
When picking colors: Okhsl, because it covers the entire sRGB gamut without clipping and handles saturation better than HSLuv.

When upsampling pixel art or a screen capture: nearest neighbor, because interpolating them feels uncanny. When dealing with non-square pixels, make sure to account for the aspect ratio. For example, the NES has a resolution of 256x240 pixels, but it's stretched to fill a 4:3 display. As such, when upsampling the NES footage to 1080p, the resulting resolution should be 1440x1080, not 1152x1080.
When downsampling pixel art or a screen capture: Robidoux NoHalo or Gaussian with a sigma of 0.375, because it avoids ringing while being sharp enough for this task.
When trying to avoid aliasing and ringing, even at the cost of blurriness: Gaussian with a sigma of 0.5, because it eliminates both completely.
In all other cases: Catmull-Rom cubic or 2-lobed Lanczos, because it's reasonably sharp and its ringing is nowhere near as bad as what 3-lobed Lanczos produces.

When aiming for maximum compatibility: ZIP, because you can open it even on Windows XP.
When archiving already compressed files: tar, because it doesn't compress unless you ask it too.
When trying to squeeze as much compression as possible: tar + Zstandard, compression level 22, because it's both fast and compresses well.
In all other cases: tar + gzip, because it's good enough, and most people can open it.

Vector: SVG, preferably without editor-specific metadata, because it's plaintext and works on the Web.

For production and storage: lossless JPEG XL, because it's more efficient and future-proof than PNG.
For distribution: PNG or JPEG, depending on the required lossiness, because everyone can open them.

When aiming for maximum compatibility: VP8, because any web browser that can play video can also play it.
When you need lossless compression: FFV1 + way too much disk space, because it's the simplest solution.
In all other cases: AV1, preferably encoded with SVT-AV1, because it blows everything else out of water.

For production and storage: Matroska, because it can fit anything inside, including FLAC and FFV1.
For distribution: WebM, because it works on the Web.