Now I have to take a really hard look at switching back to Firefox, and that would be a downgrade in almost every regard I care about. Pity.
My main concern today is actually a matter of trust. Mozilla has had enough privacy-related debacles and questionable decisions that after each update, there is a lingering doubt in the back of my head whether I need to crawl through some settings again or worse, edit obscure config keys to keep it from doing what it shouldn't have been doing in the first place. It's the same feeling I have after a Windows update, albeit to a lesser extent.
I used to be a huge advocate for Firefox. My name is one of the many thousands of donors in their NYT ad from 2004. It pains me to say that these days, Firefox feels somewhat user hostile.
If I do find myself leaving Safari, it's merely the least-bad choice from a continuously shrinking field of options.
I'm not asking about ad- / content-blockers, because that issue has been discussed many times and there's no value in rehashing that discussion. I'm asking about OTHER TYPES of extensions.
There are other extensions delivered through the App Store you can install. For example, there is a uBlock extension there.
Regardless, it seems like a big thing to omit from the notes.
Then performance problems of extensions injecting and running a pile of JS into all pages.
But yeah, I am not looking forward to losing ublock. I (Safari fanboy) will probably delay updating as long as possible.
It was in the notes. That's the line.
https://caniuse.com/#feat=pointer - now you can use one unified event capture everywhere, instead of having to choose between "click" and "touch"!
For example, if you want to roll your own "drag" event for a given element, the API allows you to do this without reference to document or a parent container element. You can just declare that the element currently receiving pointer events capture subsequent pointer events until you release it.
Additionally, the API naturally lends itself to patterns that can easily be extended for multi-touch situations.
I'm quite curious which developer led the charge for this API and how they warded off committee meddling by people who lacked knowledge about the benefits of this approach.
In my experience writing a component suite I have found I don't use touch[a-z]+ events that much (just like mouse[a-z]+ events don't get used much either).
I would be very careful before believing the promise of Pointer Events, unless you need to be on the bleeding edge for some reason. When I first used Pointer Events, there were heaps of corner cases that bit me hard. I would be especially careful if using them with virtual Dom updates or very dynamic pages - one of the worst pain points was issues with events when elements were deleted/replaced.
What does vdom diffing / dynamic page content have to do with using pointer/touch/mouse events?
If anything, the last scenario you describe sounds like it would be mitigated by use of https://developer.mozilla.org/en-US/docs/Web/API/Element/set... which is only available to PointerEvent implementations?
Maybe the support has improved in Chrome and Firefox, but I would be very careful to test Safari support before I relied 100% upon Touch Events.
I only used it for a very specific reason - I had a script which removes multi-item eBay listings where one item is 99 cents (typically some kind of keychain) and the other items are the actual listed item at a much higher price.
It's a technique used to break the "sort by price" function, since it sorts by the cheapest item in a multi-item listing.
I wonder why Apple decided to axe extensions and not support WebExtensions, that at this point have become a standard shared by Firefox and Chrome. Too bad.
I tried few ad blocker from the app store, but non of them block Youtube's video ad, making it useless.
We still have Firefox for now I guess.
It's difficult to even use the malware defense with YouTube, since YouTube's ads are just videos.
well this makes me happy at least
Likely this would be difficult on levels I can't even imagine.
Entering it in the actual login form will then usually trigger a save of the credentials.
The nice thing about it being at the bash prompt is I can just press ^U and it doesn't end up stored anywhere (and even if it did it would be a random, contextless string).
This is awesome for WYSIWYG editors, most of which have struggled to keep the formatting toolbar visible on mobile screens because there's been no good way to detect whether the keyboard is open.
Compared to MC-IF, an industry forum focusing on next generation H.266 / VCC which Apple is also a Founding Member, has an official logo from Day 1.
This is a nice enhancement. I previously used the Screen Sharing feature that was buried in Messages, which somehow stuck around from when it was iChat.
I used to always buy my license instead of the subscription but recently switched because frankly, I know it's a better business model for them, and I get so much value our of 1P I don't mind paying.
I've been a 1P user since before 1.0.
It's too easy to always try to squeeze every penny out of these small companies, but I think it's worth really thinking hard about their reality, and how much their software is actually worth to us.
IE was the reference browser for the web in the 90s, and Chrome is that today.
I struggle to support iOS 9 (Safari 9) and I barely support iOS 7, because we have a number of users with old devices and we are not a consumer app so we can't just ignore our users who cannot upgrade their browser.
I regularly check caniuse and mdn to see if I can use a useful feature that is in Firefox, Chrome and Edge, and I regularly can't because Safari doesn't support it. Or often I try to use a feature and it is buggy on Safari. Safari is the only browser that regularly breaks our web app (most recently Safari 13 changes for the iPad desktop mode). I also see old versions of Safari in use by some of our MacOS users (presumably because they can't or won't update?)
If our users hit a show-stopping bug in any other browser (browser bug or our bug), they can usually try a different browser. But iOS users can only use WebKit, so they are the most vulnerable to serious bugs.
Our clients are businesses, and our users are their employees (from a wide range of backgrounds). The employees must use our web app, and our clients mostly don't get to choose what their employees use.
We log how many users are on old browsers, and we try to support users on old browsers if it isn't too costly for us to do so.
In my experience, the majority of people using a iPhone 4 or an Android 4.4 device are doing so because they can't afford to update, and they are often otherwise marginalised. I try hard not to give them yet another kick in the teeth for stuff outside their control.
It's not quiet that precise -- there was a transition period at the end of the 90s and a period of multipolar quasi-equanimity before Chrome's dominance -- but it's a decent first approximation.
I'm sure you don't have to support 9 years old Safari.
If Apple allowed alternative browser engines in iOS, the situation wouldn't be so bad.
Safari now is the only evergreen browser that does not support it.