A parallax effect has also long been possible with CSS 3D transforms. Here's a demo,[0][1] from the same person who made that CSS 3D FPS a while ago.[2]
That sounds like a lot of work. If you rebase A on main then B on main, you end up having to resolve A's conflicts on main twice. But if you stick with merge commits, A's conflicts are handled once in the merge from main.
The list is pretty small, so I wonder if this just drives users to other, smaller platforms. That said, the list of platforms includes all the biggest offenders of engagement optimization, so it feels more like a ban of addictive social media than all social media in general. But it's also interesting they ban messaging apps, which I assume parents use to keep contact with their kids.
It'd be nice to see screenshots from real mobile browsers.
Currently, it is not possible to use viewport-fit=cover to show content under the status or address bars in iOS 26 Safari,[0] even though ironically Apple introduced it for the iPhone X.[1] viewport-fit=cover only has an effect when the site is added to the home screen, where like Android it determines whether the site can render under the home bar, but the status bar remains black.
Is this surprising? Websites have long been silently writing to disk, for cache, cookies, and blobs. OPFS just provides a file-system-like API for ultimately the same functionality
"On Chrome and Safari, OPFS supports very large files, up to 60 % of disk space, which is more than sufficient to avoid the page cache on most typical systems, as even a small disk size of 64 GB would allow us to create a 38.4 GB OPFS file."
I am indeed surprised to learn that a random website can write a file that takes up 60% of my disk. Is this obviously a capability of Web browsers?
Not only that, but they don't even provide any visibility into what's being stored. Firefox developer tools doesn't even have OPFS browser functionality. IIRC I even saw some stuff about going out of the way to make it inaccessible by the user.
There's a whole trend with websites not uploading anything to their servers due to privacy and whatnot, where do you suppose the data is being saved for repeat visits...
You make a reasonable point, while kilobytes might be too little it probably shouldn't be 30gb. 5gb might be ok. In the settings it should be possible for the user to set their own limit. I am not familiar with browser storage but there is hopefully a mechanism to inform the user that their limit might not be enough.
I think that when I install an app, typically it will tell me up front how much disk space is required. For example, in the Mac App Store, the size of the app is at the top of the page.
> Should those also be limited to a few MB?
I also want to highlight that many/most websites that think of themselves as apps are at odds with their users in that perception. As an engineer, I know full well that e.g. the URL https://homedepot.com is powered by a sophisticated set of apps. But most users think it's a website.
This is important because people do & should have a different relationship with software they have chosen to install on their machines and websites. Yes, I know e.g. Figma.com does complex client-side stuff. Every Figma user would click a dialog to grant permission for it to do what it needs to do.
The problem is the current state of the art is that literally any website can spam up your disk and you don't even know. If I visit the website for a local radio station, or an e-commerce site, or university, or a site that will tell me what time it is now in a different time zone...I do not expect that it will download tons of data and store it on my disk in case I come back. That some engineers think that is reasonable is why the browser sandboxes need reinforcement.
I'd be willing to bet most (younger?) users don't know what the difference between an app and a website is. Can't really blame them when the line between them has been blurring more and more over time. I think a growing number of users wouldn't even mention installing as a differentiator because you install PWAs (except on iOS).
Anyway, I think an important bit of information that was lost here is that browsers automatically purge data so that your disk doesn't fill up. If you're running low on space it will clean it up for you to make room.
> I do not expect that it will download tons of data and store it on my disk in case I come back. That some engineers think that is reasonable is why the browser sandboxes need reinforcement.
It's a reasonable thing to do for an app, so why not a website/PWA? Video games are a pretty good example where some stream assets while you are playing so that you don't have long install/update times. Getting in game faster is more important.
Ten movies streaming across that, that Internet, and what happens to your own personal Internet? I just the other day got... an Internet [email] was sent by my staff at 10 o'clock in the morning on Friday. I got it yesterday [Tuesday]. Why? Because it got tangled up with all these things going on the Internet commercially. [...] They want to deliver vast amounts of information over the Internet. And again, the Internet is not something that you just dump something on. It's not a big truck. It's a series of tubes. And if you don't understand, those tubes can be filled and if they are filled, when you put your message in, it gets in line and it's going to be delayed by anyone that puts into that tube enormous amounts of material, enormous amounts of material.
As the article notes, effects (at least as described in the article) are already possible in JavaScript using generators, as long as every calling function is a generator, which I assume the author finds problematic because generators are cumbersome.
I was wondering how well TypeScript can type generator-based effects. My hypothesis is that TypeScript can let you compose functions with effects, but it is not possible for it to narrow down that the result from an effect corresponds to the effect (i.e. the result of an effect will be any possible effect result used by the function).
My incomplete, untested attempt in TypeScript[0] tries to implement `enumerateFiles` and `withMyLoggingLibrary`. The type errors demonstrate TypeScript's limitation that it can't associate an effect call with its result.
I'm curious about that "magic doc" feature. Is that meant to go in CLAUDE.md or a project file? Does the file need to be mentioned during the session or does Claude automatically search for all mentions of the "magic doc" header in the project?
[0]: https://www.keithclark.co.uk/articles/pure-css-parallax-webs...
[1]: blog: https://www.keithclark.co.uk/articles/pure-css-parallax-webs...
[2]: https://www.keithclark.co.uk/labs/css-fps/
reply