- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Sat, 16 Nov 2024 22:07:36 +0000
- To: public-css-archive@w3.org
This came up again today: https://bsky.app/profile/swyx.io/post/3lb2x53wuwc2y I think it's pretty obvious at this point that the use cases are vast. I've personally come across them numerous times. Can we brainstorm potential ways to make this possible with CSS in a small (ideally fixed) number of passes? UAs are at an advantage here because they have access to font metrics that author code doesn’t. Naively, it seems like something like this should converge pretty fast, and would only need more than 2 passes on fonts with some very elaborate optical sizing axes: 1. Render the line at font-size = _target_width_ / _number_of_visible_characters_in_line_ as a crude first approximation. 2. Measure its width and figure out the ratio of that to the target line width. 3. If the ratio is != 1, scale the font size by the same ratio. 4. Repeat 2 until the ratio is 1 For monospace fonts you’re done at 1. For fonts with no optical sizing axis, you need 2 passes. Even for fonts with an elaborate optical sizing axis, it’s _extremely_ unlikely to need more than 3 passes. It would take an optical sizing axis designed specifically for this purpose to take many passes or even hang a browser. To prevent hangs due to maliciously designed fonts, we could define that this process never does more than 5 passes — if you get to that point and the ratio is still != 1, you just scale what you have and don't apply any further optical sizing adjustments (i.e. the optical sizing axis is still set to the previous value). > Using a small number of passes is unlikely to work in the general case, because if we get it wrong, the text will overflow its container and wrap, which would be catastrophic. Any generalized implementation would have to iterate until the algorithm converges. Such an algorithm would be a great way to make a browser hang. I think we should define that this is only possible when `text-wrap-mode` is `nowrap`. Also, one way to deal with minor error in the algorithm is to adjust spacing as the final step. It would only need a tiny adjustment in spacing, which wouldn't be noticeable. ---- While even just a font-size adjustment would be a major help for these use cases, I want to raise the issue that to do this well, you want to adjust weight *in addition* to font-size so that the strokes of the end result appear similar. [Here's a segment of one of my old talks about this](https://youtu.be/8BXQ3zCihYM?si=uPKkbF1nOY__usIC&t=1944) where you can also see how painful it is to do manually. <img width="321" alt="image" src="https://github.com/user-attachments/assets/4f647d93-7ee3-405d-80bc-d9870c0612f4"> <img width="313" alt="image" src="https://github.com/user-attachments/assets/755daf58-6766-4a3c-abeb-b1192d5729ee"> So ideally, we'd want to design a syntax that could support this in the future, even if the MVP is just a `font-face` adjustment. This is not as simple as "adjust font-weight based on the adjustment in font-size" because adjusting the font-weight *also* adjusts the font size. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2528#issuecomment-2480826168 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 16 November 2024 22:07:36 UTC