For recent cards, it makes more sense for these companies to tend on the side of not giving out competitive information, hence their NDA processes for developers.
> Adults don't need to write down a code of conduct, because they adhere to an unwritten code of conduct. Children whinge, 'you shouldn't do that, because this says not to!'; adults don't do that, because they know that they oughtn't — and they refrain from associating with others who do. Children want their clique to gang up on the people they don't like; adults simply walk away from those people.
Because no adult has ever harassed another in a programming community? I would love it if everyone behaved politely and courteously, however this is not currently what is happening in some projects. Having a CoC is merely a preventative measure to curb bad behavior for those who can't self-police.
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.
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.
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.
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.
For recent cards, it makes more sense for these companies to tend on the side of not giving out competitive information, hence their NDA processes for developers.