The CSS Working Group just discussed Leading Control.

How does it react to fragmentation?

What does leading-trim-under: alphabetic mean?

Another common pain point today is vertical centering. It's easy to vertically center the text container to an icon, but that often isn't the intended visual effect:

What I usually want is:

leading-trim would enable some new possibilities, like swapping out fonts without breaking the design intent:

Microsoft's XAML has a very similar notion to leading-trim on their <TextBlock />, a property called TextLineBounds.

I wanted to share one more situation—in multi-column layouts, I often wish I could set the top margin directly to the baseline to make sure make sure two bits of differently sized text are base-aligned:

Something like leading-trim-over: ideographic-bottom would let you easily achieve baseline alignments while sticking to a standard spacing convention (for example, increments of 10px).

Related: #2228

I need to be able to ensure 100% consistent text-positioning across platforms (eg for very large words), especially regarding the effective y-position of the glyphs, even if the font file states something else or can be considered "broken". The list of workarounds include using SVG text, or eg manually setting eg negative/positive margin-top / margin-bottom per OS/browser.

More info, screenshots, test-pages etc at #2228 .

Will the feature proposed in the ticket here offer that? Including in cases where there's nothing to snap to / align to?

@WestonThayer Wrt #3240 (comment) Is that an actual multi-column layout or is it multiple columns like we have e.g. in grid or flexbox or float layouts, where the column breaks are not due to fragmenting a single flow but due to placing two elements side-by-side? Because in the latter case we have the baseline alignment values. Trying to do it in the actual multicol case would need... some thought, and possibly an actual baseline grid. I don't think this feature would work well for it, because if the second headline doesn't wrap to the next column, you want a different sort of spacing than you need to get the baselines to line up.

@litherum Fragmentation is an interesting case. It's quite reasonable to want the text-trim to take effect at fragmentation breaks in multicol. But for pages, we'd end up trimming any ink that leaks over. We'll either need to adjust css-page-3 to not trim overflow at fragmentation boundaries or add a page-padding property similar to scroll-padding or something. This is actually necessary for ruby to work properly in Japanese, and many other effects that require the top of the text to line up across fragmentainers but allows some lines to contain content that overflows that visual line.

@litherum alphabetic means we trim to the alphabetic baseline. So descenders would overflow the line (similar to ascenders overflowing the cap height if leading-trim-over: cap is specified). It would allow the effects @WestonThayer describes in #3240 (comment), among other things, while still preserving inter-line spacing if that text wraps to multiple lines.

@tobireif It won't affect inter-line spacing within the same block, but it can help with that kind of problem between blocks, yes.

@fantasai re: #3240 (comment) good question, no I didn't intend my example to be a multi-column layout, rather positioning two elements side-by-side.

I often find it difficult to achieve this effect using the baseline alignment value because the bits of text I want base-aligned often do not share the same alignment context. For example, consider this design that uses the "card" UI pattern:

Because it's most convenient to enclose the headlines within a <div> (to set the background, border, and padding), the <div> ends up being what shares the alignment context within a layout container like Grid or Flexbox that has access to the baseline alignment value.

@WestonThayer That should still work. We pass up alignment baselines from first child to parent, generally-speaking. There's a few exceptions, but that example is expected to work. Set align-items: baseline on the flex container containing the two cards.

@fantasai oh wow, I did not know that! Thank you for sharing.

Is there a way to keep the card backgrounds top-aligned, without guessing at a padding-top value for the sidebar card? Example here: https://codepen.io/WestonThayer/pen/qQQvoN

@WestonThayer Use align-content: baseline on each item instead of align-self: baseline. See https://www.w3.org/TR/css-align-3/#overview https://www.w3.org/TR/css-align-3/#content-distribution (It's not very well-supported yet, though.)

@fantasai is it supported anywhere you know of?

@astearns Yes, Firefox has partial support; it works within Grid Layout, but not other layout models yet. See testcase.

I wrote a longer form post on why leading-trim would be useful: http://westonthayer.com/writing/intro-to-font-metrics/

I love this proposal! It would be hugely useful for refining typography.

alphabetic means we trim to the alphabetic baseline.

@fantasai why not just use baseline as the value name? Isn't that a more commonly-known term?

What is ideographic? The bottom of symbols, or certain scripts, or something else? It might potentially be helpful to add definitions of proposedvalues to the top comment here...

