[polymeris]

Am super frustrated with how buggy Evernote is, and would be interested in an alternative, but...

"We currently only support your browser in read-only mode. Read more."

You don't support firefox!? It's not like it's some obscure browser.

Also the demo canvas on the landing page being slightly tilted to the left freaks me out.

[ofbriggs]

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.

[moron4hire]

I can think of a way to hack it in, and I'm open for consulting contracts.

[kuschku]

You built your project on an API that just became a working draft?

What do you do when it inevitably changes?

[nathancahill]

Happens all the time. Such a terrible thing. I love this article that was posted here a couple days ago: https://blog.runspired.com/2016/03/25/the-chrome-distortion-...

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.

[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.

[RealCasually]

Change their project?

[revorad]

Here's my obligatory recommendation for Simplenote. It is so good - http://simplenote.com

No affiliation, just a happy user.