FireFox started to go downhill at least 3 years before Brendan Eich left in 2014. Most notably was when they started the version-number madness in 2011 starting with 4.0. But even before that, FireFox was starting to have a reputation for adding new features instead of fixing bugs and performance (but at least back then, these were features people actually wanted), and the 3.x versions were notable for having 'senior moments'.

IIRC the only thing that comes to mind because of Eich's resignation was that Eich made the decision not to include a certain type of DRM in Firefox, but his successor reversed that decision.

Oh, and...

a new format was developed - PNG. This was a lossless 32bpp format (8R8G8B and 8A)

Hope this makes more sense...

(Mosaic only added support a few months later).

Back before the graphical web took off in the early 90's, much consumer-level graphics-hardware was only capable of displaying 8 bit per pixel graphics (256 colours (using an indexed palette where each palette entry (up to 256) could choose one of 2^24 possible colours (R8G8B8)) at a time). GIF was a lossless format that encoded images in a range of bit-depths up to 8 bits per pixel (images with 4bpp were also common when GIF was launched). The lossless compression algorithm that GIF used wasn't as good as what came later, but even so, it became popular, as it allowed VGA-quality graphics to be encoded. GIF (along with XPM) was one of the first image-formats to be able to be used as an in-line image (in-line meaning it could be shown as part of the HTML document and not have to be downloaded separately to be used with an external image viewer) in early versions of Mosaic back in 1993.

As the mid 90's approached, 16bpp and even 24bpp were starting to become more common. This was when the 8bpp limit of GIFs was noticeable. The most obvious use for these higher bit-depths were digital photos, which because photos by nature are very irregular are hard to compress using a lossless algorithm. So JPEG - a lossy image-compression algorithm that works in 24bpp was chosen. It was more than a year after Mozilla introduced inline images that inline JPEGs were supported by Netscape (Mozilla only added support a few months later).

At first, JPEG didn't take off because web-developers were reluctant to use an image-format supported only by a few browsers, and back then, 8bpp graphics-hardware was still common. But then in early 1995, it was announced that UNISYS held a patent related to GIF that restricted it's usage. Because of that, many websites started using JPEG (although many websites still continued to use GIF). However, Netscape still had a trick up their sleeve. They noticed that the specification for GIFs allowed them to contain animation, and they implemented support for animated GIFs in their browser in late 1995 (this was even after they implemented support for Java which also would have allowed animation).

