requestAnimationFrame was introduced in the HTML spec much after the HTML 5 and HTML 5.1 specs, so our current checks do not cover it. I would expect certain headless browsers with a new JavaScript/ES6-capable engine, and some kind of DOM library to not implement this for example. That means we don't currently ensuring its presence, and we generally consider it worthwhile to make the startup phase as robust as possible, so that after that phase we can reliably and comfortably engage with the Basic foundation and the optional Modern layer atop.

I don't think we need to support the fallback for those theoretical cases, so perhaps we just need to update the feature test to look for a newer HTML APIs than this. Right now we poll the HTML API through support of the localStorage key. Perhaps requestAnimationFrame itself would make a good candidate.

See T141344 for an example of a feature-test campaign, through which we will observe and validate our hypothesis. The hypothesis could be that no known browsers would pass our current check without also passing this new check. We can then look at the data we find, which browsers they are from, and decide what to do based on that. If we find notable Grade X browsers that we'd like to provide the Modern layer to still, then we could continue to have a fallback. If we find that they would be better served with the Basic layer only, then we'd update the feature-test.

In any event, it would possibly be a better use of time to do this after T178356, which will naturally eliminate a large group of edge cases.

There is not a direct relation between the language runtime (e.g. V8, SpiderMonkey, JSC) or specification (ECMAScript), and the browser engine (Firefox, Chromium, WebKit). That is to say, requestAnimationFrame is not an ES5 or ES6 feature. It's an HTML feature (MDN, spec).

But, with the cut to ES6 in T178356, we have indeed jumped past the point where all Grade A browser versions (i.e. modern browsers we support) also implement this HTML API, as shown by CanIUse and MDN browser compat data.

I believe this is also validated by the eslint-plugin-compat which includes this dataset and is configured in our ESLint preset with our browser support matrix. So this and any other Web APIs (e.g. DOM, HTML, Paint Timing, IntersectionObserver, etc) can be unconditionally used if the browser compat data indicates as much (ideally detected by ESLint).