any feature that is not implemented in all major browsers should be considered experimental. it might go away. it's fine to use such features for experiments, but they should not be put into production and relied upon.
any differences in the implementation of the standard should be considered a bug. warning users about bugs is fine, but automatically redirecting me to some other browser that you deem working is not.
depends how much your users matter to you. if a browser[1] lags behind on a feature, you should avoid using that feature on a production website, or provide a gracefull fallback. but by no means should you redirect the users to a browser that supports that feature.
[1] i am only counting major modern browsers here: chrome, edge, firefox, safari.
you are welcome to support more, but these at a minimum.
If I have 20% FF users and 70% chromium users, then I shouldnt deploy a feature which will serve those 70% and wait who knows how long till FF catches up?
you are willing to anger 20% of your userbase? you can do whatever you want, just don't expect everyone to go along. but if i run a business and my revenue depends on my browser users, i'd be very hesitant at loosing even 5% of them, let alone 20%.
well, it depends on whether the site breaks if a browser feature is missing or not.
if it doesn't break then you have a graceful fallback which i did already suggest as an acceptable way to support new features in case they are not supported.
but if the site breaks in some way, it may prevent me to complete the objective on the site. if i wanted to buy something, and the site doesn't work because of that missing browser feature, then i will have to go buy somewhere else. it doesn't matter how much leverage the site has if i can't use it.
What? No, it's the exact opposite! If I set my system to open mailto links in Thunderbird, the link won't randomly override and open in Outlook. That's the whole point: The link specifies what should get opened, and then the application of the user's choice handles it.
