-
Notifications
You must be signed in to change notification settings - Fork 647
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-fonts-4] Percentages in font-weight for relative weights #2690
Comments
I don't think you can get this to work in the general case anyway; afaik there's no rule that says "weight 800 has the same thickness as 400 at twice the size"... Nor does 50% of the parent's font weight necessarily mean half its stroke thickness. The numbers are just an arbitrary per-font scale. (Also for small-caps, there's no rule for what size the synthesized small caps should be wrt full caps, so that's not even possible cross-platform.) |
Why doesn’t |
Would an implementation of this have to do path analysis or render the same character multiple times in order to determine what font parameters to use? |
Obviously this would need to be tweaked on a per-font basis, but at least once you figure out the scale for a given font, that's it, whereas right now you have to tweak it individually for each font size and weight!! |
Why would it do that? The relative weight would be specified by the author, not the browser. It's exactly the same as relative font-sizes. The author figures out the relationship, the browser just applies the number. |
No, not at all. It is just doing
Those two are for the case of "I don't care what actual weight you use, just make it noticeably bolder". While this issue is the opposite "I really care what weight you use and want it to be this much times the weight of the parent element".
I think that optical sizing in variable fonts can also help with better synthesized super/sub, and maybe with smallcaps also. |
🤔 If the main use case for this is to either select a certain explicit stroke thickness or to match up two implicit lengths, maybe itʼs better to be able to specify the stroke thickness as a Intuitively, I would assume |
I just stumbled upon this again (well, the lack thereof) and I actually think I buried the lede here with the equalizing strokes use case. A far more common use case is when we want a bolder or lighter stroke than the surrounding text, in a way that's agnostic to the weight of the surrounding text. |
Presumably not |
I'm assuming you don't need to be able to do this across different families (hence my question about the browser having to measure the apparent width of characters in order to find a matching weight in a different family). Is the idea is to be able to say something like
... to make the weight scale up in proportion to the font's scale down, so the apparent weight stays the same? On the face of it, this sounds like a very natural addition to I wonder if this proposal actually would actually allow for images like the one posted above. In this example, I would expect the three lines to be sibling elements rather than descendants of each other. |
I guess there's one other comment: I would expect the resolution of this percentage value to be done before the font matching algorithm is run. So, if the parent element has I would also expect it to inherit the same way that |
One problem: |
For some of these, it seems like a desired behavior might be to add or subtract a specific adjustment rather than multiplying by a percentage. For that, perhaps syntax like: font-weight: lighter(100);
font-weight: bolder(300);
font-stretch: more-condensed(25%); /* better name wanted! */
font-stretch: more-expanded(12.5%); /* same! */ might be desirable? |
@dbaron If 100% corresponds to the inherited font-weight (stretch, etc), |
Now that
font-weight
became a number with variable fonts, I think we will see many use cases for wanting to use a font weight that is relative to the parent's font-weight.This would have been useful even before variable fonts, for emphasizing parts of text regardless of its weight, as to avoid
<strong>
having no effect when used in bold text, or having an extremely strong effect when used with light text.However, variable fonts open up a swath of use cases for small weight tweaks. Namely:
Right now such tweaks are possible, but have to be performed on a case by case basis and break when the base font weight changes. It can be sort of emulated with custom properties, but it's very awkward because it's impossible to get the parent value of a property AND set it (things like
--font-weight: calc(.4 * var(--font-weight))
are invalid cycles). Actually, I'm not even sure how to implement this with custom properties for an arbitrary nesting level.It would be so much better if I could just say
font-weight: 90%
to mean "90% of the parent's font weight", and is consistent with howfont-size
works too.The text was updated successfully, but these errors were encountered: