Live data from Hacker News

iOS404

ios404.com

41–50 of 101 posts

Re: iOS404

#41
Eh. The thing I miss the most: stop reloading pages/tabs when switching back to safari (or any browser, since it's all the same webview).

If apple wants to treat the web like documents, that's fine, but then don't make it suck like an app. If a page is loaded, there is NO reason to randomly reload it because iOS deems it has been too long. Maybe it's a general problem with iOS killing apps in background, I don't care, it sucks.

Re: iOS404

#42
post #23

This site should really include Mozilla's position on the spec too. Google shipping some, potentially harebrained, idea in Chromium doesn't mean that Safari and Firefox MUST also ship it. There should be links to relevant entries from https://mozilla.github.io/standards-positions/ and https://webkit.org/standards-positions/ This is a good example of how the chromium monoculture hurts the web. It ends up being Google'…

Geez was staring at this trying to find icons and didn't realize on mobile the bottom drawer wasn't just part of the browser. Good stuff. Took this fun milk carton concept to a usable next level.

Re: iOS404

#44
post #36

[flagged]

Ah yes, the browser fingerprinting enabled by checks notes auto focusing an element? It's OK to acknowledge that sometimes Google does good stuff.

It’s also important to remember that Google is an advertising company.

And some features e.g. long lived first party cookies which are used for retargeting serve no legitimate purpose except to support advertisers.

Re: iOS404

#45
post #23

This site should really include Mozilla's position on the spec too. Google shipping some, potentially harebrained, idea in Chromium doesn't mean that Safari and Firefox MUST also ship it. There should be links to relevant entries from https://mozilla.github.io/standards-positions/ and https://webkit.org/standards-positions/ This is a good example of how the chromium monoculture hurts the web. It ends up being Google'…

I think the feature to compare could be made a little more obvious - I can see why they would default to Chrome (both the most popular browser & also the one that shows the starkest difference), but tbh I find the most interesting comparison being against macOS Safari - that list seems really surprising to me.

This also would of course be even nicer if you could define any browser as the "target" (e.g. compare Chrome -vs- Firefox) but then that wouldn't serve their very nice domain purchase as neatly.

Re: iOS404

#46
The one browser API I wish every browser would support is the File System Access API.

Because with it, we can offer users to hold their data natively on their devices. Instead of storing everything in the cloud.

So far, I think only Chrome on the desktop supports it. Here is a nice demo:

https://googlechromelabs.github.io/text-editor/

A text editor that works just like a native application.

Re: iOS404

#48
post #27

I guess that they are missing for good reason? Web notifications? Sparsely useful, 99% is just some clickbait website trying to feed you junk. Thanks Apple! The website look cool tho.

One that stood out was the audio element being able to read the volume, but not set it. Apple has always had the stance that user preferences like this should only directly be changed by the user, not by an application. There are 2 convenient buttons on the side of my iPhone, there is no need for any website to ever be able to mess with my volume settings.

Re: iOS404

#49
post #28

It seems wrong to mix and match actual accepted standards with things that only Chrome implements which are not standards. Should iOS adopt [feature] because Chrome has it, or why else is it on the list? What benefits am I missing as a user? As a mainly desktop Firefox user, any time I have a web bug my developer colleagues asks me to try Chrome instead because they only develop and test in Chrome. I would say if we…

You're saying some of the 404s should be 400s.

Re: iOS404

#50
post #12

Earlier quoted context omitted.

Why would they belong in a platform-specific app but not in a standard-based web app? Because Apple can't get 30% out of it?

The web lacks intentionality that installed 'native' apps have. You search for a recipie and land on a random blog, executing untrustable code from a countless number of third parties, clicking "I agree" on that modal that says "LiveLaughLove blog and out 1382 partners value your privacy". Native apps have a much higher level of friction at multiple points that helps balance the higher level of access they get.

The APIs coming with a security or privacy risk are always gated by a permission prompt on the web (contrary to platform-specific apps). Safari has gone even further by only allowing some of them (e.g. Push notifications) for installed web apps.

These APIs are also much more restricted than their proprietary-ecosystem equivalent.

Overall, web apps having access to these features in Chrome are an order of magnitude safer than platform-specific apps.

Post reply on HN