Currently firefox is blocked by this, and some other related APIs: https://developer.mozilla.org/en-US/docs/Web/Events/selectio...
Once dom.select_events.enabled defaults to true, we'll be able to polyfill most of the other missing APIs.
Once dom.select_events.enabled defaults to true, we'll be able to polyfill most of the other missing APIs.
What do you do when it inevitably changes?
Currently working on a project that only supports Chrome. Turns out it was only using a couple experimental APIs that were easily replaced by small libraries/polyfills. The Chrome blinders are real.
This doesn't mean "we are waiting for them to fully support this working draft", but rather that we haven't implemented polyfills for the (relatively small) number of APIs missing, yet. When/if the spec changes significantly, these polyfills should carry us until we can change the non-polyfilled version of the code.
Especially devs have a quite equal share between Firefox and Chrome (due to the privacy implications of Chrome), so using private extensions that are non-standard, and, according to what you say, irrelevant for your product has to be quite an irrational move.
That being said, that wasn't necessarily the driving factor in the "use the fancy selection APIs" decision. There were many factors, but for one thing, choosing to use those APIs, while limiting our browser support (for a limited amount of time) helped us get to where we are now at a quicker pace than if we'd opted for much broader browser support from day 1.
One of the challenges here for Firefox is that there's not an API to determine when a user's selection changes. We need this in order for inline markdown to collapse/expand as the cursor comes within proximity of it. It's definitely possible to poly-fill this, we just haven't done it, yet :\ We could disable this for Firefox, but I'd rather ship Firefox support with the rad stuff that the other major browsers already get.