CSS Text Box Trim | Hacker News Reader

CSS Text Box Trim

github.com

222 pointsbpierre52 comments

Open articleView on HN

Typography

The two most needed CSS properties for better web typography are Text-Box-Trim, as well as Margin-Trim

Please browser dev’s, implement both of these.

https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim

—-

Here’s a JS hack in the mean-time:

https://seek-oss.github.io/capsize/

Capsize is great! It's worth noting that it's not really a "JS hack": it doesn't require you to ship JavaScript to the browser. Capsize is written in JavaScript, but it's just a function that takes information about a specific font and typography information and outputs static styles, meaning you can run Capsize at build time or even just copy the generated CSS straight from their web site.

However, you can never guarantee the font text will be rendered in, so if you precalculate you may damage things. Web fonts may fail to load for a variety of reasons. Some users will force their own chosen fonts. In Firefox: Setting → Fonts → Advanced → untick Allow pages to choose their own fonts, instead of your selections above. I’ve done that for the last four years, as it makes the web so much better.

I don't know that I really get the point of margin-trim - there are already plenty of other, arguably clearer ways of avoiding padding at the start and end of an element - using flexbox and the gap property, using :not, even the classic + selector works pretty well here.

Is it designed to do more than just that, or is it just about avoiding gaps at the start and end of lines of elements?

margin-trim is basically a simpler alternative to adding a margin-bottom to every child, then removing the margin-bottom from the last child with :last-child { margin-bottom: 0; }

Flex with gap is also an alternative to that, and in my view should be the default thing you reach for. But there are some cases where the child margin approach has benefits, particularly if you're doing certain animations/transitions or if you want each child to essentially override its top or bottom gap.

But can't you do .selector:not(:last-child) ? Or .selector + .selector ? Both of these seem clearer than adding an extra property just to handle this case.

Like, I understand the situation, I've been in that place plenty of times. But I've never felt in want of a solution there.

I often use the so-called "lobotomized owl selector" (* + *) in the reset I use for my own internal tools. More specifically:

    * {
      margin: 0;
      padding: 0;
    }

    * + * {
      margin-top: 1em;
    }

That JS hack looks perfect. Except it shows up just how bad a font I've had to deal with is - Bebas Neue where the dimensions are just completely out of wack on it's little chart.