@thundernixon Because there are many different baselines, given we have many different writing systems. :) So we have to distinguish the alphabetic one from other ones. Ideographic is about Chinese/Japanese/Korean baselines.

It would be great if you could add this to the agenda.

I want to chime in in support of a line-height-trim property as well. I believe this is entering the design systems zeitgeist right now and any work that can be done to fix this would be appreciated. For what it's worth, this issue was recently talked about in the Full Stack Radio podcast (episode 134) where Mark Dalgleish talks about the challenges in fixing this in the Braid Design System.

I sincerely believe a native CSS fix for this would be a huge win.

Also adding support for this. There are a number of tools in the wild that take care of this via SCSS mixins that generate negative margin (see: http://text-crop.eightshapes.com/), but having a trim as part of the spec would be much more convenient and universal.

Im gonna pile onto @calebdwilliams comment, because I'm the one that pointed him at that podcast :)

Basically, it sort of just clicked in my brain that unless developers handle this extra space, then no one is really creating "pixel perfect" representations of designs made in tools like figma and sketch, because designers dont think about/account spacing for the leading that chrome adds because of line-height rules.

So, the CSSWG accepted to do this and we've published some drafts (sorry for the late update here), see current state at:
https://www.w3.org/TR/css-inline-3/#line-height
[Notes: 4 June update and 23 June update]

We're still trying to figure out how best to handle the ergonomics of this, so comments and feedback is very welcome (although filing separate issues for each subtopic is preferred). ^_^

Some of the currently open issues include:

• application to descendant blocks
• handling descendant inlines of differing sizes
• dealing with pagination
• internationalization / missing OpenType metrics

There's also some ongoing exploration of the interaction of leading-trim and other features relating to line box sizing, see #5239

I'd encourage everyone interested in this feature to have a look at the draft and think about it, and let us know if we're forgetting anything, or if you think something could be handled better!

Note: One of the major principles of designing CSS, btw, is making sure the system is robust to unexpected situations: fonts not loading, larger/smaller window sizes than expected, atypical user input, translations into other writing systems, etc. This feature is a little bit dangerous because it potentially cuts out significant parts of the text from being measured. One of the challenges for Inline Layout in particular is figuring out how to balance that need for robustness with the finicky needs of optically aligning text. :) So keep that in mind as you review the draft...

@fantasai wrote:

see current state at:
https://www.w3.org/TR/css-inline-3/#line-height

Should the URL in your post be https://www.w3.org/TR/css-inline-3/#propdef-leading-trim instead?

@tobireif The various features in that section interact, so I figured it was better to link to the top of the section for anyone wanting to understand how it all works.

@fantasai one possible issue could be ellipsis as overflow hidden would probably remove parts of the text

  text-oveflow: ellipsis;
  overflow: hidden;
  white-space: nowrap;

from the faq of https://seek-oss.github.io/capsize/

@jantimon text-overflow: ellipsis and overflow: hidden are paint-time effects that hide the text, so have no effect on layout.

I haven't seen x-height as a possible value for leading-trim-under.

The approach is often used when setting flowing text next to images:

I would go as far as using it for vertically centering button text:

Hey all. I'd like to expand on what I was getting at above with a few more examples:

In two of the cases (Example 2 and 4) it's very useful to be able to trim at the x-height, as this is how some designers lay out text. In Example 1 it's also handy to balance the cap trim by stopping at the descender instead of trimming up to the baseline.

So to restate: If the objective is to achieve optically balanced padding around text, we would need to vary the amount of trim according to the type of content. Different capitalizations will require trimming at various typographic metrics other than the baseline or cap-height. In the provided examples the x-height and the descender length prove to be useful values as well.

i will jump very high when this is realized i love this

Currently we are exploring potential alternative names for leading-trim because of negative feedback on the word leading: #8067

leading-trim is now part of Safari Technology Preview 163 🥳 🎉

I am not sure what that means for the naming discussion in #8067

@jantimon The implementation in Safari Technology Preview 163 is just for experimentation, and it's expected to change in response to feedback (which we hope to get due to said experimentation!) We're still expecting significant changes before it's ready to ship, and renaming some properties (or even refactoring how they interact) is still on the table. :)

Would leading-trim-over: baseline work?

Then something like this would be possible:

As an update, we did some refactoring of this feature and republished.

• Summary of the changes in this issue.
• Updated draft is available here.

There's also some interesting open questions. Feedback is welcome, and there are prototype implementations now in both Safari Technology Preview and Chrome Dev as they work on aligning to the spec.