- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 15 Oct 2025 17:02:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-inline] Extend `text-box-edge` to support em-over/-under baselines and optionally support custom baselines``, and agreed to the following: * `RESOLVED: close no change - using @font-face descriptors to modify a particular font’s metrics is the intended solution for problems like this` <details><summary>The full IRC log of that discussion</summary> <emilio> chrishtr: so this was filed by a person working @ NRK (norweigian publishing company)<br> <emilio> ... they found some text-box-trim limitations<br> <emilio> ... so when trimming to the text the hope is it trims to top of ascender and bottom of descenders<br> <emilio> ... and lines would be taken care by line gap metrics<br> <emilio> ... but some fonts don't have line gap metrics and instead they have padding on ascender and descenders<br> <astearns> q+<br> <emilio> ... so they proposed alternative keywords for the actual text<br> <florian> q+<br> <jfkthame> q+<br> <emilio> ... so I'm kinda passing along this feedback and want to get discussion from other<br> <emilio> ack astearns<br> <astearns> ack florian<br> <emilio> astearns: how do we determine what this font metric is?<br> <emilio> florian: same, symphatize with the use case but without metrics we're just guessing<br> <astearns> ack jfkthame<br> <emilio> ... sometimes guessing is fine but in this case it looks like a buggy font<br> <emilio> jfkthame: same sort of comment<br> <djmarland> +1<br> <emilio> ... iirc the issue talked about metrics being normalized to be 1em apart<br> <emilio> ... but that has no relation to the actual glyph position<br> <astearns> ack fantasai<br> <emilio> ... so that's not that useful<br> <emilio> fantasai: same<br> <emilio> ... we do have the ability to override the metrics with @font-face so they could correct the metrics<br> <emilio> ... it'd be good if there were font metrics in the font tho<br> <emilio> chrishtr: do you think they'd be able to solve that with @font-face?<br> <emilio> fantasai: yeah<br> <emilio> chrishtr: so they'd hack whatever to subtract the 0.1em less?<br> <emilio> fantasai: they'd have to measure<br> <emilio> ... to figure out what it should've been in the font<br> <emilio> florian: another thing we could predict is that as this feature is more common<br> <jfkthame> q+<br> <emilio> ... but CSS is fully automatic and it's more important to have the right metrics<br> <emilio> ... so maybe this will be a nudge towards the fonts being more correct<br> <emilio> chrishtr: one of the alternatives was text-box-edge: 1em which seems like another way of doing the same<br> <emilio> fantasai: right but you want to tie to your specific font<br> <emilio> ... if the font metrics are wrong in a font you should fix it in @font-face<br> <astearns> ack jfkthame<br> <emilio> chrishtr: right, in case there's fallback or what not<br> <emilio> jfkthame: I think we should be a bit hesitant in terms of talking about font metrics being wrong<br> <astearns> RESOLVED: close no change - using @font-face descriptors to modify a particular font’s metrics is the intended solution for problems like this<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9148#issuecomment-3407438629 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 October 2025 17:02:07 UTC