I haven't dug into the history to see if this is really how it happened. I'd actually feel better if it wasn't true but it's the thought that occurred to me when I noticed the scroll fade effect becoming popular.
I feel like the scroll fade fad is misunderstanding layered on bugs, turtles all the way down.
Once upon a time, developers implemented lazy loading of images, to save bandwidth. However, some developers implemented it poorly, waiting until the moment an image is scrolled on-screen to even start loading it, leading to a visible blip as you scroll.
(The better way would be to load an additional pageful of images beyond the current scroll view, which would provide enough time to load before scrolling into view at least most of the time. However, this doesn't maximally save bandwidth and some developers don't make good tradeoffs between diminishing returns on saving bandwidth vs. visibly degraded UX.)
Then, designers saw the blip-into-view effect, thought it was an intentional visual effect (rather than an artifact of poorly implemented lazy loading), but thought, oh, I'll fix it so it looks nice, with fading.
And here we are with a dumb visual fad originating from a bug without realizing it was a bug.
They're isolated by website but the tabs are not isolated from each other, like in Safari (in private browsing).
This distinction matters, if you primarily use private browsing, and have lots of tabs open from a site (say, Wikipedia, or Reddit, or pick a social networking service you don't want to track you by cookie[1]) - that particular website will know all the different tabs are from the same user potentially over a long stretch of time if at least one of those tabs remains open.
[1] Ad networks also track by IP address, so you need to take measures there too.
In Settings, on the General tab, for "Safari opens with", select either "All windows from last session" or "All non-private windows from last session".
Two little-appreciated privacy features in Safari not mentioned in the article:
Each private browsing tab has its own cookie / data bucket[1]; and
Private browsing tabs and windows are preserved across restarts. (This is optional and can be configured to forget them upon restart.)
These make it practical to use private browsing for nearly all browsing, which isn't really the case in other browsers, where private browsing is clearly designed as an occasional-use thing. (And of course if you use private browsing for most things, you can still open regular windows for sites where you want to stay logged in.)
[1] If a link or script in a tab opens a new tab or window, then they share the same cookie bucket. This preserves compatibility with sites that require such a flow.
I've been using HTTrack for almost two decades to create static archives of a yearly website for an annual event.
It doesn't do the job 100% but it's a start. In particular, HTTrack does not support srcset, so only the default (1x) pixel-density images were archived (though I manually edited the archives to inject the high pixel-density images, as well as numerous other necessary fix-ups).
The benefit of the tool is fine control over the crawling process as well as which files are included. Included files have their URLs rewritten in the archived HTML (and CSS) to account for querystrings, absolute vs. relative URLs, external paths, etc.; non-included files also have their URLs rewritten to change relative to absolute links; thus, you can browse the static archive, and non-included assets still function if they are online at their original URL, even if the static archive is on local storage or hosted at a different domain than the original site.
It was more work each year as the website gradually used script in more places, leading to more and more places I would need to manually touch-up the archive to make it browsable. The website was not itself an SPA, but contained SPAs on certain pages; my goal was to capture the snapshot of the initial HTML paint of these SPAs but not to have them functional beyond that. This was (expectedly) beyond HTTrack's capabilities.
There is at least one exception: On form 1040, you have a yes/no option to redirect $3 to the presidential election campaign fund. This does not affect the amount of your taxes; it's a personal funding choice.
I think it's a desperate attempt to downplay the severity in any way plausible, taking advantage of the fact that credit card numbers and social security numbers have been mythologized in the American consciousness as nearly-mystical totems of identity and security, as part of the "identity theft" meme, even though they play little role in actual information security or privacy.
100% of the energy becomes heat eventually. For a typical trip, this happens by the trip conclusion. (And also each time the car pauses, such as a stoplight.)
For the trailer-on-hill example, it concludes when the trailer (eventually) is towed or rolls down the hill and comes to a rest from friction.
The weighted trailer is being used like a battery and modifies the situation in the same way as if it were a hybrid car (non-plug-in battery that recharges through regenerative braking and/or directly from the ICE).
Based on the release of multiple emulators in the App Store in the past few days (including Delta which looks like it is here to stay), it looks like I got this wrong. My original comment made sense to me based on my reading of the rules, but it looks like they really are allowing open-ended emulators that can load ROMs from anywhere.
I think mainly the ability to download additional games, and more specifically, games emulated from a different platform rather than game content written as HTML/JavaScript.
I may be wrong about the bundling in terms of the collection, but I still think this is more about Apple's general stance on "stores within an app", and the rule change is folding retro game emulators in as another exception to that, and not a change primarily about emulator allowability in general.
The emulator change is a minor rule change about bundling and is not what many of the reactions to the change think.
What people seem to think this means: Open-ended retro game emulators like Snes9x and Dolphin are now allowed. (I don't think this is correct.)
What the change is actually doing: If you are the licensed publisher of a retro game collection, you can now offer them in one app (including perhaps downloading additional games added to the collection later) instead of splitting them into individual apps. Each game must be individually vouched for.[1]
What is not changing: "Emulators" have long been allowed if the emulated code is bundled with the app and it is officially licensed.
"4.7 [...] You are responsible for all such software offered in your app, including ensuring that such software complies with these Guidelines and all applicable laws. [...]"
and
"4.7.4 You must provide an index of software and metadata available in your app. It must include universal links that lead to all of the software offered in your app."
Outlook is a once-great product that has been left to rot by a Microsoft with little lineage to the great company from the 90s and early 00s that created it.
Outlook debuted Cached Exchange Mode in the early 00s, popularizing "offline first" before it was known as that.
Now: The "new" Outlook can't even show folder unread counts correctly, even when fully online. It seems to only load a small subset of messages locally, only populating folders when you scroll past the point it loaded. (In classic Outlook, this was a setting—I understand loading all mail was not enabled by default—but it could be enabled. No longer.) It sometimes gets stuck where it won't show new mail until restarted. (Gmail has this bug too.) It forgets open mail windows when restarted. It forgets expanded folders in the folder pane when restarted (but only sometimes).
Microsoft removed the ability to show the mail/contacts/calendar navigation bar below the folder pane, and forced it to be shown on its own huge vertical bar, almost all of which is wasted space. For good measure, they did this in classic Outlook as well as "new" Outlook. There was massive backlash to this, and Microsoft plowed forward anyway. On Windows there is/was a registry setting to revert this (but intentionally, no user-facing setting). I have not checked on Mac.
To the sibling comment: Outlook for iOS is indeed great, probably only because it was an acquisition. It is not in Microsoft's DNA to build an app like this themselves anymore.
As an admin: Microsoft seems to redo the Office 365 admin interface every 2-3 years. It is an incomprehensible mess. I am also a Google Workspace admin for the past several years, and theirs is far better, and it's more or less stable over the long term.
Office 365 has been hacked by state actors recently.
I still like the Outlook UI and feature set better than Gmail (despite the "new" Outlook being a major regression), so I begrudgingly stay with Outlook/Exchange because I dislike it less than Google Workspace.
Fastmail does not give signs that they are a relevant company—they created JMAP and basically did nothing with it. Why not make a first-class Windows/Mac client, offline first, with powerful organizational features, like the Outlook of yore? Or at least, contribute to adding first class JMAP support to Thunderbird? This is your sole business.
I think the legal concept of "beneficial ownership" is the intent here: We want to know the ultimate (natural) person(s) who control the app's assets and for whose benefit the app is monetized.
There is no simple rule that can be applied at scale. Determining beneficial ownership requires a case-by-case review of not just the chain of legal ownership, but management, contracts, incentives, etc.
Any fixed rules can be gamed. For example, a company could license out its name as a "franchise" who is legally independent but whose franchise contract has so many arms of control that they de facto function as a single company. Another example is that a majority donor of a nonprofit controls the nonprofit even if they have no board seats or de jure power to appoint or fire board members.
Both Gruber's "fake" explanation and the "computational photography" explanation are likely wrong.
There's a third explanation: It's almost certainly an accidental use of panorama mode.
- It's two poses, not three, with the stitch somewhere on her back.
- The shop attendant was taking the photos. Coates wouldn't know if panorama mode was accidentally selected for one.
- The Photos app info pane doesn't flag that a photo was taken in panorama mode. (But you can infer it from the nonstandard resolution if you know of this possibility.)
- The top of the right mirror is very slightly curved, indicating the perspective correction of panorama mode. (Not the railing, which is likely curved in real life, but the actual mirror frame.) It's barely visible to the naked eye, but you can verify by drawing a straight-edge with a lasso selection tool.
I replicated it at home with two mirrors (technically, one mirror and one iPad with the front-facing camera) and my iPhone in panorama mode, and a kitchen timer for "proof" (demonstrates over 2 seconds apart). You can barely see the panorama stitch and wouldn't notice it unless you were looking for it: https://mastodon.social/@jeff_tyrrill/111509692643373685
There does not appear to be officially. No RSS feed is declared in the main index page metadata, and adding /feed to the URL doesn't work as it does with "newsletter" pages.
However, by poking around in my browser debugger's XHR calls, it only took me a few hours to write a translator from Substack's (not-publicly-supported) JSON-based browser API to RSS.