[This is one of a series of issues we're filing about the design feedback of leading-trim and text-edge. As far as we know, these properties are unimplemented in any browser, which means now is a good time to give feedback on their overall design. For each of the issues we're filing, we don't have a fully-formed proposal that would solve the problem, but we do have some avenues of potential mitigation in mind, and we're offering these ideas as a starting point for further discussion.]
As described earlier, the ascent/descent metrics of fonts usually include a little bit of extra room in them. And authors usually don’t actually know where the ascent and descent of a particular font on a particular line lie. So, an author starts with a default rendering of their paragraph, and if they want it to be a bit looser, they’ll nudge the line-height up by a pixel or two or ten. If they want it to be a bit tighter, they’ll nudge it down by a pixel or two or ten.
text-edge doesn’t allow the author to fine-tune in this way. An author can’t say “base my line rhythm on the ideographic-ink layout bounds, but bump it up (or down) by 1 pixel because that looks better.”
A potential solution is to merge text-edge and line-height into a single property. The author could specify:
line-height: 30px just like they can today; that wouldn’t (can’t) changeline-height: cap alphabetic which would mean “the bounds for the inline box extend from the cap height down to the alphabetic baseline”line-height: cap 1px alphabetic 2px which would mean “the bounds for the inline box extend from 1px above the cap height down to 2px below the alphabetic baseline”line-height: calc(cap + 1px) calc(alphabetic + 2px).This way, the line rhythm that text-edge tries to implement today could be fine-tuned in the same way that line-height is fine-tuned.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3