Bug filed here, simple repro here.
I appreciate that service worker is here. I appreciate that they are making progress on PWA support. It's good to see. But there are some longstanding HTML5 issues in the browser that need to be fixed. Would really appreciate some Apple devs solving it; the fix is conceptually simple: fire HTML5 audio .ended event when audio finishes playing, even if the screen is off or app is in the background.
And, it still doesn't work on iPod Touch, because for some reason Safari there claims it doesn't have a microphone. (It does.)
Perhaps you have flaky authoritative nameservers?
I was confused by this sentence, but it actually says "HTML <IMG> tag" (the "<IMG>" part of the text is unescaped, and does not render). Meaning you can use <img src="video.mp4">
"But we already have <video> and animated webP and..." is addresed in depth in the linked article: https://calendar.perfplanet.com/2017/animated-gif-without-th...
I wonder what other things we could do to H.264 to further improve the standard while aiming to be patents free within a foreseeable time frame. And act As the baseline of the web to move forward.
"A service worker registered by an example.com iframe inside a webkit.org page will be able to communicate to all service workers and clients that share the same (webkit.org, example.com) partition, but not to any other example.com or webkit.org client. A network load made by a (webkit.org, example.com) service worker will use the same cookies as if the network load was made in an example.com frame embedded in a webkit.org page. Similarly, private browsing mode is enforced in a service worker by partitioning service workers according the browsing session."
For example: sending a PWA to background causes it to die. For my music player app, this is a showstopper; the audio stops playing.
Bringing the PWA to the foreground causes a full refresh. Again, showstopper for my PWA.
This led to us needing to tell our users to NEVER add the page to the homescreen (pwa or otherwise) or the app will stop working, which confused many and made other suspicious (IMO rightly so, that's such a fucking weird thing to have to specify!)
Are they really worried mobile websites will overthrow the App Store in popularity?
Sometimes I really feel Safari is the new IE.
That being said, it does really suck, and it's something they NEED to get solved before the possibility of taking Safari and iOS seriously in the web-app space happens.
As it relates to audio apps -- not generally.
The capabilities have grown over time as Safari on iOS supports more PWA features, but the article seems to be framing this as a new ability to install apps, when that isn't very new at all.
Of course, there are going to be plenty of sites that still consider their fancy font to be more important than the actual text it's rendering...
use the `drawImage` function to draw the image scaled to whatever size you want, then just call any of the APIs that you want to get either ImageData, a base64-encoded-URI, or a PNG Blob resized.
Any resizing of a jpg to another jpg is going to incur double compression isn't it? Sure there are ways of mitigating it using various sampling and resizing algorithms, but it's not going to be perfect, and there is no "one-size-fits-all" best algorithm.
What would a "browser API" provide that you can't already get with canvas?The only thing I can think of is customizable resize algorithms, but I'd rather have the option to change that for a canvas, rather than a specific "resize this image API".
Apple is trying to create a closed ecosystem with the browser and I for one will not just let that go. Add all the features you want! You'll be treated like IE until you start playing nice with others.
Does this mean they’ll finally go back to the style tag entry they used to use - the same one Chrome uses today? That would be a great help!