Such as?
clicking issues https://stackoverflow.com/questions/24077725/mobile-safari-s... (yeah even clicks are broken)
background jank https://stackoverflow.com/questions/9983520/webkit-animation... (not sure it's exactly this bug but I do have fixes in the codebase for that)
round corners https://stackoverflow.com/questions/50995411/cant-set-border... (still happening right now)
And countless other JS and CSS bugs I forgot I have in the codebase. There's scrolling bugs, navigation bugs, layout bugs, form bugs... I'm sorry to say but nothing really "fully works" it's always slightly off one way or another.
And there's all the quirks additionally to all of that.
I suspect you either didn't read those release notes fully or you don't fully understand what they mean.
I develop primarily on Safari, and only occasionally test on Chrome (for my hobby side project), and occasionally I run into instances where Chrome differs. To me, those look like Chrome bugs because Safari is my "default".
If you're using Chrome (or Firefox, which, in my recent experience, tries specifically to be compatible with Chrome because Chrome is the overwhelming default for people like IE was) primarily, and expecting Safari to exactly match its behavior, of course you'll run into various cases where Safari appears buggy. But to use that to claim that Safari is "the new IE6" is just ludicrous.
I don't know how old other people in this thread are—maybe those making the comparison to Safari weren't actually around for the IE era, or maybe it's just been so long you've forgotten how bad it really was—but I was actually doing some web development back when IE6 and even IE4 were common. They were an absolute nightmare. I don't recall the precise details at this late date, but there were fairly basic HTML tags they didn't implement, and others they implemented completely differently. Javascript features were all over the map.
That realusername has to dig up four fairly esoteric edge-case issues to show that Safari is "total nonsense", and then have HatchedLake point out that at least two of those aren't even current, is ample proof that it's the comparison of IE to Safari that's total nonsense.
For the tags I do agree but for the Javascript I have a good bunch of pollyfills just for Safari in place.
> That realusername has to dig up four fairly esoteric edge-case issues to show that Safari is "total nonsense", and then have HatchedLake point out that at least two of those aren't even current, is ample proof that it's the comparison of IE to Safari that's total nonsense.
All of those issues are current and very much not fixed. Yeah they are very old and have been there for almost 10 years I do agree, but it's still broken now, even after 10 years.
There are several questions regarding bugs - how many are there, how difficult are they to find, how difficult are they to fix.
It seems that there are many Safari bugs that are difficult to find, and to fix, which makes them worse than other browsers.
In this case I believe the bug is actually difficult to find, this guy found it but I bet a lot of developers just went and ahead and wrote it down as a bug with safari, can't or won't fix. But now we know it's an easy fix - don't write Welcome Back in a page if you don't want this behavior.
My question is if your language is another one - like lang="DE" will it then have the same behavior on a page with the German version of Welcome Back.
Are there other magic strings that serve the same purpose as Welcome Back in Safari's mind.
on edit: changed difficult to fix to difficult to find.
- SVG background issue from 2016. Tested on my Safari Tech Preview 113 (Sep 2020), can't replicate.
- Clicking issue. This is related to mouse event bubbling on iOS only (will affect both Safari and Chrome since they both use the same WebView). It's theorised that Apple set a specific set of rules when mouse events (on touch devices) will bubble up for performance/usability. Or it's just a bug.
- A rendering issue from 2012. It's explained in your link this is related to pre iOS 7 era performance improvement by WebKit to only redraw those parts of an image that have changed. Sounds like a very reasonable thing to do, taking into account how Apple heavily pushed performance and battery savings on mobile/laptop devices a decade ago.
- Round Corners. Tested on my Safari Tech Preview 113 (Sep 2020), can't replicate.
I don't see how any of these are anywhere close to being "total nonsense", feels like you're being biased and just exaggerating on purpose to bash Safari.
Chrome force logging in you when you use Gmail to hijack your privacy and link your browser history to an account sounds more "nonsense" than Apple focusing on performance/battery on mobile devices a decade ago that created a regression/new bug that requires 1 line to solve. https://news.ycombinator.com/item?id=17942252
I primarily use Safari for privacy/battery/performance reasons, and on my web app of 2 years with tons of styling I have 5 lines of scss code with "// safari" comment to make some elements render the same as Chrome.
Never in my career writing a single digit line of additional css made me think "oh my god this is total nonsense". Everyone has to accept there will be differences from one browser engine to another, and from my personal experience, these are minimal and nowhere near IE6 back in the days.
> I primarily use Safari for privacy/battery/performance reasons, and on my web app of 2 years with tons of styling I have 5 lines of scss code with "// safari" comment to make some elements render the same as Chrome.
You are within your own right to use Safari but you should not expect everything to work perfectly in return, treat it as "best effort" web browsing.
On my case I have about a dozen lines of CSS and same in JS for all the Safari quirks. All of those took time to investigate and fix (especially with their awful debugger...), maybe there's more Safari bugs, I just cannot guarantee everything works.