Seriously, what horse are you backing where iOS Safari is compared to IE6?!? What oh-so important feature you simply must-have, that would even begin to signify that iOS Safari is "holding back the web"?
The web dev world is absolutely mental at the moment...
Apple's total opaqueness on what their plans are for the future functionality of their browser certainly doesn't help either.
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.
get off my lawn etc.
Not buying it.
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.
That fact that localstorage doesnt work in private mode is 1 example.
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.
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.
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.)
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.
Private mode means deleting the data, not disabling the functionality. Chrome and the rest handle it correctly.
Service workers are another example of a feature that is missing in Safari. And an important one for offline support.
Its absence is a crippling limitation.