Jonathan Kew [:jfkthame] Reporter
	Description • 6 years ago

In Fonts 4, these descriptors can accept a second value (e.g. "font-weight: 100 600; font-stretch: 80% 125%;"), representing a range of values that a variation font supports.

https://drafts.csswg.org/css-fonts-4/#font-prop-desc

	Jet Villegas (inactive)
	Comment 1 • 6 years ago

[ Triage 2017/02/20: P3 ]

	Jonathan Kew [:jfkthame] Reporter
	Comment 2 • 6 years ago

Emilio, any chance you could take this? As it involves modifying the parsing of the @font-face descriptors, you'll be infinitely more efficient at tackling it than I would.... :)

	Maire Reavy [:mreavy]
	Comment 3 • 6 years ago

Moving this to P2 since we're requiring support for the higher-level CSS properties in addition to the low-level variation-settings tools in order to ship Variable Fonts

	Emilio Cobos Álvarez (:emilio)
	Comment 4 • 6 years ago

Do we want to block this on the work jwatt is doing to support <number> instead of <integer>? Or fix this first? Both work for me.

	Jonathan Kew [:jfkthame] Reporter
	Comment 5 • 6 years ago

Probably best to check with jwatt about that. We'll want to end up using the same custom types on the gecko platform side for FontWeight/FontStretch/FontStyle as properties and as descriptors, so maybe you'll want those to land first; but perhaps it's feasible to work on the parsing updates (to support ranges, and an optional <angle> for font-style:oblique) even now, and then slip in the change to the underlying gecko types when they're ready.

	Jonathan Kew [:jfkthame] Reporter
	Comment 6 • 6 years ago

This ended up getting done along with the properties in the dependencies of bug 1454597.

	Chris Mills [:cmills]
	Comment 7 • 6 years ago

I've added some details of this stuff to the @font-face page:

https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face

And updated the browser compat data:

https://github.com/mdn/browser-compat-data/pull/2231

And finally added a note to the rel notes:

https://developer.mozilla.org/en-US/Firefox/Releases/61#CSS

Let me know if you think this look OK. The @font-face docs are a bit of a mess right now, but I am scheduling to fix those in a separate piece of work.

	Jonathan Kew [:jfkthame] Reporter
	Comment 8 • 6 years ago

Thanks, Chris. One thought re the font-style descriptor: it might be worth clarifying that a range is only supported when the font-style is oblique (i.e. the oblique keyword can take a pair of angles); for font-style:normal or italic, no second value is allowed.

	Jonathan Kew [:jfkthame] Reporter
	Comment 9 • 6 years ago

In the relnotes: "font-weight, font-stretch and font-style now support user-defined syntax types (bug 1436048)" isn't the right way to phrase things. The "user defined types" mentioned in bug 1436048 are an internal implementation detail, not something exposed to authors.

I'd say something more like "font-weight, font-stretch and font-style now support additional values as defined by CSS Fonts 4" (and then the specifics of what each property accepts).

	Chris Mills [:cmills]
	Comment 10 • 6 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #8)
> Thanks, Chris. One thought re the font-style descriptor: it might be worth
> clarifying that a range is only supported when the font-style is oblique
> (i.e. the oblique keyword can take a pair of angles); for font-style:normal
> or italic, no second value is allowed.

Nice one Jonathan — I've updated the following page to include these details:

https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-style

	Chris Mills [:cmills]
	Comment 11 • 6 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> In the relnotes: "font-weight, font-stretch and font-style now support
> user-defined syntax types (bug 1436048)" isn't the right way to phrase
> things. The "user defined types" mentioned in bug 1436048 are an internal
> implementation detail, not something exposed to authors.
> 
> I'd say something more like "font-weight, font-stretch and font-style now
> support additional values as defined by CSS Fonts 4" (and then the specifics
> of what each property accepts).

OK, thanks — updated!