Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS404

ios404.com

Post reply on HN
Print view View original

81–90 of 101 posts

Re: iOS404

#81

Post by hasanhaja »

isodev wrote: post #62
buildfocus wrote: post #13

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…

We already have a diverse ecosystem of platforms which are capable of using hardware components for various experiences - we call them "the OS". It comes with a security model, permission prompts and all kinds of bells and whistles (it's a mature platform, developed for decades). The browser (agent) is a native app designed to allow users to access and navigate web resources (we call them pages or documents). Pages c…

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 apps for. Compared to iOS, the web platform is more secure with better privacy controls [1][2], and that feels like a better place to invest our energy.

[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26

Re: iOS404

#82

Post by hasanhaja »

threeseed wrote: post #31
bouncing wrote: post #24

Earlier quoted context omitted.

That's more or less how HTML has always been. Before Chrome, it was IE just adding stuff. Before IE, it was Netscape just adding stuff. JavaScript itself is just a browser adding stuff. Like it or not, W3C standards have always been reactive to what browsers are already doing. And what's really remarkable about this list is that quite a few are supported on Safari on Mac, just not on iOS. Like autofocus. It's just a…

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.

> That doesn’t mean that we should just adopt any nonsense that Google comes up with.

That's a fair statement. Conversely, why should we put up with Apple stifling the web platform? Especially when there's strong evidence to show this is motivated primarily by profit rather than the user experience [1][2].

[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26

Re: iOS404

#83

Post by hasanhaja »

joshstrange wrote: post #77

I’m seeing a lot of “draft”, “candidate”, “recommendation”, and “other”. Aka, I’m seeing a lot of bullshit. Yes, Apple has dragged its feet on standards but things that Chrome just decided on by itself are not standards. A number of the partially implemented (on iOS) things (like clipboard or volume) have legitimate privacy concerns or UX concerns. I don’t want a website to read my clipboard, I don’t want a website t…

I'd highly recommend this document to establish the scale of impact these different vendors have: https://open-web-advocacy.org/walled-gardens-report/

Google is definitely not in the clear, but Apple's anti-competitive practices is much more damaging to the open web.

Re: iOS404

#84

Post by isodev »

hasanhaja wrote: post #81
isodev wrote: post #62

Earlier quoted context omitted.

We already have a diverse ecosystem of platforms which are capable of using hardware components for various experiences - we call them "the OS". It comes with a security model, permission prompts and all kinds of bells and whistles (it's a mature platform, developed for decades). The browser (agent) is a native app designed to allow users to access and navigate web resources (we call them pages or documents). Pages c…

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 features on the list) will not help us towards an open platform. On the contrary, it will only worsen the dependence on a handful of corporations that can afford to invest to build a browser. Remember, even Microsoft couldn't afford to continue working on their own engine.

As a developer, I care very deeply about being able to make my apps and experiences available to "all the platforms" but shifting the cost of compatibility into userland is not a long term solution. Just put yourself in the shoes of a traveller, 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.

Re: iOS404

#85

Post by hu3 »

madeofpalk wrote: post #76
agust wrote: post #74

Earlier quoted context omitted.

So they can make it to work for platform-specific apps that they tax 30%, but can't make it to work for interoperable web apps which they can't tax. How convenient.

Safari already supports a permission-less file system API with a very similar security model to iOS's filesystem access. https://developer.mozilla.org/en-US/docs/Web/API/File_System... https://webkit.org/blog/12257/the-file-system-access-api-wit... It's able to support this because the 'file system' is scoped specifically to that origin, and doesn't allow access to any aribtary location on the file sytem, just like i…

Your parent comment point still valid.

If Apple made arbitrary file access work for apps [1], surely they could make it work for Safari. But apps pay 30% and websites don't, so it's easy to conclude why they don't want to.

[1] https://developer.apple.com/documentation/uikit/view_control...

Re: iOS404

#86

Post by pjmlp »

K0nserv wrote: 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'…

With the help of a generation of developers hating Microsoft and IE, Google has managed to turn the Web into ChromeOS.

Re: iOS404

#87

Post by guipsp »

mikeger wrote: post #26

How iOS would support `::selection` with the tap-based interface?

iOS still supports selection, and as such it is not unreasonable to desire the ability to style it, or react to it.

Re: iOS404

#88

Post by guipsp »

Aaargh20318 wrote: post #48
dmaa wrote: 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.

The website would not be able to mess with your volume settings. The implication of this choice by apple is that you cannot play two sounds at different levels, for example.

Re: iOS404

#89

Post by shalanah »

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

Re: iOS404

#90

Post by joshstrange »

hasanhaja wrote: post #83
joshstrange wrote: post #77

I’m seeing a lot of “draft”, “candidate”, “recommendation”, and “other”. Aka, I’m seeing a lot of bullshit. Yes, Apple has dragged its feet on standards but things that Chrome just decided on by itself are not standards. A number of the partially implemented (on iOS) things (like clipboard or volume) have legitimate privacy concerns or UX concerns. I don’t want a website to read my clipboard, I don’t want a website t…

I'd highly recommend this document to establish the scale of impact these different vendors have: https://open-web-advocacy.org/walled-gardens-report/ Google is definitely not in the clear, but Apple's anti-competitive practices is much more damaging to the open web.

That has nothing to do with my point that these aren’t web standards in most cases. Walled gardens are a separate concern. You can’t point to things that aren’t standards and talk about walled gardens.
Post reply on HN