[jclem]

Like the "read more" link about FF support says, we plan on supporting it and IE10+ in the future.

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.

[kuschku]

If that’s the case, then why develop based on a browser that isn’t even the most used browser anyway?

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.

[jclem]

The overwhelming majority of the traffic we've seen so far has been Chrome and Safari, even from HN.

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.

[moron4hire]

It is trivially easy to poll it in an animation loop.