But JPEG had a restriction - it couldn't compress an image losslessly. While JPEG was great for photos, it would itroduce noticable artefacts on drawings, diagrams, etc.). To get round this restriction, and the fact that GIF was limited to 256 colours and had a patent, a new format was developed - PNG. This was a lossy 32bpp format (8R8G8B and 8A) that included alpha-channel support (GIFs did support transparency, but it was 1-bit (either fully transparent or fully opaque)), and used a much better lossless compression algorithm than GIF. While web-browsers supported inline PNGs as early as 1995, because the format hadn't matured yet, it took several years for it to take off. Holding up progress were several PNG-related bugs in Internet Explorer 6 (used by >90% of computers in the early-mid 00's) that didn't render certain types of PNGs properly (eg. ones with alpha channels). Add to that the fact that the UNISYS patent expired in 2004, it meant that for line-drawings, many people stil preferred GIF over PNG simply because MSIE6 often botched PNG-rendering. These days, PNG is pretty common when using images more suited to lossless compression.

PNG images are static and don't support animation. Two attempts were made in the early 2000s to support PNG-animation - APNG and MNG. Both didn't take off, so for animated images, we're still - in 2026, when nearly everyone has a 24bpp display - mostly using animated GIFs and their 256-colour limitations to show animated images on the web.

After many years of new image-formats that either died or did not gain traction, JPEG-XL appeared. It could finally replace both lossy JPEGs and lossless PNGs and animated GIFs, but was held back by browser developers. Google wanted to push either WebP or HEIC, and deliberately did not support JPEG-XL, but the tide has finally been turning. With both Chrome and Firefox (and presumably Edge which uses Chromium following soon) supporting JPEG-XL out the box, websites could finally shift over to JPEG-XL. The ability to losslessly transcode JPEGs into JPEG-XLs helps the transition, and if the server detects an old version of a browser, it can translate a JPEG-XL back into a JPEG in real time. So we might now finally be seeing more annd more websites starting to use JPEG-XL.

However, the fact that 25 years after the first attempt was made to introduce animated 24-bpp images, GIFs are still used, might give a warning that the transition may take some time. Hopefully, JPEG-XL support from all major browsers and image-viewers and an easy way of shrinking JPEGs by converting them losslessly to JPEG-XLs will make the transition easier.

Or as C++ programmers will say: What you want is a &&, not a &

...when describing an Electric Monk in his book Dirk Gently's Holistic Detective Agency.

"video recorders watched tedious television for you, thus saving you the bother of looking at it yourself"

Space Invaders (Taito, 1978) was probably the first game to introduce the concept of the 'video game character'. Before that, games such as Pong, Breakout etc. were mostly just based on purely abstract graphics (ie. blocks (largre pixels)) that did not have any personality. Space invaders managed to give the aliens a distinct look (and even made the effort to animate the characters (even if it was just two frames), which was a big deal back then), and thus giving them a distinct character. Nearly all games after that had some sort of character - hence Space Invaders may have given birth to video game characters.

I've made posts about it here, here, here and maybe a few other places too.

My main message to the FireFox devs is this: Be aware that your user-base is power-users who want to customise the heck out of their browsers. Your attempt at simplifying the UI by copying Ch*me is quite frankly misguided. It's because of this that there's a big disconnect with what the Mozilla managers imagine FireFox users want, and what FireFox users actually want. To fix this, all they need to do is to bring back the customization they took away. So basically, this is another way of saying that FF needs to concentrate on winning people back from browsers like Pale Moon, Basilisk, Waterfox, and not Chr*me, Edge, Safari, etc. It doesn't matter if the browser has the biggest market-share, it just has to fill a niche and be good at filling that niche

Two specific things that annoy me:

• Please do not merge the stop and reload buttons in a misguided attempt to save screen real-estate. What if you want to stop a web-page from loading that's taking ages to load (in the hope that it stabilises or uses less resources when it's not in it's "waiting to load" state) and then you just happen to press the stop button when the webpage either finished loading or timed out, only for it to have changed into the reload-button and then your webpage reloads. And besides, stopping and reloading are two separate functionalities and should not be merged.
• Document-tabs belong UNDER the UI and immediately above the webpage-area - NOT right above all the controls. Last time I tried FireFox, it was not even possible to fix this even with an extension. Don't know if that's still the case, but it was when I stopped using FF.

Oh, and could you make sure JPEG-XL support is enabled by default?

This article discusses a plan for re-filling the Aral sea by diverting part of the river Ob to flow southwards towards the Aral sea to prevent it from completely evaporating. This will also have the side-effect of reducing the amount of freshwater being discharged into the Arctic Ocean, and thus reducing the dilution of salinity in the Arctic ocean with fresh-water from the Ob, which might help prevent the Gulf Stream from shutting down (apparently, increased salinity would keep it going). Considering the situation in Russia right now, the chances of this happening are almost zero, but considering that the port of Murmansk would no longer be ice-free without a Gulf-Stream might just motivate the Russians to do something.

While the 800XL apparently had the best case for modding and expanding, the 400's case looked the best. It had what's now called the Cassette futuristic aesthetic. It actually looked like it came from the future and now has a very retrofuturistic look. Later home computers such as the Atari 800XL, Commodore 64, etc actually looked like they belonged in their time period at the time.

This article discusses a plan for re-filling the Aral sea by diverting part of the river Ob to flow southwards towards the Aral sea to prevent it from completely evaporating. This will also have the effect of reducing the dilution of salinity in the Arctic ocean which might help prevent the Gulf Stream from shutting down. Considering the situation in Russia right now, the chances of this happening are almost zero, but considering that the port of Murmansk would no longer be ice-free without a Gulf-Stream might just motivate the Russians to do something.

When HDTV came out, we had 720p and 1080p resolutions (on broadcast, it was only 1080i, but the TVs could mostly handle a 1080p input signal (eg. from a Blu-Ray player or PC)). This meant that not only did 1080p content have to be downscaled to be viewed on a 720p TV, but 720p content had to be upscaled to be viewed on a 1080p TV. Because 720 is not a factor of 1080, it meant that each pixel of a 1080p display does not correspond to an integral number of pixels in a 720p display, so some blurriness might occur. With 2160p (AKA 4K) displays, 1080p can be upscaled losslessly by just repeating each pixel twice, and 720p by repeating it 3 times. I was hoping that with 4k and 8k resolutions, we'd get rid of those pesky 2/3rd resolutions, but then along comes 1440p (which was not part of the original plans for resolutions beyond 1080p) to screw things up. 1440p cannot be upscaled to 4k losslessly. At the moment, 4320p (8K) displays are prohibitively expensive, so most of us are stuck with lossy upscaled (or downscaled) 1440p content.

While any 3D game can easily adjust to any screen-resolution (not including performance-issues), the problem is that 1440p monitors encourage people to make native 1440p videos in this this 2/3rd resolution.

1440p is a bastard-resolution. Please don't encourage it!

Pale Moon - a fork of FireFox currently supports JPEG-XL by default (ie. without having to mess around in the configuration), but unfortunately, it's only got a negligable share of the market. I think maybe a few other FireFox derivatives also support it out the box. Would be great if FireFox itself would enable it by default, but unfortunately, FF only has a 3% or so market-share (6.5% on Desktop). As EDGE uses the Chromium engine, I'm not sure if Microsoft can add JPEG-XL to EDGE without distancing itself from Chromium, and I'm not sure what the situation is with Safari.

I made a post about this in another Slashdot article which basically said that what caused IE to lose it's market-share was it's stagnation (IE6). Not only did it have many security bugs, but it's implementation of certain web-standards was poor. FireFox came at just the right time, filled in the gap in the market, more web-developers felt confident using things that were broken on IE6, and FireFox chewed away at IE's share of the browser market.

Nowadays, Chr*me's lack of support for JPEG-XL might seem similar, but it's just one issue, compared to IE6's notorious buggyness. This might be a chance to break the hegemony of Chr*me, but for that to happen, there would have to be a lot of websites that serve content in JPEG-XL. From a website's point of view, the reduced bandwidth would greatly benefit the site, and from a developer's point of view, existing JPEGs can be transcoded to smaller JPEG-XLs losslessly, and if they had the original images (or JPEGs at higher resolution/quality), even bigger savings can be made.

The only reason Chr*me has a hegemony on the web is because we allow it. For most end-users, there is little incentive to switch browsers. But if more sites offered JPEG-XL content, refused to offer content in AVIF and asked users to use a different web-browser to view it, it might just be the tipping point. Of course, if Google change their mind and add JPEG-XL, there will be less incentive to move away from Chr*me, but then, we still have an unhelathy domination of the browser-market going on.

Again, the definition has been bent just to label something as Raytracing for marketing purposes. Back in the early 90's, I saw a PC game that claimed to do Raytracing, but it looks like fake-phong-shading.