Live data from Hacker News

iOS404

ios404.com

91–100 of 101 posts

Re: iOS404

#91

Hi all - this is quite fun! I'm Shalanah. I made iOS404.com. A couple of feature notes: - Compare to other browsers by clicking on the Chrome icon to switch to FF for Android or Safari Desktop (or a combo). - Select or deselect specification by clicking on the filter icon. On what's to come: I'm looking to add MDN features next. There are wayyyyyy more missing iOS features there. Thanks! -Shalanah

You might want to ping HN admins (email works best in my experience) to reposition this post in HN since it has been nuked out of the atmosphere for some reason. It is nowhere to be seen in HN listing.

For example this other post is older (6 hours ago), with less points (70) and less comments (34), and yet it shows on top 12 of HN:

    12. Show HN: a Rust based CLI tool 'imgcatr' for displaying images (github.com/silinmeng0510)

Re: iOS404

#92
post #4
post #3

Looks awesome! While the visualization is cool, I hope some of these will remain "not found" indefinitely. Just because we can stick everything into a web-spec, doesn't mean we should.

Me too. Device orientation, USB, Bluetooth, vibration, they don't belong in a web app.

I didn't understand why these APIs existed until I used ESPHome. It can use the Web Serial API to flash an ESP32 board using Chrome + a USB cable.

Re: iOS404

#93
post #91

Hi all - this is quite fun! I'm Shalanah. I made iOS404.com. A couple of feature notes: - Compare to other browsers by clicking on the Chrome icon to switch to FF for Android or Safari Desktop (or a combo). - Select or deselect specification by clicking on the filter icon. On what's to come: I'm looking to add MDN features next. There are wayyyyyy more missing iOS features there. Thanks! -Shalanah

You might want to ping HN admins (email works best in my experience) to reposition this post in HN since it has been nuked out of the atmosphere for some reason. It is nowhere to be seen in HN listing. For example this other post is older (6 hours ago), with less points (70) and less comments (34), and yet it shows on top 12 of HN: 12. Show HN: a Rust based CLI tool 'imgcatr' for displaying images (github.com/silinme…

I just emailed HN via the contact below. Not sure if that's the right method -- thanks the tips!

Re: iOS404

#94

Cute. Some of these are already/soon out of date. Safari Technology Preview just shipped View Transisitions API https://webkit.org/blog/15260/release-notes-for-safari-techn... In practice, I've never missed an API on Safari for building websites that customers ask for. I have missed Chrome dragging it's feet on CSS properties like Snap Points or backdrop-filter. The difference in culture couldn't be any more apparent…

The text copying is a good point.

The text is actual text.

I must have disallowed selecting for the swiping feature to work. Definitely something I should look to revert or allow for copying buttons.

Re: iOS404

#95
post #84

Earlier quoted context omitted.

The desktop might be quite diverse, but the diversity on closed, proprietary ecosystems like iOS is controlled by one party. Either, we open up iOS so anyone can distribute apps without Apple being the ultimate authority (like on MacOS), or we enrich a much more mature platform (the web) that we already have to be more capable so we can deliver very similar experiences through the web that we currently build native a…

I'm not sure how the close aspect of iOS is relevant, it feels like a strawman. You say the web is more mature, to which I reply that this is the same circumstance as leaving one browser to become dominant (which we already did). In a perfect world, having a closed option would be "one of the options on the table" but for the majority of users this is not the case. Introducing WebUSB (or any of the more exotic featur…

The closed aspect directly speaks to how much diversity you can have on the platform. The features (like WebUSB) aren't the drivers for a more open platform, but they highlight what the impact of having no competition does. Opening up the platform will fuel competition and the market can decide what works and what doesn't. At the moment, we just have to trust Apple has our best intentions by supporting/not supporting certain features and standards. However, we know from the work the Open Web Advocacy has done that this isn't true. The primary driver for both stifling progress on Safari and keeping browser competition out is the profits from the App Store [2].

Chrome becoming the dominant browser is also concerning, and they will have to be held to a much higher scrutiny by us and policy makers to ensure they have users best interest at heart [3].

> shifting the cost of compatibility into userland

What do you mean by this?

> struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.

I agree! This is exactly why we can't depend on one organization to dictate what's allowed and disallowed on that platform. On iOS, think about how long it took Apple enabled Apple Pay support for non-safari browsers even though they all had to be WebKit-based.

[3] https://open-web-advocacy.org/walled-gardens-report/#the-chr...

Re: iOS404

#96
post #8

Immense disappointment that I opened up the site on my iPhone's Safari and it renders perfectly fine.

Lol - can't say it didn't cross my mind to use tech that wouldn't work on iOS :)

Re: iOS404

#97
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'…

[deleted]

Re: iOS404

#98
post #60

Earlier quoted context omitted.

All the dangerous ones come with comprehensive permissions prompts, and browsers can offer options for don't ask again/never ask etc, so if you're not interested there's still little downside to those being available for those who are. Personally, I've found a bunch of these super useful, as user and a developer. Being able to use tools like https://www.espruino.com/ide/ to play with hardware straight from the web is…

I would guess that most regular users are very quick to click “Allow” on a dialog box. I like how macOS handles unidentified apps where you have to navigate manually to the security settings to allow an unidentified app.

For dangerous ones like WebUSB you can't just click 'Allow' - after granting permission, it shows you a list of connected devices, and you have to actively select the device you want the website to access, and then approve it.

Re: iOS404

#99

Earlier quoted context omitted.

That doesn’t mean that we should just adopt any nonsense that Google comes up with. Also autofocus on page load is a terrible idea on iOS as it automatically brings up the keyboard. No one wants to switch between web pages and suddenly have to wait for the keyboard to appear each time on page load.

Android has handled this fine since approximately forever. It focuses the element, but doesn't necessarily bring up the keyboard until you tap it.

Pretty poor UX.

Expectation on iOS is that anything that is focused you should be able to type into.

Re: iOS404

#100
post #51

We’re crying at a pretty high level IMO. So many cool APIs are available now in all browsers that enable us to build things that used to be impossible on the web. So don’t only focus at what isn’t here yet.

If problems aren’t called out they can’t be solved.

I don't really see it as a problem that other browsers don't immediately implement non-standard, underspecified APIs some Googler made and put into Chrome to get a promotion.

It's a problem when Apple refuses to implement standards because it hurts their 30% cash cow monopoly, but most APIs on that site aren't that.

Post reply on HN