- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Aug 2017 12:18:05 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `TAG Review of variable fonts`, and agreed to the following resolutions: * `RESOLVED: font variations will be both properties and descriptors` <details><summary>The full IRC log of that discussion</summary> <fremy> Topic: TAG Review of variable fonts<br> <TabAtkins> GitHub: https://github.com/w3ctag/design-reviews/issues/183<br> <fremy> github: https://github.com/w3ctag/design-reviews/issues/183<br> <fremy> dbaron: ??? asked for tag review<br> <eae> s/???/drott/<br> <fremy> dbaron: the main feedback was how this should be font properties or descriptors<br> <fremy> dbaron: the reasoning should be that some things should be whether you would want the things to apply to fallback fonts or not<br> <fremy> dbaron: over time, system fonts are likely to get more variations<br> <TabAtkins> Looks like the axixes would be best done as an open-ended set of properties, similar to custom properties...<br> <fremy> myles_: there are two spaces<br> <TabAtkins> We can't guarantee that the axis names live in the CSS ident space, so we can't do `font-axis-*` tho.<br> <fremy> myles_: one is for things that are defined for all fonts<br> <fremy> myles_: and things that are custom for your own font, which are used in all caps<br> <fremy> TabAtkins: what is the ascii range for these names?<br> <fremy> myles_: less than ascii for sure<br> <fremy> myles_: no control char or anything, and casing does matter<br> <fremy> dbaron: flip side is animation<br> <fremy> dbaron: if you want to animate them, they should be properties<br> <fremy> eae: there have been clear request to support that<br> <fremy> dbaron: I think it would make sense then to have both to support both use cases<br> <fremy> myles_: this is what font-feature-settings is, minus some stories I rather not start talking about<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/1652<br> <fremy> TabAtkins: how about having a list of values in the axis?<br> <fremy> TabAtkins: we still need to be able to control them independantly<br> <fremy> TabAtkins: we can instead allocate a property namespace so that you get a property for each axis<br> <fremy> fantasai: the issue is that each axis might change of ascii range in newer formats<br> <fremy> TabAtkins: you can escape any char in identifiers in css<br> <fremy> myles_: in our impl we would not want that anyway<br> <fantasai> s/the issue is that each axis might change of/what if axis idents are outside/<br> <fremy> s/that/weird axis names/<br> <fremy> alan: use case where you have weight animated<br> <fremy> myles_: you can animate pair by pair<br> <fremy> TabAtkins: but you still need to change all of them in same declaration<br> <fremy> myles_: additive css would solve that<br> <fremy> TabAtkins: yes<br> <fremy> myles_: so, based on consensus we need a resolution to add descriptor and keep property<br> <fremy> fantasai: we have a similar problem with various stylistic fonts tags you want to turn on and off<br> <fremy> fantasai: what we did, we decided to tie them to an identifer that is font-specific<br> <fremy> fantasai: we could take the same approach here<br> <fremy> fantasai: this would allow to customize a font-specific thing in particular without affecting other fonts<br> <fremy> myles_: that would work for named axises but some are just number-indexed<br> <fremy> TabAtkins: also the ranges could not mean the same thing for each font even if name is identical<br> <TabAtkins> s/name is identical/the two axises do approximately the same thing/<br> <myles_> That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts<br> <fremy> alan: even the lower-case standardized names, do they have identical ranges?<br> <fremy> myles_: no<br> <fremy> myles_: names are consistent between formats, but ranges are not<br> <fremy> myles_: they are internally consistent per format though<br> <fremy> alan: could we map one to the other?<br> <fremy> myles_: yes, we could map to a canonical form<br> <TabAtkins> s/myles_: that would work for named axises but some are just number-indexed/That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts/<br> <fremy> alan: so could we define a css range?<br> <fremy> myles_: I don't want to get into that<br> <fremy> alan: anyway, I didn't hear any opposition to have things be both font descriptors and properties as per tag review<br> <fremy> alan: can we get this resolved?<br> <Bert> q+ to ask (about previous topic) what 'font-synth: no-weight style' means for small-caps: Is small-caps synthesis on (beacuse it is not explicitly turned off) or off (because it is not explicitly turned on)?<br> <fremy> RESOLVED: font variations will be both properties and descriptors<br> <fremy> alan: any other issue we should discuss from this review?<br> <fremy> dbaron: not really, the rest is mostly editorial<br> <astearns> ack Bert<br> <Zakim> Bert, you wanted to ask (about previous topic) what 'font-synth: no-weight style' means for small-caps: Is small-caps synthesis on (beacuse it is not explicitly turned off) or off<br> <Zakim> ... (because it is not explicitly turned on)?<br> <fremy> Bert: so font-synthesis: no-abc --> turns off abc but on def, right?<br> <fremy> myles_: well, it resets def to its default<br> <fremy> myles_: right now all the other values are on by default, but in the future we could add new things that would be off by default<br> <fremy> Bert: then why should we not change the fonts spec<br> <fremy> myles_: no, it would just do as today, the spec will still be internally consistent<br> <fremy> fantasai: well, new features will be off by default all the time right? otherwise it will be breaking change<br> <fremy> Florian: not really, because new features could be things that did not exist at all before<br> <fremy> Florian: so there would be no possible backwards compat problem<br> <fremy> fantasai: and small-caps?<br> <fremy> myles_: it is not in level 3, so no revision to do<br> <fremy> fantasai: but with this we could backport to level 3<br> <fremy> fantasai: wouldn't you want that then?<br> <fremy> myles_: to prevent a browser that support "small-caps" but "not-smallcaps"?<br> <fremy> fantasai: yes<br> <fantasai> fantasai: We could have small-caps be on in the initial value and also be on if omitted<br> <fremy> dbaron: well, i think there is still a change from level 3<br> <fantasai> fantasai: The ability to do this is effectively why we are considering having this foo/no-foo syntax.<br> <fremy> TabAtkins: this is not the same default we are talking about<br> <fremy> TabAtkins: now we talk about "default if you omit it in the declaration" not the "default if you omit the declaration"<br> <fremy> dbaron: is this widely implemented?<br> <fremy> myles_: no<br> <fremy> dbaron and tabatkins arguing about default vs initial<br> <fremy> dbaron: i would want the default to be the same as the initial<br> <fremy> fantasai: +1<br> <fantasai> s/default/default if omitted/<br> <TabAtkins> [dbaron kept using "default" to mean "initial value", when I and Myles were purposely using "default" to mean a totally separate concept]<br> <fremy> fantasai: if we don't do what david wants, yes, there is not breaking change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1652#issuecomment-319952560 using your GitHub account
Received on Thursday, 3 August 2017 12:18:06 UTC