W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2016

[csswg-drafts] [css-fonts-4] [varfont] @font-face descriptors should accept ranges

From: litherum via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Sep 2016 23:33:16 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-178487581-1474500794-sysbot+gh@w3.org>
litherum has just created a new issue for 

== [css-fonts-4] [varfont] @font-face descriptors should accept ranges
 on behalf of @AmeliaBR

Would there be a value in allowing the font-face descriptors (e.g., 
font-weight, font-stretch) to take two values, defining the range 
available from the file?

If you use range descriptors, then the non-variable fallbacks no 
longer match the descriptors, and would need separate font-face rules.
  However, I'm pretty sure that still works with `@font-face` as 
currently defined, just need to watch the ordering:

@font-face { /* fallback normal weight face */
font-family: BodyText;
font-weight: normal;
src: url(something) format(woff);
@font-face { /* fallback bold weight face */
font-family: BodyText;
font-weight: bold;
src: url(something-bold) format(woff);
@font-face { /* variable weight font */
font-family: BodyText;
font-weight: 200/700; /* min and max weights */
src: url(something-variable) format(woff2-variations);
So user agents that recognize the range descriptor and variable-font 
format would download the final file, others would download one or all
 of the backups (depending on which weights are required).

EDIT: I initially had the range descriptor using comma to separate the
 values.  But it would probably be best to reserve commas for a list 
of distinct values (not a range).  So, for example, if a user agent 
supported OpenType collection files (multiple distinct faces in one 
file), that could be `font-weight: 300, 500, 800`, while a 
variable-weight font with a continuous range would be `font-weight: 

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/521 using your GitHub 
Received on Wednesday, 21 September 2016 23:33:24 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:03 UTC