Issues related to new CSS Leading Trim feature.

The web rejoicing about the new CSS feature "Leading Trim" in the making which fundamentally changes how text is aligned in their frames on webpages (See image below).



Though in a first glance I was excited about it on close inspection I found these issues. I want to share this with you to get you to feedback on the concerns listed below. To see the concerns with example use this link to the Figma File: https://bit.ly/34nqMLC

Taking into consideration just the cap height and baseline:
1. leaves out most of the use cases (words with descenders).

2. not always the right way to optically align text vertically (
Leading trim applied across different typefaces with equal spacing interchangeably won’t work as smooth as shown in the CSS draft.)

----

3. Leading trim is not that effective in case of words with Diacritics.

4. The alignment becomes more complex in case of Devanagari script so a hanging baseline and alphabetic baseline metric currently proposed won’t suffice the alignment issue.

5. Setting the font size to a whole number in the current design software won’t yield to whole numbers for “leading-trim height” in all the fonts.

Does this mean in future design software will set font sizes based on Leading trim size?

6. The system is not that beneficial in case of 4px grid system until the moment design applications provide a way to align using the same method. Even if that is implemented, designers working
on design system will have an added responsibility of taking into consideration text with a high amount of descenders. Which is not in control of the designer.




Comments

  • Craig Eliason
    Craig Eliason Posts: 1,436
    So this automatic solution has problems in certain circumstances like the automatic solution it replaced had in other circumstances. Which suggests to me this is a problem that can't be effectively automated. 
  • So this automatic solution has problems in certain circumstances like the automatic solution it replaced had in other circumstances. Which suggests to me this is a problem that can't be effectively automated. 
    Yes, that is my point. And I want to understand if I'm thinking in the wrong direction or I assumed anything which wrong.
  • fundamentally changes how text is aligned in their frame
    Of course it doesn't change anything per se. Obviously, this is not a replacement for a standard behavior, but a brand new, opt-in feature, used at designer's/developer's discretion, so I don't really see what seems to be the problem?
    h1 { 
    text-edge: cap alphabetic;
    leading-trim: both;
    }
    And I do think text-transform: uppercase is a pretty common use case where this would be quite useful. The whole point here is to have the design adapt to changing fonts that might not have compatible metrics and have the padding/margin stay visually the same. And I think that is pretty awesome, being a CSS way of extracting information (indirectly) from a font file.