Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
@Tim sure but that is... completely beside the point of the question. and while technically they're images, i'm half sure it's more from convenience more than anything - two potential upsides being consistent sizing and the ability to have them in css content: properties, rather than, well, "lmao let's use fonts instead of images because why not" - note that even SE itself used spritesheets until (i believe) very recently
@manassehkatz-Moving2Codidact not too sure about svgs replacing buttons and menus though... and while "ui elements" obviously includes images, i'd argue that the vast majority (borders & layout elements) are in fact not images
@MechMK1 or, rather not "get"ting the internet, it's more that it's a heck of a lot safer (esp. financially) to stick with something that's tried and tested, leaving the innovation to others
@HappyDog sure but kinda pedantic... you know what i mean. if it's dynamically generated based on data specific to a certain thing (transaction, user etc.) it doesn't always make sense to have it at (a GET request at) a fixed url. anyway, my point is that conceptually links should be for static data (do note that whether it is "dynamically generated makes zero difference to the end user whether it appears static or not) and forms/buttons should be for dynamic data
re: "to download your digital goods or get a PDF of a receipt may be an API call"... it's because they shouldn't be files. these should be a) dynamically generated and/or b) locked behind authentication - so conceptually it isn't a file (not one at a specific location in a folder hierarchy at least)
eh, rather than "obfuscated programatically" i think it's more than they prefer to have metadata they can check to make sure the file is, in fact, what it claims to be. e.g. uploader name, file size/type, upload date etc.
