- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jan 2018 17:45:06 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `[css-fonts-4] Should the OpenType spec dictate the acceptable values for variable font CSS properties?`, and agreed to the following resolutions: * `RESOLVED: No change for issue #1531` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-fonts-4] Should the OpenType spec dictate the acceptable values for variable font CSS properties?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1531<br> <dael> myles: There was an issue that was raised with a bunch of pieces. All but one were misunderstandings. One has become an issue. IN a variable font there are axises. There's a weigth one for example. The question is should there be limits on the acceptable values on these axises? If yes, what?<br> <dael> myles: For oblique you may not want >90. Weight no grater then 999. Etc.<br> <dael> myles: This came up because italic. There's two popular font formats and they both support variations. Open Type spec says it has limits on axis values, but true type doesn't have limits.<br> <dael> myles: When I wrote the spec I allowed both to be supported, however the issue is brought up saying that maybe it should be limited to the values in open type<br> <dael> myles: That's problematic because we won't be able ot use both types equally.<br> <Vlad> I think there is a lot of misunderstanding here, and many assumptions need to be verified prior to making a final decision.<br> <dael> Chris: I'm not sure I'd put it the same way. I understand aat does thigns differently. It's not jsut range, but default values. I rememebr I feel into this using a non-open type font and the ranges were something like 0-4 and that was problematic.<br> <Vlad> For details, one might want to look at https://www.microsoft.com/typography/otspec/otvaroverview.htm#CSN<br> <dael> Chris: To my mind most of fonts 3 and 4 are based on open type. THen we said how other formats map to that. Id on't mind if it says for aat fonts there are different things. Where open type has the same range for everything is more intuitive.<br> <dael> myles:I understand that point. Counter is there are default values in teh true type spec. There is a straightforward mapping to the scales CSS uses. I don't think...we are making a new standard so we should make one that both font files apply equally. It's possible.<br> <dael> Chris: Could you say more about the it's possible? If they're using different initial values I don't understand how to compat.<br> <dael> myles: The scales can be linearly mapped. For weight CSS says default is 400, true type is 1.0. 1 maps to 400, 0 to 0.<br> <dael> Chris: Okay, okay. hmm.<br> <dael> Chris: That sounds persuasive.<br> <dael> Chris: I dont want to be reluctant, but seeing spec text would make me happier. I would like to see specficially what youw ant to change.<br> <dael> myles: Proposal in the issue is limit the acceptable range tot he italic variable fonts axis.<br> <dael> myles: Proposal was change the spec. I would argue we shouldn't change and accept all values because both fonts can work with that.<br> <dael> Chris: That's for italic where it doesn't mean oblique.<br> <dael> myles: Yes.<br> <dael> Chris: Then I'm a lot happier.<br> <dael> jensimmons: I'm working with a team looking at variable fonts as we design tooling.<br> <dael> jensimmons: we were thinking of weight with a slider at 0 to 1000 where a font may have juciness between 200 and 800, but the slider would show the whole thing. SOunds like that's what you're talking about where css has an upper range limit and I would say yes. WE could make a better tool. Elsewise the only numbers are those in the font.<br> <Vlad> I think we should carefully revisit this topic. I believe many assumptions about what the variation axis value represents need to be revisited.<br> <dael> jensimmons: Then the tool would change as people go font to font and they're trying to set fonts for all of a stack.<br> <dael> Chris: That's what I was trying to set. But people use use font stacks less and they're more setting features on a font and providing it. The idea that you would set two values i"M trying to avoid.<br> <dael> myles: I want to also. My position is that for the axises browsers know there is one scale representable for that axis. CSS desc that, browsers impl that, then that scale is mapped to the underlying font tech to make that font have the desired effect.<br> <dael> Chris: sgtm<br> <dael> Rossen_: Sounds like we're coming to a consensus.<br> <dael> Rossen_: One person that's IRC only and was active on GH is vlad. I want to make sure his point is looked at.<br> <dael> Rossen_: Vlad are you on the call?<br> <Vlad> I am on the call but you don;t seem to be able to hear me<br> <dael> Rossen_: We cannot hear you.<br> <Vlad> Let me try anpther audio connection<br> <dael> Rossen_: While Vlad tries to fix his audio, Chris or myles did you get to read his IRC comments?<br> <dael> Chris: I read them, but I don't know what he means exactly.<br> <jensimmons> or she<br> <dael> Vlad: Sorry about that. Iw as trying to say that I'm fine with leaving as is, but I htink we need to revisit carefully in detail. Assumptions we make in what the font variation axises are may not hold. Even for weight the assumptions we make that all fonts can support a particular limit is not true, that's up to the designer.<br> <dael> Vlad: WE can't easily resolve right now so we can leave spec as written, but we need to make an effort to ensure what we have will be usable when spec if finalized.<br> <dael> Vlad: Ex. regular and condensed fonts, the weight axis is not determinded by character stem width. Weight is how heavy the font is and the condenced will look more heavy with the same stem size. Weight is somewhat relative. Therefore assuming 900 looks the same is not true, nor is it true 900 is always supported.<br> <dael> myles: I'm happy to go through this in the future with you.<br> <dael> Vlad: I jsut wanted to make sure that nothing is set in stone right this moment.<br> <dael> Chris: Vlad remember the descriptors can say what range, like this font is 100-350 and if you ask for 500 you get a different font.<br> <dael> Vlad: Yeah. But some axises, like italic, don't have a particular range and the varation may change for fonts. Oblique is more straight forward. The variation for italic isn't as deterministic as slant, for example.<br> <dael> Rossen_: I'm trying to see if we can scope an end. Vlad with the current proposed resolution it doesn't sound like we will be constrained with the concerns you have.<br> <dael> Rossen_: And reading myles he'd be happy to revist this when we get to it.<br> <dael> Vlad: What' I'm saying is what's in the spec is based on assumptions about font behavior where there are varaitions. We need to revisit those assumptions before we make a final call<br> <dael> Rossen_: Do you guys want to go back to GH?<br> <dael> myles: I think what Vlad is covering is a seconadry issue. If you have specific places where it may be broken I'd encourage you to open new issues. On this specific topic I'd hope we can resolve.<br> <dael> Vlad: My concern is this particular issue where the new name from it, I don't think that's even possible. Open type spec couldn't dictate even if you want it too. Variation values are normalized to what the font designer encoded. THe effect of the variation axis will not be the same for every font. I'm not sure how to take the issue title.<br> <dael> myles: The way the spec is designed there are 3 axises the browser understands. For those 3 I think it's reasonable there's a scale where if an author sets avalue in the scale the browser can do wahtever in that scale to prepresent. If the axis is something hte browser doesn't understand what can it do?<br> <dael> Vlad: I'm fine with this issue. BUt I think you're asumming the browser will know what to do with a value and I don't think that's always true.<br> <dael> myles: You should open a new issue for that.<br> <dael> Rossen_: So for the current, proposed resolution is?<br> <dael> myles: No change.<br> <dael> Rossen_: Proposed resolution is no change.<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: No change for issue #1531<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1531#issuecomment-358384560 using your GitHub account
Received on Wednesday, 17 January 2018 17:45:12 UTC