It was removed from the core browser because they reached the point where it could be entirely implemented in an extension, and also wasn’t as popular as they’d hoped. … it should then be noted that it can no longer be perfectly implemented in a WebExtensions world; there are some compromises that need to be made, comparatively minor is my impression but I don’t use it (I used Panorama at first, but found before long that multiple windows and Tree Style Tab was more useful to me).
> An extension system that could actually deeply modify the UI (thanks to XUL), which is now gone (and has been replaced with a partial WebExtension implementation).
Replaced for entirely legitimate performance reasons, even if you ignore the security and maintainability arguments. As with many things, it’s a balance. So long as userChrome.css still works, I’m fairly OK with where things lie.
> Firefox OS, Positron, Prism
Sigh. Yeah. I’d count XULRunner here too. I won’t comment on Firefox OS or Prism, but I believe a substantial reason in the killing of XULRunner and Positron is that they were too hard to maintain and held progress on Firefox back.
> Almost everything Mozilla thought of, half-assed, and then killed, Edge has succeeded
It’s funny how these things go: an early implementer before its time, and then later something else reinvents much the same thing but actually succeeds at it. The first two examples of this that my mind always springs to are actually both Microsoft: HTA, which was basically Electron lite, but in 1999; and tablet PCs in the mid-2000s, that quite flopped because the hardware wasn’t quite right yet, and so Microsoft abandoned the space and licked their wounds for another decade before returning (with the iPad and Android tablets having occupied the space, including things like ASUS’s Eee Pad Transformers).
And the related phenomenon of cycles like how OSes used to be all colour-customisable, then they steadily lost that, then eventually they all added dark modes back in again, treating it as something all new and never-before-seen.
> Dark themes
You’re subscribing to the common fallacy that dark themes are just one thing. The fact of the matter is that there are actually several substantially different types of dark modes. This is theory I’ve been mulling over for the last few years; I’ve vacillated between reckoning three and four types and exactly where to draw lines, but I’m currently going with four: ① æsthetic, which is fairly low contrast and certainly avoids true black and white; ② accessibility, which is high contrast in both colours and styles (that is, no gentle gradients, just harsh boundaries between colours), and uses true black and white—note here that light accessibility mode is much more likely to be useful than dark accessibility mode, but both have a place; ③ low-light, which uses true black and mostly fairly bright whites up to and including true white, but is not scared of in-between colours or actively trying for super-high contrast; and ④ power-saver, which is largely for things like OLED panels, where true black definitely uses less power and can look great, and certainly not for TN LCD panels where true black tends to look awful. Which type of dark mode is most appropriate depends on the user’s eyesight, the device screen type, the ambient lighting conditions, the nature of the content being presented, user preference, and power availability.
It was removed from the core browser because they reached the point where it could be entirely implemented in an extension, and also wasn’t as popular as they’d hoped. … it should then be noted that it can no longer be perfectly implemented in a WebExtensions world; there are some compromises that need to be made, comparatively minor is my impression but I don’t use it (I used Panorama at first, but found before long that multiple windows and Tree Style Tab was more useful to me).
> An extension system that could actually deeply modify the UI (thanks to XUL), which is now gone (and has been replaced with a partial WebExtension implementation).
Replaced for entirely legitimate performance reasons, even if you ignore the security and maintainability arguments. As with many things, it’s a balance. So long as userChrome.css still works, I’m fairly OK with where things lie.
> Firefox OS, Positron, Prism
Sigh. Yeah. I’d count XULRunner here too. I won’t comment on Firefox OS or Prism, but I believe a substantial reason in the killing of XULRunner and Positron is that they were too hard to maintain and held progress on Firefox back.
> Almost everything Mozilla thought of, half-assed, and then killed, Edge has succeeded
It’s funny how these things go: an early implementer before its time, and then later something else reinvents much the same thing but actually succeeds at it. The first two examples of this that my mind always springs to are actually both Microsoft: HTA, which was basically Electron lite, but in 1999; and tablet PCs in the mid-2000s, that quite flopped because the hardware wasn’t quite right yet, and so Microsoft abandoned the space and licked their wounds for another decade before returning (with the iPad and Android tablets having occupied the space, including things like ASUS’s Eee Pad Transformers).
And the related phenomenon of cycles like how OSes used to be all colour-customisable, then they steadily lost that, then eventually they all added dark modes back in again, treating it as something all new and never-before-seen.
> Dark themes
You’re subscribing to the common fallacy that dark themes are just one thing. The fact of the matter is that there are actually several substantially different types of dark modes. This is theory I’ve been mulling over for the last few years; I’ve vacillated between reckoning three and four types and exactly where to draw lines, but I’m currently going with four: ① æsthetic, which is fairly low contrast and certainly avoids true black and white; ② accessibility, which is high contrast in both colours and styles (that is, no gentle gradients, just harsh boundaries between colours), and uses true black and white—note here that light accessibility mode is much more likely to be useful than dark accessibility mode, but both have a place; ③ low-light, which uses true black and mostly fairly bright whites up to and including true white, but is not scared of in-between colours or actively trying for super-high contrast; and ④ power-saver, which is largely for things like OLED panels, where true black definitely uses less power and can look great, and certainly not for TN LCD panels where true black tends to look awful. Which type of dark mode is most appropriate depends on the user’s eyesight, the device screen type, the ambient lighting conditions, the nature of the content being presented, user preference, and power availability.