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