W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [css-fonts-4] [varfont] May want different properties for font matching and variation value

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 Jul 2018 16:57:44 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-407824106-1532537863-sysbot+gh@w3.org>
The Working Group just discussed `May want different properties for font matching and variation value`, and agreed to the following:

* `RESOLVED: defer this issue to next level`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: May want different properties for font matching and variation value<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/528<br>
&lt;dael> myles: Right now for font variations the properties are partioned. Set A effects font selection and set B doesn't. A is font-weight, -style-stretch.<br>
&lt;dael> myles: You use value of those to find a font and if it has range of values the requested width or slope is applied<br>
&lt;dael> myles: For those properties they both are used to choose fonts and then they select a point in design space. Issue asks how to separate concepts. I want to select a font-weight but not have it effect font selected.<br>
&lt;dael> myles: There is a way, you can use font-weight properties to do font-selection and after that you can use font-varaition settings of wght and that separates the values. It's not very clean, but it will work the way you want. It's just not as nice<br>
&lt;dael> fantasai: If don't that then...If you had a variable font and you jsut want to use for all weights on page and you're using 3 weights then you would have to crea te a ne @font-face rule for each weight that's pegged to that value and map that to a value on the variation axis<br>
&lt;dael> fantasai: That would work if you had fixed # of weights and you knew what you would use.<br>
&lt;dael> fantasai: If you were animating weight that won't work b/c you have no mapping for intermediate values<br>
&lt;dael> myles: font-face descriptor allows range<br>
&lt;dael> fantasai: Font variations doesn't. So fi you have a font-weight descriptor that's 400-800and then set font variation settings as a default of 500 then you've said this font which is gonna be rendered at 500 always is the 400-800 range. If I ask for the 400 I get the 500 because it wins, right?<br>
&lt;dael> myles: right<br>
&lt;dael> fantasai: You can't create the mapping...you can do it for a single point but not a range<br>
&lt;dael> florian: I think a use case would help<br>
&lt;dael> florian: I think a typical thing is you're using your main font for lots of things, but for &amp; you want a different font. Non-variable you use unicode range to subset and you decide that it looks good at a different size. With @font-face you can do that. With variable you try and do the same thing where the &amp; font is about 200 more then main font you can't do that. You can lock it for specific values, but not on range<br>
&lt;dael> florian: I think we want in the @font-face rule you can map a range to another range. At font-selection if there's a font between 500-700 I'm good and it corrisponds to 700-900. Or something along those lines<br>
&lt;dael> fantasai: Agree that's what needed to solve. Have a similar issue as related to size. It's a bit easier b/c it's constant.<br>
&lt;dael> florian: I thinkt he problem isn't too bad b/c you can slice per linear range you can do it if you have mapping<br>
&lt;dael> fantasai: I think we should solve this, but defer to next level. not super critical, but we do need to...people are shipping. We should get set of features to ship and get the spec to CR. I agree it's a problem and we should look to solve<br>
&lt;dael> myles: I'd like to hear from designers about the problems they're trying to solve<br>
&lt;dael> fantasai: And defer would give time for that to happen<br>
&lt;dael> Rossen: myles okay to defer or did you want to hear now?<br>
&lt;dael> myles: defer is fine<br>
&lt;dael> florian: Okay to defer<br>
&lt;dael> Rossen: Objections to defer this issue to next level?<br>
&lt;dael> RESOLVED: defer this issue to next level<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/528#issuecomment-407824106 using your GitHub account
Received on Wednesday, 25 July 2018 16:58:10 UTC

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