It'll be dependent on support in the font rasterizer we use, which varies depending on the platform. So this may become possible at different times on Linux/Android (depending on Freetype support), Mac OS (CoreGraphics) and Windows (DirectWrite).
There's also the issue of the CSS support for font variations (currently under discussion).
We should probably consider this an overall meta-bug for variation-font support, and file dependent bugs for the individual work items that will be needed: probably one for each platform/rasterizer backend, and one (or more) for the CSS side.

Variation Fonts are getting a lot of attention from web designers, typographers, and font companies. They are all very excited about it, especially the performance implications.
Chrome is already all over this: https://twitter.com/typo_labs/status/850728396099383297
And imo, this is one that will gather steam quickly, and yet, developers won't use it until it's in most browsers — putting extra attention and pressure on any browser that doesn't support it.

When these flags are set, variable fonts seem to work quite well. I realize there must be more to the story; it would be good to know if there is any way to help/find more support for getting this out from behind the flags.
```
Set layout.css.font-variations.enabled = true.
Set gfx.downloadable_fonts.keep_variation_tables = true.
Set gfx.downloadable_fonts.otl_validation = false.
```

You might want to change the release notes to indicate that variable fonts do not (yet?) work on Windows 7, as this is still the dominant desktop operating system for Firefox users, according to https://data.firefox.com. The current wording will raise expectations and will leave people disappointed. (Especially since variable fonts do actually work in Chrome on Windows 7.)