#Safari vs firefox may 2019 android#

Since Google doesn't respect that and ignores all/most input on the non-standards it's pushing out at neck-breaking speed, you can see where it's going if you 'allow browser choice on iOS'

#Safari vs firefox may 2019 android#

> and respecting a user's browser choice via Android or Google apps. You've already started your priorities loud and clear We also need to order the issues in terms of priority and how damaging they are to the wider ecosystem. > It's also really important to be specific as to why the behaviour is harmful to end consumers. Or maybe look at the status of the APIs you so ardently defend. Not just repeating Google's talking points. You could start by actually looking around and figuring out these things yourself, too. If you're willing to type this up in detail. > they have to be well understood and documented. You have a very specific, very narrow beef that you're pursuing.ДЄnd it's parroting Chrome's propaganda basically word-for-word both on the website and here in the comments. It means you're not really focusing on the open web. Currently our main focus is user's browser choice > We're happy to target anti-competitive behaviour from any operating system or browser if it relates to the open-web. PSA: there exists an API to handle cookie without using okie, that is currently only supported by chromium.

Honestly, at this point any time I see any public Chrome person write anything I immediately assume it's a distortion of reality at best and a blatant lie at worst.

There's literally zero response on that from who is now gaslighting Safari in the comment above, and presenting these API additions as fait accompli. (I made a number of comments on that issue) As is, we're generally against this one for the time being We would really rather people use WebGL if you want fast/efficient filters. There are a bunch of implementation concerns here (and mentioned on that issue) with regards to availability on various native 2d backends. Someone linked 'Request for position' on these APIs. If/When these issues are resolved, we may see them implemented in these browsers, too. Not to mention that the quality of some of these so-called specs is very low. Same goes for other hardware APIs: from the point of view of both Safari and Firefox those specs have security and privacy holes the size of Jupiter. This means that Safari's stance may also change. Just three years ago Firefox's position was also largely negative due to unresolved security issues: It's possible those issues are now resolved, that's why it's making its way into Firefox. Before that it's just some browser's prototyping stage, no matter how many times Chrome will tell you otherwise.ДЄccording to chromestatus, WebMIDI now has positive position from Mozilla and negative position from Safari: They are not really on a standards track for now, they are 'Draft Community Reports' or somesuch.ДЇor something to become a standard that something needs to independent implementations. Both Firefox and Safari view them as harmful in their current form.