As it turns out, the implementation of the site’s dark mode was plagued by a Flash of Unstyled Content (FOUC). As illustrated, light mode would flash during navigation between pages while in dark mode. Yuck.
The issue lies in the fact that the dark mode class is applied to <body> only after the page fully loads. As a result, the browser renders the default light theme in the brief moment between page load and the execution of the dark mode script.
The fix:
Apply dark mode to <html> instead of <body> by adding an inline script at the top of head.html
Update dark mode styles to target html.darkmode.body
Update dark mode JavaScript to use document.documentElement.classList.add("darkmode"); instead of document.body.classList.add("darkmode");
A recent analysis of a Apple QuickTime .MOV file I conducted at work compelled me to write this post to discuss its file structure.
Released in 1991, Apple QuickTime .MOV files are structured by hierarchical atoms that store media data and metadata. A typical .MOV file may consist of the following atoms:
1. ftyp (file type)
The ftyp atom specifies the file format type. For example, ‘qt’ for QuickTime.
2. moov (movie) aka ‘the meat’
The moov atom defines the .MOV file since it carries crucial technical metadata like duration and display specifications.
It may have other types of sub-atoms, with at least one of the following three: mvhd (movie header), cmov (compressed movie) & rmra (reference movie). Several other sub-atoms like clip (clipping), trak (track), ctab (color table), and udta (user data) may exist in the moov atom.
The layout of a moov atom:
Data
Type
Size
4 bytes
Type='moov'
4 bytes
Profile atom
'prfl'
Movie Header atom (REQUIRED)
'mvhd'
Movie Clipping atom
'clip'
Track atom
'trak'
User Data atom
'udta'
Color Table atom
'ctab'
Compressed Movie atom
'cmov'
Reference Movie atom
'rmra'
3. mdat (media data)
As suggested, mdat contains the files audio & video data.
4. free/skip (padding) [optional]
5. uuid (user defined) [optional]
Interestingly, the file that landed on my desk came without its ftyp atom, which I learnt was only required after the establishment of the ISO Base Media File Format (ISO BMFF) standard. It is also likely that legacy tools and software at the time may omit the atom, relying completely on players like QuickTime player to smartly defer to the moov atom. Hence it is plausible that legacy .MOV files may come without the ftyp atom, hence failing to play in some players and file format identification checks.
Python was not found but can be installed from the Microsoft Store: ...
I kept getting the above error when calling Python in the command-line after upgrading Python, despite adding it to System Environment Variables. As it turns out, Windows secretly maintains aliases - python.exe & python3.exe - in ‘%USERPROFILE%\AppData\Local\Microsoft\WindowsApps’ that encourages Python installations through its Microsoft Store. While this may streamline the installation process for new users, this causes rage to those that want more bespoke configurations.
Thankfully, one can easily disable these aliases once they are made aware of them.
Step 1: Locate the aliases
Search ‘Manage App Execution Aliases’ in the Windows search bar.
Step 2: Toggle off ‘python.exe’ & ‘python3.exe’
A further step is to put ‘%USERPROFILE%\AppData\Local\Microsoft\WindowsApps’ lower in the pecking order in Environment Variables.
I was trying to install a Python package when I encountered the following error:
C:\Users\MATT-THINKPAD\OneDrive - nyu.edu\Documents\fido-1.6.1\fido-1.6.1>pip install setuptools
Defaulting to user installation because normal site-packages is not writeable
Collecting setuptools
Using cached setuptools-75.5.0-py3-none-any.whl.metadata (6.8 kB)
Using cached setuptools-75.5.0-py3-none-any.whl (1.2 MB)
Installing collected packages: setuptools
ERROR: Could not install packages due to an OSError: [Errno 2] No such file or directory: 'C:\\Users\\MATT-THINKPAD\\AppData\\Local\\Packages\\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\\LocalCache\\local-packages\\Python312\\site-packages\\pkg_resources\\tests\\data\\my-test-package_unpacked-egg\\my_test_package-1.0-py3.7.egg\\EGG-INFO\\dependency_links.txt'
It turns out that Windows 11 does not accept file paths over 260 characters by default and users may remove the character path limit by editing the registry.
Open ‘Registry Editor’
Navigate to ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem’
Edit the value date of ‘LongPathsEnabled’ from ‘0’ to ‘1’
