I forgot to mention that PDF added new features on top of PostScript, including 3D models.

Strangely, this kinda makes sense. PDF is based on PostScript, which is a file type (also by Adobe) that gets sent to printers. It’s just skipping the final “send to printer” part and sends it to a file instead.

A fascinating thing (in a scary way) is that PostScript is technically a full programming language with loops, functions, logic, and a built-in font rendering and 2D graphics engine. When a document is printed using PostScript, your computer generates a script to lay out the page, that the printer runs in order to produce the document!

PDF is essentially “the safe parts” of PostScript - the same 2D graphics engine but with all the dynamic parts removed. PDFs are statically laid out when they’re created, rather than having to run arbitrary code to lay them out like PostScript does.

PDF does support JavaScript code, but it’s rarely used and needs to be granted permission to run. It’s not a core part of the format.

For printing, PCL has somewhat taken over and it’s less scary - it just has preset commands rather than allowing arbitrary code in a full programming language. PostScript is still used today for higher-end printers and print jobs though.

Gzip is old-school. The majority of modern sites use Brotli now. It’s slower to compress, but that’s not normally an issue for static resources (CSS, JS, etc) because they can be pre-compressed during the build and the web server serves the pre-compressed files instead of dynamically compressing them.

Some sites and apps have custom scrollbars. I don’t like it, but they do exist.

Websites can change the colour of the scrollbars, in which case they’re no longer system-rendered ones.

The recommended ESLint rules catch most of the bad stuff, and these days this is all you need in your ESLint config to enable them:

import {defineConfig} from 'eslint/config';
import js from '@eslint/js' 

export default defineConfig([
  js.configs.recommended,
]; 

There’s one use case where == is still commonly used: == null matches both null and undefined. Lint rules that block == usually allows the null case as an exception.

I think a lot of “modern” scrollbars are just there as an affordance so you know that the content is scrollable and how far you’ve scrolled down, not to actually click and drag. Not entirely sure about the UX research for this but my guess is that it’s because most people either physically drag (like with a touchpad or touch screen) or use a mousewheel to scroll down.

Some websites / web apps have the opposite problem: too many scrollbars.

MacOS has a setting to hide scrollbars when a mouse isn’t plugged in (i.e. when just using the trackpad on a laptop), and it’s enabled by default. Even if you force a scrollbar to appear using CSS (overflow: scroll), it won’t appear.

I’ve seen sites where some boxes had two or three sets of scrollbars, because the developer didn’t test on desktop OSes other that MacOS (or on MacOS with a mouse plugged in) and didn’t realise that their CSS was adding scrollbars to too many elements.

In any case, your design should have an affordance to show that there’s more content that can be scrolled to. A common way to do it is fading out or having a shadow on the scrollable edge. This technique is close to 15 years old but I still see it used today: https://css-tricks.com/books/greatest-css-tricks/scroll-shadows/. The Chrome dev site has some brief notes on some more modern techniques: https://developer.chrome.com/docs/modern-web-guidance/guides/ui-atoms/scrollability-affordance-hints