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

Re: [csswg-drafts] [css-fonts-4] [varfont] access to named instances

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Tue, 03 Jul 2018 05:19:17 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-402016032-1530595156-sysbot+gh@w3.org>
The Working Group just discussed `Access to named instances in variable fonts`, and agreed to the following:

* `RESOLVED: "font-named-instance" descriptor in @font-face with values "auto" or "<string>" and in the font-variation-resolution between step 4 and step 5`
* `RESOLVED: s/auto/none in previous resolution`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> topic: Access to named instances in variable fonts<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/525<br>
&lt;frremy> myles: This is one of the top requests I get from typographers<br>
&lt;frremy> myles: Named instances are how you can associate a string with a position in the variable axises space<br>
&lt;frremy> myles: They want to be able to use them<br>
&lt;frremy> myles: The only way I see would be a property taking that name, and overrides every other property<br>
&lt;frremy> myles: but that isn't great<br>
&lt;frremy> heycam: could we create a shorthand that would override these properties?<br>
&lt;frremy> myles: the problem is that the axes are not always linked to the css axes<br>
&lt;frremy> eae: and the axes might have similar names but be used for things unrelated to what css means<br>
&lt;frremy> chris_: another way for doing that is to add a new descriptor in @font-face<br>
&lt;frremy> florian: does that turn-off all properties that would be used for match<br>
&lt;frremy> florian: we can ignore all the values specified elsewhere<br>
&lt;frremy> heycam: but what if you want to start from a point, the named instance, then tweak one or two axes only?<br>
&lt;fantasai> fantasai: We could pull the named instance, apply CSS modifications on top of it.<br>
&lt;frremy> florian: can we add a new initial value "auto" that is ignored by default but would override named instances otherwise?<br>
&lt;frremy> fantasai: you pick a specific point in the space, and use that as an @font-face directly<br>
&lt;frremy> fantasai: and then you can say what it is even if this is not what the font says it is<br>
&lt;frremy> fantasai: you should be able to do this for axes<br>
&lt;frremy> chris_: the downside is that authors might use the named instances and opt out of the axes<br>
&lt;frremy> chris_: first model is you ask one specific font and use it<br>
&lt;frremy> chris_: second model is the css model, you create families and use properties to change within the families<br>
&lt;florian> q+<br>
&lt;frremy> fantasai: we could also override the named instances axes, like the weight<br>
&lt;fantasai> fantasai: So we pull the named instance, set the various non-standard axes according to the named instance's settings<br>
&lt;fantasai> fantasai: but set the standard axes according to the CSS system<br>
&lt;fantasai> fantasai: which might overide what the named instance would otherwise be, but keeps the CSS system and the font settings aligned<br>
&lt;fantasai> fantasai: E.g. if someone picks out an extra-black instance, but doesn't set it to font-weight: 800, then we apply font-weight: 400.<br>
&lt;astearns> ack myles<br>
&lt;frremy> myles: i think there are two design requirements<br>
&lt;frremy> myles: first is that fonts don't always download<br>
&lt;frremy> myles: content blockers can't for instance drop fonts, so we need to be resilient to font not being downloaded<br>
&lt;fantasai> s/can't/can/<br>
&lt;frremy> myles: second is that the nested cases, where a span needs to be able to bold from its parent<br>
&lt;frremy> myles: we know that because we allow "Arial Bold" for instance as a font family<br>
&lt;frremy> myles: but we do this in a smart way, so if you unbold, you get back Arial<br>
&lt;frremy> chris_: so, we would have the same kind of game in this case, correct?<br>
&lt;frremy> myles: yes<br>
&lt;frremy> chris_: the advantage of having the named instance in the descriptor is that you can use the properties on the child element the normal way<br>
&lt;frremy> chris_: which might be in that font-family or not, but this is the same as css from that point<br>
&lt;astearns> ack florian<br>
&lt;frremy> florian: I'm wondering if we named instances control things that are not css-y, then these values should be controllable by css<br>
&lt;frremy> florian: but does a named instance need a value for all axes?<br>
&lt;frremy> myles: yes, it does have a value for every axis<br>
&lt;frremy> myles: so your proposal is not possible, because there is no default<br>
&lt;frremy> florian: we need a way of saying "this font-descriptor value is for font-matching only" or "this value is a set value, ignore css<br>
&lt;frremy> chris_: basically, this is all because of variable fonts<br>
&lt;frremy> chris_: before we defined a nice set of things and it worked out<br>
&lt;frremy> chris_: but with the ranges we have now, it would create many values<br>
&lt;frremy> florian: if you set a named instance, and don't use descriptor for weight, the range will continue to apply, override the named instance<br>
&lt;myles> q+<br>
&lt;frremy> florian: but if your descriptor is explicitly set, then you would stick to that value<br>
&lt;frremy> florian: for instance "font-weight: &lt;something>" and then you don't use the value from the font instance<br>
&lt;astearns> ack myles<br>
&lt;frremy> myles: in the spec right now, there are many places from which the axes values can come from<br>
&lt;frremy> myles: there is a specific order<br>
&lt;frremy> myles: in this order, descriptor are early, css is after<br>
&lt;frremy> myles: we could say that the named instance applies where exactly it appears in the order<br>
&lt;frremy> myles: then you continue to apply further rules as usual<br>
&lt;chris_> myles summarises the precedence rules from https://drafts.csswg.org/css-fonts-4/#font-feature-variation-resolution<br>
&lt;frremy> myles: my proposal is that we could add a new signal to this algo<br>
&lt;frremy> myles: that would be the named instance<br>
&lt;frremy> myles: and it would be applied very early, other things come after<br>
&lt;frremy> florian: what ordering are you proposing exactly?<br>
&lt;myles> https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence<br>
&lt;chris_> https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence<br>
&lt;frremy> myles: between step 4 and step 5<br>
&lt;frremy> myles: new descriptor that is either auto or string<br>
&lt;frremy> myles: if the value is a string, you look at the font, find that value and apply the axes<br>
&lt;frremy> chris_: I like that<br>
&lt;frremy> eae: that seems nice<br>
&lt;frremy> eae: but if you fallback then these values don't apply<br>
&lt;frremy> eae: you could have one single glyph that uses another font<br>
&lt;frremy> fantasai: but then you have the issue that the axes might not be what css thinks they are<br>
&lt;frremy> myles: it's a little scary if we want to apply the axes of one font file, figure out if you are bold, then use these values in another font<br>
&lt;frremy> myles: if the first font doesn't load, then you get a different result<br>
&lt;frremy> fantasai: yes, i think if you want this, you should also set font-weight bold and that would fallback properly<br>
&lt;frremy> eae: authors might not do that<br>
&lt;frremy> myles: they will need to, because the ordering I propose will have font-weight win over the named instance<br>
&lt;frremy> myles: with this proposal, the named instance will set bold, but the font-weight will override this later<br>
&lt;frremy> fantasai: so the values we use to render are the ones that are in the computed styles<br>
&lt;frremy> florian: and discoverability?<br>
&lt;frremy> florian: better devtools?<br>
&lt;frremy> (general support for myles proposal)<br>
&lt;frremy> PROPOSAL: descriptor in @font-face with values "auto" or "&lt;string>" and in the font-variation-resolution between step 4 and step 5, we lookup the values of the named instance in the font and apply them<br>
&lt;fantasai> frremy: Can we make it alist of names?<br>
&lt;fantasai> frremy: so that way you can handle fallback fonts kindof better<br>
&lt;fantasai> florian: Are you matching the lists? or just go through the whole list per font in src?<br>
&lt;fantasai> myles: We can extend it later to do that, if needed<br>
&lt;frremy> astearns: let's not do this, we can do this later if we want<br>
&lt;frremy> myles: it is backwards compatible to convert this to a list later<br>
&lt;frremy> frremy: ok, sounds good<br>
&lt;frremy> dbaron: but what if you have different font files?<br>
&lt;fantasai> dbaron: What if you want different names per font file in the src list<br>
&lt;frremy> myles: you should only use that for cases when the browsers support different formats<br>
&lt;fantasai> various: No, we don't want to do that<br>
&lt;frremy> myles: not different files<br>
&lt;fantasai> s/use that/use src lists/<br>
&lt;frremy> chris_: myles: let's do this later<br>
&lt;dbaron> dbaron: what if instead of a separate descriptor you have a function that goes in the src: descriptor<br>
&lt;frremy> astearns: if you want that, I think you want that at the "src" level<br>
&lt;frremy> myles: if we want to extend this, we can come up with new ways later<br>
&lt;frremy> (bikeshedding about the name)<br>
&lt;frremy> (font- prefix because all of them have that)<br>
&lt;frremy> (-named-instance because that is what this is called in the spec)<br>
&lt;frremy> chris_: I like font-named-instance, let's use that<br>
&lt;frremy> astearns: so we seem to be converging font-named-instance<br>
&lt;frremy> florian: I'm not going to object<br>
&lt;frremy> RESOLVED: "font-named-instance" descriptor in @font-face with values "auto" or "&lt;string>" and in the font-variation-resolution between step 4 and step 5<br>
&lt;frremy> (one more cycle of the bikeshedding, but the arguments are about the same)<br>
&lt;frremy> fantasai: we can rename things in spec<br>
&lt;frremy> fantasai: but we can chose a better name if we want<br>
&lt;frremy> chris_: yes, but i still prefer what we resolved<br>
&lt;fantasai> s/spec/spec, that's an editorial change/<br>
&lt;frremy> heycam: can we use "none" instead  of "auto" though?<br>
&lt;fantasai> s/but we/when we expose terminology through syntax, /<br>
&lt;frremy> RESOLVED: s/auto/none in previous resolution<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/525#issuecomment-402016032 using your GitHub account
Received on Tuesday, 3 July 2018 05:19:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 3 July 2018 05:19:22 UTC