I'd pay top $$$ if someone could show me how to let a mobile Safari user record audio on their microphone and submit it. iOS doesn't permit this in any way, whether it be with getUserMedia or media capture forms. The only way to do audio recording is to build an iOS app just so I can get this one simple feature which is exactly what they want. Repeat this story for a dozen other features as well.

Apple's total opaqueness on what their plans are for the future functionality of their browser certainly doesn't help either.

This is a feature I would really like to have.

I tried to circumvent it a while ago when I was playing with the Web Audio API by allowing an iOS user to "upload" a video, from which I would then extract the audio using decodeAudioData. Unfortunately it returned an error on callback in iOS.

Perhaps it could still work by processing said video on the server and sending back the audio, but keeping everything client-side was my requirement.

Web pages that can access the microphone sounds like an absolutely insane idea to me, but then like I said, web dev is absolutely mental at the moment...

get off my lawn etc.

So Safari doesn't hold the web back like IE6, because the ways it's hold the web back doesn't count because you don't want those features.

Not buying it.

I'm suggesting that the web is fine - its stupid nonsense like javascript access to the microphone that gives the illusion that the web is moving forward, and that some people are freaking out proclaiming the end of days because some ridiculous feature hasn't been implemented.

How is it ridiculous just because it's a feature you don't use?

There are plenty of uses for newer standards, that's why they're created, but it only works if the browsers carry their weight and implement them consistently. Safari doesnt, and is thus holding back the progress, just like IE6+ did.

There are a lot of quirks with Safari that are similar to the way IE6 eventually stopped following standards.

That fact that localstorage doesnt work in private mode is 1 example.

I can see why that'd make someone cross, but it seems in line with how localstorage works + how browsers define their "private browsing" features. On Chrome, for example, when in Incognito mode, you can't undo-close-tab a tab after closing it. Effectively, every tab you open in these "private browsing" modes will sooner-or-later "self-destruct", including all its cookies, localstorage, etc. (iOS?) Safari just chooses "sooner" rather than "later."

If your site relies on using localstorage during the lifecycle of an individual page, you can always replace it with an in-memory mock polyfill if you notice it's missing. There's probably an NPM package for that.

The point of standards for browsers is that you shouldn't need a polyfill just to support a feature (localStorage) in one browser. Ideally, it would just destroy its contents after your private browsing session is done, just like the way (I believe) all browsers treat cookies in private browsing mode.

Sure, what I'm saying is more that localStorage doesn't have the standards equivalent of an SLA guaranteeing it'll work for the "within the lifecycle of one page" use-case. Apple, I think, are just being opinionated (and pushy) here: they think the right way to tell a web-app "your localStorage won't save" is to undefine the API, making trying to write to or read from localStorage raise an exception, so that your app is then forced to decide whether it can go on without localStorage (by handling the exception, or by using a polyfill which does the same) or that it can't (by just telling the user "don't use this page in Private Browsing mode, doofus!" and stalling out.)

It's certainly not the approach everyone would be happy with, but it allows developers much more flexibility than the contrary case, where private browsing is a silent effect that might make apps do very stupid things (like, say, downloading the same huge asset bundle into localStorage over and over.)

> downloading the same huge asset bundle into localStorage

This would happen anyway no matter what storage or cache is used since all data is cleared after private browsing session is over.

Breaking localstorage (with an over-quota error) is not the way to deal with this. Polyfills are just more crap in complexity and downloaded bytes to compensate for a browser's issues.

It would be much better to have a navigator.isPrivate flag enabled so apps can check the environment accurately, not guess based on whether certain APIs work or not. It's not about SLAs but supporting standards. Deleting client-side data is all that private browsing needs to do.

That's not sooner vs later. That's breaking functionality.

Private mode means deleting the data, not disabling the functionality. Chrome and the rest handle it correctly.

Where is the W3C standard for private browsing mode?

There isn't one, that's why it should behave like a normal browser (from the web dev perspective) even while in private mode.

That doesn't follow. If it literally behaved like a normal browser that would break the privacy guarantee of private mode. In fact you could argue that browsers that implement localStorage in private mode are the ones who are not standards compliant.

From the Web Storage spec: "[localStorage] is designed for storage that spans multiple windows, and lasts beyond the current session."[1] Thus if a browser is discarding localStorage prior to the end of the current session, it's explicitly against the spec.

This is more than academic. If apps aren't written to explicitly use ephemeral storage then they may not function as expected in private mode, like, say, unexpectedly causing data loss.

[1] https://www.w3.org/TR/webstorage/

Web development relies on browsers. There is nothing mental about this.

Service workers are another example of a feature that is missing in Safari. And an important one for offline support.

Yeah, can't wait for web apps to drain my battery when I'm not using them too.

Web should be just HTML/CSS, no JavaScript at all, so no need for service workers.

Web components, Progressive Web Apps, Fetch, etc.

Service Worker!!!!

Its absence is a crippling limitation.

+1. This is the main problem right now, especially since web workers are a workaround for anything blocking the main thread, like some local storage.