[css-inline-3] text-edge
doesn’t allow for fine-tunability (like how line-height
does)
#8478
Labels
css-inline-3
Current Work
[This is one of a series of issues we're filing about the design feedback of
leading-trim
andtext-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
andline-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 thatline-height
is fine-tuned.The text was updated successfully, but these errors were encountered: