In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.
And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't handle it won't even show the image.
It's not theoretical. It's the JPEG XT spec. It adds alpha channel and HDR to standard JPEG in a backwards-compatible manner.
* A webp version with transparency, which won't be supported by most clients but the ones which do will support everything
* A JPEG version without transparency, or with "faked" transparency (i.e. baked-in background color), which will be supported by basically everyone but with less quality.
That way, if the client is capable of loading the "good" version it will, and if it can't then it will load the "good enough" version.
SVG is such an underappreciated technology that is in every browser. Why do icon fonts exist when you could just use SVGs just like you do PNGs and JPEGs? You can even inline them in your HTML so there isn't an additional HTTP request if you want.
Edit: Did some more research and the patent risk appears to have passed as of 2016. Still nobody seems to have interest in JPEG2000.
There is simply no reason why people in 2016 or now would be interested in a format from 2000 that was a patent minefield until at least 2016.
Are people just more cavalier about the patent risk these days? The problem with JPEG2000 wasn't the patents we knew about, it was the possibility of submarine patents. People were still wary after the GIF debacle. Nobody wanted to be charged $0.05/image after the fact when they've delivered literally billions of images. Plus the courts were seen as very favorable towards patent holders, even when they were acting in bad faith.
These design decisions all made sense when clock rates were exponentiating, but they're all nightmares now that we rely on branch prediction and memory prefetching and superscalar execution units. The codec is simply not a good fit for the computing architectures we have today.
Arguably not a good choice for the year 2000, either, considering that all high performance CPUs at that time were out-of-order, superscalar and deeply pipelined.
They've subsequently improved that — OpenJPEG is quite good now https://github.com/uclouvain/openjpeg — but probably missed the window for adoption barring a major upset, which is a shame because it's a very powerful codec and has some neat tricks like progressive decoding (imagine if you could have one file in storage and your responsive design simplify specified the HTTP range requests to get for successively large resolution images?). You could ship it in a browser using WASM but I think the browsers are — not without cause — being really reluctant to add new formats and the ensuing security risks without a good reason, and without browser support no format will be more than a niche.
Every iOS and macOS device supports JPEG 2000… that should be pretty meaningful.
As an example, we could talk about the number of connected IoT devices that are supported and up to date, and it's probably in the billions. But compared to the number of connected out of date and unsupported devices, it's likely inconsequential in comparison by metrics of total numbers, percentage of a whole, and importance (alternatively, total number of unsupported and possible exploitable devices does matter, because of what it implies about how they can be used destructively).
If you want transparent JPEGs on your web page that works.
Back then the number of GETs was really important, so stuffing the mask into the JPEG made sense. Now with our HTTP/3 and QUIC world that isn't such a big deal.You might be better off just using a CSS mask image.