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.
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.
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
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.
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 :-)
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.
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.
> 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.
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.
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.
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.
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/