[HN Gopher] CSS Text Box Trim
___________________________________________________________________
CSS Text Box Trim
Author : bpierre
Score : 162 points
Date : 2024-05-03 14:11 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| murermader wrote:
| 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.
| achairapart wrote:
| This will be very useful, especially for vertical aligning, but
| as of today is essentially unsupported:
|
| https://caniuse.com/css-text-box-trim
| reaperducer wrote:
| _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.
| k4rli wrote:
| 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
| robinson7d wrote:
| 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.
| joemi wrote:
| > 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.
| wnevets wrote:
| > 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.
| robertoandred wrote:
| It's not recent. Safari has always been pushing and adding
| things, just not what Google wants.
| wnevets wrote:
| > 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.
| afavour wrote:
| 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.
| philistine wrote:
| 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)
| afavour wrote:
| "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.
| mholt wrote:
| 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.
| hbn wrote:
| 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.
| thekingshorses wrote:
| Safari is the only browser that doesn't support extending
| HTML element
|
| https://caniuse.com/?search=Custom%20Elements
| atonse wrote:
| 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 :-)
| agos wrote:
| I remember something in the whatwg ideals saying something
| along the lines of: users before developers before user
| agent developers
| philistine wrote:
| Apple prioritizes thus: Apple first, its users second,
| its devs third.
|
| They never stray from that.
| amlib wrote:
| 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.
| littlestymaar wrote:
| 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).
| alberth wrote:
| 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/
| tshaddox wrote:
| 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.
| MrJohz wrote:
| 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?
| tshaddox wrote:
| 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.
| MrJohz wrote:
| 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.
| baggy_trough wrote:
| How about a property for "largest font size that will make this
| text fit in the box without wrapping"?
| eclipticplane wrote:
| In a similar vein but not changing text size is text-wrap:
| balance. https://developer.chrome.com/docs/css-ui/css-text-
| wrap-balan...
| fooey wrote:
| Nice! Thanks for the tip on a thing I love I didn't know
| existed!
| thepra wrote:
| Now this is going in any place with long format texts in my
| web apps, thanks
| recursive wrote:
| I don't really understand what this is doing that margins aren't.
| pests wrote:
| This depends on the font and give you options on how the
| bounding box works. Margins would be error prone, manual, and
| unreliable.
| alberth wrote:
| Better explanation here
|
| https://css-tricks.com/leading-trim-the-future-of-digital-ty...
|
| Note: this use to be called "leading-trim"
| mixmastamyk wrote:
| 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.
| Ian_Macharia wrote:
| Really cool. I'm currently building a text animation library and
| this should solve a lot of the margin issues that I've faced
| tsujp wrote:
| 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.
| Inviz wrote:
| This is currently technically possible by customizing font face
| definition, right?
| lominming wrote:
| 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.
| dsego wrote:
| 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
| LoganDark wrote:
| Yes. Please. I need this so much. This would solve so many of my
| issues with text alignment.
| mortenjorck wrote:
| 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.
| kennydude wrote:
| How strange after seeing this after pulling my hair out the other
| day about this exact issue. If only it was implemented today!
___________________________________________________________________
(page generated 2024-05-03 23:00 UTC)