- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Feb 2021 16:25:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Specifying changes to parameters for fallback fonts`, and agreed to the following: * `RESOLVED: Solve the general case of fallback font adjustment via @font-face descriptors` * `RESOLVED: Add advance-override descriptor to Fonts 5, precise details TBD` <details><summary>The full IRC log of that discussion</summary> <gregwhitworth> Topic: Specifying changes to parameters for fallback fonts<br> <chrishtr> q+<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/126<br> <gregwhitworth> chris: the general principal is wanting to change things based on which font was actually used<br> <gregwhitworth> chris: so you set them conditionally, they expect a simple syntax. Much of this thread is to say that most simple solutions are not going to work<br> <astearns> ack chrishtr<br> <gregwhitworth> chrishtr: I wanted to point out a few things<br> <gregwhitworth> chrishtr: which syntax would be used<br> <gregwhitworth> chrishtr: main usecase that xiaochengh had in mind was automatically overriding when you have a fallback of a webfont you want to limit jumping of the webpage and add little to not difficulty to the author because it behaves automatically<br> <leaverou> q+<br> <gregwhitworth> chrishtr: the one alternative is to have a CSS property that has augmented syntax and I think that would end up being quite complex because it would need to repeat<br> <astearns> ack leaverou<br> <gregwhitworth> leaverou: there have been many proposals, they seem to revolve around changing the font-props<br> <gregwhitworth> leaverou: the syntax would get quite complicated<br> <gregwhitworth> leaverou: rather than change props let's add inline conditionals based on prior resolutions of inline conditionals<br> <gregwhitworth> leaverou: you can then branch however you want and it only gets as complicated as the author needs it to be<br> <gregwhitworth> leaverou: so you can end up with multiple font-families in a single element<br> <drott> q+<br> <gregwhitworth> leaverou: you don't want a different letter-spacing for every glyph for example<br> <gregwhitworth> leaverou: this gets future improvements for conditional syntax<br> <gregwhitworth> myles: one of the args against my proposal was unreadable and I think this may be more unreadable<br> <astearns> ack drott<br> <gregwhitworth> astearns: that would depend on the general usage but yes more flexibility usually adds complexity to parse<br> <gregwhitworth> drott: would you add a way to selector for the inline font?<br> <gregwhitworth> leaverou: no a keyword, such as accentColor<br> <gregwhitworth> leaverou: I can drop a link to the proposal<br> <leaverou> https://github.com/w3c/csswg-drafts/issues/126#issuecomment-775990597<br> <leaverou> s/accentColor/currentColor/<br> <xiaochengh> q+<br> <drott> q+<br> <gregwhitworth> astearns: I'm thinking this is a good thing to get too, but this more immediate need a descriptor rather than waiting for a solution to the conditional styling<br> <astearns> q?<br> <gregwhitworth> myles: in the last issue we were going to add one of these degrees of freedom to the descriptor<br> <gregwhitworth> myles: as a more concrete proposal should we try to add 4 additional descriptors to ensure alignement?<br> <chris> q?<br> <astearns> ack xiaochengh<br> <gregwhitworth> xiaochengh: the proposed syntax of this property is complicated and the implementation will be complicated too<br> <drott> q-<br> <astearns> ack fantasai<br> <gregwhitworth> xiaochengh: I'm not sure how to implement that in Chrome to be honest<br> <gregwhitworth> fantasai: I think going with the descriptor is a much better way than trying to embed this in font properties especially so many CSS calculations depend on those properties<br> <gregwhitworth> fantasai: properties are really weird to bind font-face to some value<br> <myles> q+<br> <gregwhitworth> fantasai: we can't just put it into the font-face rule, you'd want different styles to different elements, we're going to have derivitives of the same font-face with different overrides<br> <gregwhitworth> fantasai: it would be good to cascade in so you don't have to repeat them<br> <gregwhitworth> myles: so inheritance for at rules?<br> <leaverou> q+<br> <gregwhitworth> fantasai: cascading rules which is what counter style does<br> <gregwhitworth> fantasai: I support jonathan's proposal overall<br> <astearns> ack myles<br> <fantasai> jfkthame's proposal https://github.com/w3c/csswg-drafts/issues/126#issuecomment-764641927<br> <gregwhitworth> myles: one of the degrees of freedom is font-weight and that is a matching property<br> <gregwhitworth> myles: so if we want to have an override I'm not sure how that would work<br> <florian> q+<br> <cbiesinger> q+<br> <cbiesinger> hm<br> <cbiesinger> qq+<br> <gregwhitworth> myles: what that should mean is that that element shouldn't select the defined font-weight<br> <drott> q+<br> <gregwhitworth> chris: that shouldn't impact matching<br> <astearns> ack cbiesinger<br> <Zakim> cbiesinger, you wanted to react to myles<br> <chris> q?<br> <gregwhitworth> christian: could you solve that issue by having a font adjustment factor, so if the fallback is used you can multiply by something like 0.9<br> <cbiesinger> q-<br> <gregwhitworth> myles: so if you fallback to font-x use a factor of .8 or .9 for font-y<br> <gregwhitworth> myles: I think that's what chris was saying<br> <gregwhitworth> fantasai: would that work with variable fonts?<br> <gregwhitworth> myles: no it wouldn't work for var fonts<br> <gregwhitworth> fantasai: jonathan's solution has a mapping table<br> <gregwhitworth> florian: font-weight is the odd one here<br> <astearns> ack florian<br> <gregwhitworth> florian: they're not really numbers they're a way to match a font that happens to map to numbers<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <myles> q+<br> <gregwhitworth> florian: if we're dealing with variable fonts we need to map to ranges or series<br> <gregwhitworth> florian: the others are actual measurements, this one is weird<br> <gregwhitworth> leaverou: I want to say we're discuss two orthogonal issues and one is trying to provide a better fallback and one trying to improve styling for ones that were selected for fallback<br> <drott> q-<br> <gregwhitworth> leaverou: there are usecases that are local fonts eg: Mac vs Windows fonts<br> <gregwhitworth> myles: the folks we've talked with are fine with font-face being used<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <TabAtkins> ScribeNick: TabAtkins<br> <TabAtkins> myles: There are these props we're interested in<br> <TabAtkins> myles: weight, size, letter-spacing, word-spacing, line-height<br> <TabAtkins> myles: line-height might be taken care of by ascent/descent-override<br> <TabAtkins> myles: letter-sacping resolved in last issue<br> <TabAtkins> myles: font-weight sounds hard, need more time<br> <TabAtkins> myles: but font-size and word-spacing, maybe we could make progress<br> <TabAtkins> jfkthame: font-stretch?<br> <TabAtkins> myles: could be. would you like it to be?<br> <TabAtkins> chris: yeah, condensedness should be in the list<br> <florian> q+<br> <TabAtkins> astearns: Wondering if we should have a general reoslution to solve these things as @font-face descriptors, and start getting spec text for this<br> <leaverou> q-<br> <chrishtr> Agreed on font-face resolution being a good next step.<br> <chrishtr> And then discuss types of overrides.<br> <TabAtkins> astearns: For previous issue, for the simpler things here, and then ahve separate issues for each type of override<br> <TabAtkins> astearns: This is alread a giant issue that tends to spin out into overlapping convos<br> <chris> Yeah that sounds like a plan<br> <astearns> q?<br> <TabAtkins> florian: A discussion over the break: instead of specifying the amount you want to adjust the font, specify the target amount<br> <TabAtkins> florian: UA could adjust automatically, but could be flexible with variable fonts, etc<br> <TabAtkins> florian: Or choose different fallbacks with better metrics<br> <fantasai> TabAtkins: That might work for some things, but I can't see how it would work for advance<br> <TabAtkins> myles: It'd be an overall tracking value, like "make the average character width X sized"<br> <TabAtkins> jfkthame: Too many questions there, how to average?<br> <TabAtkins> florian: Not harder than just using the adjustment<br> <fantasai> TabAtkins: Disagree<br> <fantasai> TabAtkins: Current proposal only adjust the fallbacks.<br> <fantasai> TabAtkins: Take the good font, then load fallback and tweak it until to works<br> <fantasai> s/works/works the way you want<br> <TabAtkins> myles: This is why I opened an issue for font-size-adjust:auto<br> <TabAtkins> myles: Right now author needs to guess<br> <fantasai> TabAtkins: At least you can guess and check for font-size easily, but see your point in general<br> <TabAtkins> myles: So suggested we have an auto for that<br> <astearns> ack fantasai<br> <astearns> ack florian<br> <TabAtkins> fantasai: There was discussion about reoslution<br> <TabAtkins> fantasai: proposed resolution is to address these use-case with descriptors<br> <TabAtkins> fantasai: Don't think we can be more specific atm<br> <TabAtkins> fantasai: I know Chrome wants to address the advance-override case sooner rather than later, so we should make progress on making that concrete<br> <TabAtkins> astearns: So resolve the general descriptor, and specifically add advance-override<br> <TabAtkins> fantasai: in Fonts 5?<br> <TabAtkins> myles: yeah<br> <TabAtkins> astearns: objections?<br> <TabAtkins> jfkthame: Not quite sure we know what advance-override means yet - details tbd?<br> <TabAtkins> astearns: Yes, we resolve to add it, can spin out issues to nail down details.<br> <TabAtkins> RESOLVED: Solve the general case of fallback font adjustment via @font-face descriptors<br> <TabAtkins> RESOLVED: Add advance-override descriptor to Fonts 5, precise details TBD<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/126#issuecomment-776063005 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 16:25:33 UTC