Earlier quoted context omitted.
You can't do proper adblocking (e.g. uBlock Origin) on Safari. That's why I don't really use it except when on battery and out travelling - and even then I'll often avoid using Safari since ads are so awful. Yes, I've tried the Safari adblockers, they suck. As far as I can tell they do marginally more at best than a DNS block. Once you can't use uBlock Origin with Chrome due to the proposed Manifest V3, Firefox will…
This was one of the main reasons we built the Orion browser [1]. Lightweight and faster than Safari in benchmarks, same WebKit engine and able to run Chrome and Firefox extensions out of the box, including uBlock Origin. Still in beta and you can try it for free. It is zero telemetry and completely user supported through Orion+ subscription. Has a very active feedback forum at OrionFeedback.org. [1] https://browser.k…
Recent improvements to Safari
141–147 of 147 posts
Re: Recent improvements to Safari
#142Earlier quoted context omitted.
You can't do proper adblocking (e.g. uBlock Origin) on Safari. That's why I don't really use it except when on battery and out travelling - and even then I'll often avoid using Safari since ads are so awful. Yes, I've tried the Safari adblockers, they suck. As far as I can tell they do marginally more at best than a DNS block. Once you can't use uBlock Origin with Chrome due to the proposed Manifest V3, Firefox will…
Same. Safari has always been very performant, but it doesn't matter when you're basically running around naked without ublock.
Re: Recent improvements to Safari
#143One very overdue improvement to iOS Safari I noticed: the humble HTML select element. Since the first iPhone, iOS Safari displayed a clunky wheel selector for HTML selects, requiring more taps than necessary to view and select an option from the list. Finally at some point last year they ditched the wheel, replacing it with a simple list (similar to Android), requiring less interaction to select an item. Only took th…
It wasn't an inefficiency. It was a way to give users nice scrollable lists with large tap targets on tiny mobile screens.
Yes it was. It required more interaction than necessary to select an item from a list, which is the definition of inefficiency. Why do you think they changed it.
Not only that, but the picker wheel only showed a few items, you had to scroll to see more than about 3 or 4 items. All this squashed into half the screen. Inefficient and poorly designed.
When selecting numbers on a date calendar, the wheel can be forgiven because you don't need to see the whole list to know the estimated position of your choice. But most select boxes on the web are NOT number pickers, but lists of words required to be read before a selection made. The old and now dead iOS select element wheel was a sorry piece of UX design indeed in most select box cases.
Re: Recent improvements to Safari
#144Earlier quoted context omitted.
Chrome is not the the weakest / furthest behind major browser
On release, IE6 was so ahead on CSS standards conformance it broke websites. The old (long-forgotten) incantation for accessing XMLHttpRequest is the way you create a COM IDispatchEx object by ProgID from inside Active Scripting, because that was the way it worked in the original IE implementation. Before there were PWAs or Electron, there was the HTA, introduced with IE5. (Admittedly XUL came even earlier.) And so o…
Re: Recent improvements to Safari
#145Earlier quoted context omitted.
Chrome is not the the weakest / furthest behind major browser
That only reveals a lack understanding how IE 5 took over the Web world. It slowed down when it won, same will happen to Chrome after Google is done turning it into ChromeOS. Safari is the only relevant browser preventing Google to achieve that goal.
Please tell me how Chrome has "slowed down" after reaching the current market share years ago. It's not like Safari is the one making on-spec progress like Firefox did in 2005. Sounds like you're the one not understanding the early browser wars.
Re: Recent improvements to Safari
#146Earlier quoted context omitted.
Anyone who disagrees hasn't tried to develop a website on Chrome and Firefox only to find out Safari still doesn't support regex lookbehind (which means zero javascript will now run). It's only been available in Chrome for 5 years after all, no rush.
None of your Jacascript code will run? That sounds overly dramatic. 1. this only concerns regex 2. there’s an alternative regex syntax doing the same thing as part of the ecma standard 3. it can be implemented very easily without regex in almost all cases 3. It seems like you’re only considering chrome for desktop, not other browsers or mobile
Try appending this piece of code to your `index.js` and let me know how it goes in Safari:
const r = /(
The parser will encounter a syntax error and no code is executed.Re: Recent improvements to Safari
#147I don't really know about all the details of those metrics but I know one thing: Safari is smooth. Actually it was just perfect in the previous years too for me anyway. It just works and works super-efficient. That's why I use it. The only reason I have Chrome installed is to test my websites with Chrome and use MetaMask. TBH I never understood why people use Chrome on a Mac unless there is a specific extension or si…