Implement browser compatibility detection in OOjs

Closed, DeclinedPublic

Actions

@Esanders What kind of detection, for which use case?

I think I meant feature detection like we do in startup.js.

@Esanders I'm hesitant to add that to OOjs, but depending on the use case, I could be convinced otherwise.

A few thoughts:

• Browser features used by OOjs (a library) should generally be be a subset of the features used in an end-product (like VE or MW).
• OOjs itself is not positioned to be able to call its own check, given it would have nothing useful to do if the check fails. If this were a standalone product like VE, it could potentially be included on an HTML page directly in a way that either enhances the page, or gracefully falls back to nothing. But for a lib like OOjs, that probably should not gracefully fallback, given it would not fulfil its own contract of providing an external API.
• If we did have a check in OOjs and use it to gracefully do nothing, how should OOjs be consumed by VE or MW? Should consumers check the support indirectly by checking the existence of OO? This would imply a consumer has to load OOjs upfront without a feature check, which causes other problems, and likely wouldn't work well for MediaWiki in a way that is efficient, scales to multiple libs, and doesn't cause parse errors when unsupported (which obsoletes the purpose of a feature test).

I suppose there is the argument of maintenance in the current approach, which is that the feature requirements are enumerated in README, and consumers have to manually ensure their inclusion in their primary feature check (VE, MW). Perhaps some sort of automation is possible there.

But I digress, what use case did you want it for?

This was a while ago, and probably before we dropped ES3 support fully, so probably not as pressing now. I think I had in mind third party support so that users could avoid loading apps built with OO if the browser didn't support them.