Light or dark mode, what is the difference and what is your preference?
The more you look on devices, the more you are affected by shining or flashing lightning, hurting your eyes, reducing the battery wastage, having burn affects, show too many blue pixel lights not good for your eyesight, etc.
This is why developers like dark modes.
It helps reducing the noise of light your eyes has to blend out.
So we have a populating ambition to create dark modes on apps, by webpages and by browsers, all over.
Therefore we need to clear some things out, since we have too many players:
At first it started with very single webpages and apps giving a dark mode or dark theme to enable or to live with.
The first case is good, since you decide which you prefer. And in some cases, like developed for the pure theme with upcoming Serendipity Styx 3.7, you can easily switch it by a button where it makes sense to you. It even has a condition if your browser prefers-color-scheme: dark, so it knows where to go when you first arrive without a selected set.
Then it dropped over to systems, like android for example, which allowed to set a dark or light mode preference. The more that came into play, the more the system and other developers thought of generally turning everything dark.
But this is shaky, since a machine or program - even with good algorithms - cannot really decide what looks good or not, or suits you best. Down to the bottom they just turn light into the opposite dark color and vice versa. That only works good as simple as that on pages which are designed as simple as that!
So we have apps and the system.
At last the Browsers started to take over and made the confusion complete.
Browsers have themes. These can be light or dark and influence the whole frame behaviour of your magic monocle.
Then they have modes, which allow to overwrite certain colors of webpages, eg. for link colors.
And they can depend on light themes forcing dark pages, light themes not doings such stuff, dark themes with dark forced pages and dark themes with untouched webpage colors.
But wait! Didn't you say there are system dark modes too? Right! Browsers have to take this conditions into too.
With Firefox 95, which just arrived in the public, you will see this affect. Sudden pages return dark without being explicitly set to, depending on settings you might have taken in your system, browser or application before.
Firefox for example has a "ui.systemUsesDarkTheme" configurable config variable, which is set by your theme choice. The new, beside theme setting and color overwrites, is:
? see “layout.css.prefers-color-scheme.content-override”
0 = dark (users may want a light system style, but dark websites)
1 = light (users may want a dark system style, but light websites)
2 = system
3 = browser theme (default original setting = 3)
This check and set can help to restore behaviour you have been used to.
Really!Didn't I say this before? I like dark modes! 😀
As already stated when developing the Styx 3.0 Series for WebP there was
another image format on the horizon.
This is the AV1 Image File or AVIF format, which offers extreme compression
by visually no image quality change compared to the traditional formats like
JPEG, PNG, and GIF, and even the relatively new WebP format.
A royalty-free, cross-platform format for media delivery, given support from
all big players (Alliance for Open Media), so it is likely to get adopted
much faster than the WebP format, which took almost ten years from launch
before being supported in Firefox.
AV1 Image File support in browsers and apps
Chrome 85+ and Firefox up from 93+ already support the AVIF format by default.
The latest status for browsers supporting AVIF can be found here:
[« Can I use »].
Sadly the Safari browser and Apple OS environments are behind, while Android
should already work.
AVIF image format delivery
As you know already by working with Styx WebP Variations, uploaded files in
standard image formats are additionally stored as new format Variations.
So AVIF is yet another Variation stored in the MediaLibrary .v/ directories.
The Styx OUTPUT toolset checks the image AVIF Variation compared with the
WebP Variation and always delivers the smaller in filesize. If it is enclosed
by the picture element container, the sourceset (srcset) order
will always be AVIF first, then WebP and for last as the <img..>
element the origin file expression.
In case the WebP srcset image expression is smaller in filesize than the
AVIF one, the AVIF srcset is suppressed. This ensures that always the
smallest in size is delivered.
Sending this prepared HTML markup to the client, the users browser and
environment decides which image it is able to load and to display.
CURRENT IMPORTANT DRAWBACKS of using AVIF format
While most of the things about AVIF are VERY promising and it is likely to
become the standard for media delivery in the future, there are some shortcomings
that we should be aware of before migrating to AVIF.
The ABSOLUTE MAJOR BOTTLENECK is the encoding performance of AVIF images,
which can be VERY SLOW compared to JPEG or WebP images. While the majority of
user devices should have no problem decoding AVIF images for display, it
can at times take over a minute or two to encode an image to AVIF.
The time and resources required for encoding benefits some images with impressive
extreme compression ratios. I had all over from ~30 up to extreme 96,6 percent of image
compression ratios without loss.
As the format evolves, the encoding performance is likely to improve in future.
ENVIRONMENTAL ENCODING SUPPORT
Encoding support starts with PHP 8.1 by GD library with release at the end
of November 2021 and with ImageMagick up from 7.0.25+ versions.
Uploading files already in WebP or AVIF format was even possible before, but
resizes, read out and other actions do need support at least from some PHP
build-in methods. There still is work to do, like for getimagesize(), which
does not work for AVIF image sizes yet in PHP 8.1 out of the box (see LIMITATIONS).
We have to strongly remind you - when testing - to not upload more than one
image at time (!) to not crash your given server resources.
The time of encoding is depending on the origins file size. Sizes under
1 MB won't matter as much as when using images with several Megabytes.
PHP GD and ImageMagick encoding compression are slightly different and their
results often surprising comparing all formats. See an example result:
If you want to get known to AVIF without touching your current blog system,
there are third-party service providers like ImageKit with extensive image
processing networks to provide decent AVIF encoding performance in real-time
for your images. Or using the fascinating tool and conversion privacy of
[« avif.io »] which uses Rav1e, Rust and WASM to convert your
Styx 3.6 has not yet enabled AVIF support by default. It just states to be
groundwork ready for extreme testers and other Developers.
For daring testers I push out a Serendipity Styx 3.7-beta1 soon which will
be able to enable AVIF variations per option (temporarily). Keep in mind, that we maybe
will NOT be able to just use AVIF variations per Styx default, and as long the requirements
are given, for some more years, since performance and other issues like the ones
already mentioned were not proofed over several years (as they were for WebP
which had much more time landing in mainstream).
That said, enable in « Configuration » - « Image Conversion Settings » - « Enable use of AVIF Variations? ».
This base implementation is known to fail with certain Variation builds, in
special with ImageMagick conversions while developing. So any Variation files
with 0 bytes, or AVIF images with 252 bytes (0.25 KB) or 3389 bytes (3.4 KB)
or 34165 bytes (34 KB) are considered broken and conditionally excluded from
usage. Time will tell if this needs a review for different file systems or
just were rare issues on my machine while experimental development only. FOR ANY TESTERS:
If you see outlined files with webp or avif extension not being displayed by
link or by picture container, please file an issue with extended information.
For having discovered certain issues with bigger image sizes, there is a
14MB upload limitation set which avoids running AVIF variation conversions.
Some of the encountered failures I found while development (at least the 0
bytes ones with GD and the 252 bytes with ImageMagick) were connected to some
images of certain .jpeg files for the most, while others (jpeg/jpg) did
succeed without problems. There seems to be something included to those images
which breaks with an "error/heic.c/IsHeifSuccess/135" error, that seems to be
a missing something using libde265 for reading and x265 for writing in HEIC.
As you see this is still a process and is further on bound to HEIC/AVIF support
compiles on different servers. If you discover failures, don't throw with tables
and just note them to be one of those issues which will hopefully get ironed out
PLEASE NOTE, that ALL current PHP versions - including the just now released
PHP 8.1 - are not able to thumbsize an image by readable image sizes,
when you have an AVIF image format.
The PHP 8.1 standard image format conversions in current Styx 3.6 and 3.7-beta1
state are only able to do so, since they take the same values as the WebP
expression as a "stolen" value copy. This is a current Styx PHP workaround
and upload limitation as long this is not implemented to PHP without having
to use additional libraries.
Some Developers already have stiched together a promising libavifinfo C-file
that still needs some final thoughts and reviews but is near to come included
to PHP, so we probably will get readable support for AVIF payload containers hidden
inside the AVIF file. If this is going to be added to PHP 8.1 is a question and
may as well find its way very much later to PHP 8.2 next year.
This also implies to Styx image scaling and rotate actions. So if an AVIF image
file or image AVIF Variation file exists - and/or is known broken by filesize
image scaling/rotating is prohibited for all formats as long this PHP
implementation loss is a matter. Rotate won't throw a message in this case.
Its not the length of changelog descriptions that makes the value or the headline ;-) As announced by rumors very early, the main feature of Styx 3.5 is the DARK MODE, beside all additional improving fixes.
Styx 3.5.0 applies
Extend some more picture WebP variation container backend usage
Updated the Bootstrap and CKEditor assets
Improved backend handlers, like adding back buttons, or action buttons for certain rare cases, etc.
Finally removed old Smarty backward compatibility mode wrapper and configuration sets
Improve backend entry preview array for empty categories and certain themes
Improve fetching image meta data for EXIF data readable file format checks
Added some missing lang constants
Removed a last occurrence of Serendipity Series 0/1 API workarounds
Fixed an amount of old bugs and regression losses
Improved and fixed user handling and permissives
Fixed themes (check out new dates)
Fixed a faulty interpretation with using theme required fields and contactforms, ending up being more strict.
Finally added the DARK MODE, playing well with all sort of difficulties. Improves clarity and contrast as well as the styx backend theme in general.