Related blog post, that was recently submitted to HN: Hardest Problem in Computer Science: Centering Things (https://tonsky.me/blog/centering/).

This feature would fix alot of the problems with centering fonts (icon and text) vertically, which is currently not really possible, at least not easily.

This will be very useful, especially for vertical aligning, but as of today is essentially unsupported:

https://caniuse.com/css-text-box-trim

This will be very useful, especially for vertical aligning, but as of today is essentially unsupported:

Looks like Safari beta is the only current option.

It's always funny how Safari gets so much heat on HN for being "behind" on things, when it's so often ahead on features.

For example, it's the only browser that supports hanging-punctuation, and supported JPEG2000 since 2011.

Safari IS often behind on things. It's the ONLY major browser that doesn't support 'overflow-anchor: auto' even though that's been the default in all other browsers for years now. https://caniuse.com/css-overflow-anchor

Their TP finally implements it, but years late.

Apple's hesitance on implementing browser features can also be a positive. They held off on web push forever which is a good thing because web push is horrible and just opened the floodgates for everyone's grandma's Samsung phone being constantly covered with online gambling ads. When Apple finally implemented it, they did it so it's only allowed for web pages saved to your homescreen like an app which I think is a good compromise.

Safari is the only thing stopping Google from running rampant with implementing new "web standards" because all browsers on the iPhone are Safari, so everyone needs to make sure their site works in a browser other than Chrome.

This is looking to be on borrowed time unfortunately because regulators are looking to force Apple to allow other browser engines. So look forward to Google's stranglehold on the internet being further cemented.

Safari also entirely disables CSS multi-column when printing per this 17 year old bug: https://bugs.webkit.org/show_bug.cgi?id=15546.

I think Safari's priorities closely map Apple's priorities and DNA.

So when it comes to presentation (how text is presented, typography, color spaces, HiDPI, etc, all things that benefit an overall design, user experience) Safari always seems to be way ahead of the rest.

But when it comes to stuff that developers want (stuff that mostly makes devs more happy), it may tend to lag more behind.

That mirrors Apple's general priorities of often prioritizing user experience over dev experience.

And even though I'm a developer, I happen to kind of agree with that prioritization..... on most days :-)

I remember something in the whatwg ideals saying something along the lines of: users before developers before user agent developers

Apple prioritizes thus: Apple first, its users second, its devs third.

They never stray from that.

Well, that’s all the browser vendors. Their interests first.

> It's always funny how Safari gets so much heat on HN for being "behind" on things, when it's so often ahead on features.

To be fair to HN this has been a relatively recent change. Jen Simmons and Webkit/Safari teams have really stepped up their game.

It's not recent. Safari has always been pushing and adding things, just not what Google wants.

All of these things are relative, let's not pretend they aren't. Safari has always been pushing _some_ things and has been significantly behind in others. From my own memory bank: Chrome implemented WebGL in 2010, Apple took until 2014 to finally bring it to iOS Safari. That actively held back work I was doing.

It's very easy to dismiss any web improvement as being something Google is shoving down everyone's throat but it's not true, a lot of them are things developers are crying out for.

I can relate to your work being impacted by webGL not shipping on iPhone, but we both know why Apple took so long: because they invest less than Google in their browser, and the investment they make cannot regress speed nor battery life. I side with Apple on that view.

They’ve recently started investing more in the browser, but haven’t moved on degrading battery life. I wonder why they’re suddenly investing (cough cough DMA)

“they don’t allocate resources to the project” is context, not a reason. We’re allowed to resent that choice made by one of the biggest companies in the world.

That was the reason?? With something like that I would have assumed it was mainly Apple worrying that big developers might start getting wise-guy ideas like shipping games on the web to avoid the ol’ 30% racket.

> just not what Google wants.

or what developers like myself want. There was absolutely a significant period of time where it felt like I was dealing with the new IE in the age of evergreen browsers.

Just because Safari can sometimes be ahead, it's still the browser that lags the most. And sometimes we're talking about years behind Chrome and FF (WebRTC being the example I directly suffered from).

I remember having to jump trough a series of silly hoops just to get audio encoded in Opus to play on Safari browsers. They do indeed drag their feet on seemingly arbitrary things.

Safari is the only browser that doesn't support extending HTML element

https://caniuse.com/?search=Custom%20Elements

> Safari is the only browser that doesn't support extending HTML element

That's a pretty big thing. I did not know.

I have custom elements on this web page, but I haven't had anyone complain that the image doesn't show (or shows up twice) under iOS: https://www.lelanthran.com/chap10/content.html

Are the features actually useful though? Surely there's a reason why only Safari has them. This textbox trim seems like a fix for badly made fonts

It depends on what one considers useful.

E.g. they were also first to support the `:has()` selector/pseudo-class, which I think can be useful for avoiding JS in some cases.

> This textbox trim seems like a fix for badly made fonts

That's not what it is. It's a typographic control that wasn't available in browsers before. It's got nothing to do with fonts being badly made. All textboxes (no matter which font) can be measured from many different places, and this lets you specify (via text-box-edge) which of those many different places you want to consider as the bounds of a specific textbox.

I don't see how hanging-punctuation and JPEG2000 support are worth bringing up when they were so infamous for breaking websites with their poor IndexedDB support (for frankly a stupid amount of time) that it spawned the phrase: "Safari is the new IE".

Not to mention Webms, PWAs, pointer support, etc...

I hope this will finally stop developers from setting line-height: 1; on text inputs which cuts off the top and bottom parts of some letters. Even Google developers make this mistake.

FINALLY!!

For 12 years visually vertically centreing text has required adding a padding or margin of a few pixels to the bottom or top, now (when adopted) it can be done properly.

Much needed feature for typography! The biggest pain is when I need to visually vertically center a text with an icon. If you have an [ICON] followed by upper case character (e.g. Hello), the (H) will always visually look too high to be vertically centered with the [ICON] because the actual height of the text that is calculated always account for hanging characters like "g, y", etc.

It's such a pain, there was a fantastic hn submission not long ago about the struggles with vertical centering.

https://news.ycombinator.com/item?id=40069599

How about a property for "largest font size that will make this text fit in the box without wrapping"?

In a similar vein but not changing text size is text-wrap: balance. https://developer.chrome.com/docs/css-ui/css-text-wrap-balan...

Now this is going in any place with long format texts in my web apps, thanks

Nice! Thanks for the tip on a thing I love I didn't know existed!

I had always wondered why Figma supports this when there doesn’t appear to be any support for it in the wild (web or native). Nice to see the W3C draft is looking fairly mature at this point.

The TFA is such a nice in-depth introduction to the properties. Respect to the authors for the work they put in explaining it.

Really cool. I'm currently building a text animation library and this should solve a lot of the margin issues that I've faced

How strange after seeing this after pulling my hair out the other day about this exact issue. If only it was implemented today!

I don't really understand what this is doing that margins aren't.

Better explanation here

https://css-tricks.com/leading-trim-the-future-of-digital-ty...

Note: this use to be called “leading-trim”

This depends on the font and give you options on how the bounding box works. Margins would be error prone, manual, and unreliable.

Was hard to understand until they got to the Use Cases section, should have led with that. TLDR: fonts are not vertically centered, but bottom aligned. This feature helps alleviate that by (typically) cutting off the top empty space.

Yes, you can sometimes add a little space around the text, but this is a proper solution.

Okay, but first let's wait for 10 years until it's going to be supported by every device out there.

Bookmarked, will get back to it in 10 years.

This is currently technically possible by customizing font face definition, right?

Yes. Please. I need this so much. This would solve so many of my issues with text alignment.

Reply on news.ycombinator.com