The variable font code uses Proxy, a non-polyfillable ES6 type.

[ILOVEPIE]

The variable font code uses Proxy, a non-polyfillable ES6 type, preventing opentype.js from being transpiled to anything lower than ES6.

Expected Behavior

In order to implement a legacy/compatibility build this code must be reworked slightly to remove the dependence on Proxy.

Current Behavior

While most JavaScript features can be polyfilled for older browsers, proxy is one of the few that cannot. Even SWC and Closure Compiler cannot polyfill this feature.

Possible Solution

Don't use Proxy, it doesn't add any significant amount of code to avoid it.

Context

This is blocking #693

[Connum]

There's es6-proxy-polyfill on npm and https://github.com/GoogleChrome/proxy-polyfill - why can't we use that? Using proxies has the advantage of triggering recalculations automatically for example.

[ILOVEPIE]

We can use it if we directly add support for the polyfill into our code, but it's not a true polyfill for it, it's more like a workaround. The only way to truly polyfill it is the non-standard and deprecated Object.observe().

[Connum]

Mhh, what is a "true" polyfill for you?

[ILOVEPIE]

A polyfill is a piece of code that replicates the functionality of a feature using other older features. In this case, the chrome polyfill doesn't work in all cases.

The polyfill supports just a limited number of proxy 'traps'. It also works by calling seal on the object passed to Proxy. This means that the properties you want to proxy must be known at creation time.

Currently, the following traps are supported-
get
set
apply
construct

[ILOVEPIE]

We could use it though, it's just we have to be careful about the traps used, and how we use it.

[axkibe]

Is this backward compatibility really necessary? Nowadays users need to have a relativly recent browser due to security dangers anyway. If polyfilling is possible without much effort I'm all to it, if it put additional constraints on development I'd give it a no to waste time and effort on it.

[ILOVEPIE]

Is this backward compatibility really necessary? Nowadays users need to have a relativly recent browser due to security dangers anyway. If polyfilling is possible without much effort I'm all to it, if it put additional constraints on development I'd give it a no to waste time and effort on it.

A lot of smart TVs and other embedded browsers use old versions of chromium and webkit. For compatability with such devices this is needed.