Skip to content

[css-inline-3] text-edge doesn’t allow for fine-tunability (like how line-height does) #8478

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

Closed
litherum opened this issue Feb 20, 2023 · 2 comments
Labels
css-inline-3 Current Work

Comments

@litherum
Copy link
Contributor

litherum commented Feb 20, 2023

[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) change
  • line-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”
  • Alternatively, we could define units for these metrics, so the author could say something like 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.

@litherum litherum added the css-inline-3 Current Work label Feb 20, 2023
@litherum litherum changed the title [css-inline-3] text-edge doesn’t allow for fine-tunability (like how line-height does) [css-inline-3] text-edge doesn’t allow for fine-tunability (like how line-height does) Feb 20, 2023
@fantasai
Copy link
Collaborator

fantasai commented Mar 29, 2023

I don't think that these two properties can be merged. The inline contents of a line are not all identically sized and placed, so there's a question of whether something “fits” within the standard box or not.

The purpose of text-edge is to control what the bounds of an inline are for the purpose of determining its fit within a line box. This is distinct from controlling the desired height of the line box (line-height). Typically the distance from the top text-edge to the bottom is less than the desired line-height.

Now, you might want to be able to define the line height in terms of a line gap instead of a line height. And we could add syntax to allow for that. But it needs to be separate from what text-edge is doing, and it also brings up the interesting question in #5564.

@litherum
Copy link
Contributor Author

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-inline-3 Current Work
Projects
None yet
Development

No branches or pull requests

2 participants