Rethinking Text Resizing on Web
medium.com
medium.com
On web, use `overflow-wrap: break-word` and make sure your header can shrink.
Soon the time comes when old.reddit.com is no more and that is farewell.
Without users writing new content (because the site is crap) the Google stream will dry up too.
So, same as talkradio?
Their latest update on my iPhone 15 Pro (so the most vanilla configuration) has some kind of reverse padding on posts that will drag them under the previous one.
Sure they do. You're just not the target audience. You're stuck in the A/B testing phase where the A side gets Advertisements and the B side gets the B-rated website.
That's just bs. As a maker of UI, I want to get a rectangle, put my controls on it with the sizes in cm/in/° as I see fit and then to just slide right-bottom to see what happens on different screen sizes. One doesn't have to buy a foot-high stack of smartphones and tablets to test an effing label.
The whole issue stems from the fact we can't measure things correctly, cause the whole measurement system bases on ideas from winword era.
Maybe I'm not sure what you mean, but this is not correct. "The web" is definitely DPI-independent. Specifying a width of 16px will render 32 physical pixels on a @2x display.
Not gonna rewrite or patch a whole CSS framework to make a dashboard. One can avoid using it in the first place, but then has to cope with elusive y-scroll in line inputs, misalignments and so on. There's always something strange out of box even if you target a specific browser.
The two obvious examples which come to mind are mounted displays (from wall art and signage to billboards), and glasses-based displays.
A 1cm font size on a mobile device is ludicrously large. On outdoor signage it's invisible, and quite possibly below pixel size. It might be appropriate on a desktop display for some major title or site branding. It's going to fill the entire field of view on a face-mounted display.
The simple truth is that design has to respect not only device capabilities (your colour-palette likely works poorly on monochrome e-ink devices, ask me how I know), and reader capabilities (colourblind? glaucoma? cateracts? presbyopia?, macular degeneration?) but also the specific use case and environment, all in ways that the author of a site or design often has no possible insight on. Client specifies design is the only option which works in all of these instances, and yes, this means that the more complex your site / SPA (o hai ubrz) the more likely it will be to break irreparably in a large number of instances.
Nope!
A CSS pixel is 96 DPI at 28 inches from the viewer.
px is fundamentally angle-based. 1/47 of a degree. And sure it's a "scaled value of cm" at some point but this way the scaling is more obviously handled on a per-device basis.
Nobody who knows their salt has been using breakpoints (as a first resort for the past decade). There is no point arguing with a predictive text model about it.
Though, @container breakpoints are at least justifiable. Back when people keyed everything off viewport width (the approach that I'm sure the computer was regurgitating – and the approach used by every version of Bootstrap since 2), things were very fragile.
HN also does what's described at the end using media queries - if you make the page small your topbar fills the entire top and changes element layout while the post content area fills the entire rest of the screen.
The more subtle things you describe seem quite sensible. I'll probably steal those ideas, if it comes up.
I think about it as building different sites for different form factor. What you do on a phone is different from what you do on a desktop. Or a tablet. I don't like using the amazon website on mobile because it's so cluttered, when what I want is usually searching for a product, or checking my cart for a product. I'm not managing my account in there, nor do I want alternative recommendations.
I should subscribe to some "new web features you can actually use now" newsletter. Any ideas?
These re resolutions are usually significantly higher then the iPhone mini. usually The product owner or UX/design make that decision because you need to make a cut somewhere, and almost nobody uses small phones anymore. So they're making the judgement call that these people aren't worth the money creating the design, testing that every flow works correctly etc.
It's definitely annoying to be outside of the target demographic however, I know the feeling well.
- Their intent isn't small resolution, they're discussing increasing font size beyond the default on a standard premium smart phone[1]
- Retina displays came out when I was still in college...2010? At that point, resolution is meaningless, things like dp (Android parlance)/pts (iOS parlance)/points (Adobe or font parlance) rem are what you have to hang your hat on
- if you're making "someone else" (?) tell you what resolutions to support, are they technical enough to understand that?
- The invocation of "medium to big enterprise" is carrying a lot of weight, the big enterprises I've worked at certainly didn't do this, but it was Google
I think this is something more depressing that I saw constantly through the eyes of someone who started at SmallCo then went to Google: designers didn't know enough about view layout to explain this, engineers didn't care enough to explain because it was a "design thing", and if you were an engineer who cared enough, you were seen as troublesome / sticking your nose in the wrong place by your fellow engineers.
This isn't an idle observation: by sticking my nose in the wrong place continually, I learned enough about design to make a new dynamic design system that no one cared about until VPs needed one, and then it got in on the branding for Material You/Material 3.
[1] iPhone Mini is 5.4", the post you're replying to is recommending 5.8", that's a pretty de rigeur smart phone screen, even for premium smart phones in high income countries
Ofc the person isn't asked which pixel density, pixel ratio, resolution etc should be supported - they're asked what the smallest device is they should support. And this is usually the iPhone, and raising issues if a design doesn't work on a iPhone mini gets reprioritized into the backlog until someone closes it as won't fix.
And yes, I'd wager these multinational giga corporations like MAMA (Microsoft, Apple, Meta, Alphabet) are very different in culture, but I can't speak from experience, Ive never applied to work for any of them
I believe my nation classifies small enterprise to be <50 employees, with large starting at 250. That's a very different organisation structure then you get in a corporation with tens of thousands of employees, spanning multiple nations.
They also don't understand that people will visit your web site with their phone, even tho we have a native app.
I don't think I've ever seen a website respect my phone's text size, and frankly I didn't know it was posisble, this Airbnb blog post is cool and makes me want to update my own sites.
Desktop web versus phone/tablet/tocuhscreen? I’d take the innovations and how forward they’ve moved us and society over anything in the past… they’re not just about input but forced new solutions and took us to new places.
Can anything be implemented better? Of course, and I agree with you: the next disruption will be better.
BUT will also expose more challenges in how we deal with tech, each other, and the planet.
I think the format is perfect for consumption. That this became so separated from creation is another problem.
Touchscreens are not necessarily the best input device for any one task, but they are the second best input device for pretty much all tasks. They are very versatile - you don't need to define all your inputs up front, instead you can add new controls dynamically as needed (such as a keyboard that only shows up when you're inputting text, and even adapts to the type of text you're working with). When working with a desktop, you have a range of specialist input devices, from mice, keyboards (which themselves are a combination of different input devices for different tasks), drawing pads, trackballs, etc. A touchscreen will never be as good as any of these devices, but it can do the job of all of them, and switch between them as necessary.
Obviously there are limits to how useful this versatility is. A touchscreen in a car, for example, can control a lot of different aspects of that car from one place, but it makes finding those controls more complicated. So controls that need to be accessed regularly or quickly still need their own separate physical buttons. It's why volume buttons tend to still be physical on most phones. But you'd equally not want to control your car with a keyboard and a bunch of different shortcuts - understanding the tool that's best for the job is key.
And the point here is that the touchscreen is the best tool if you want something versatile.
I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material. Again, it has its disadvantages as well, but most phones can switch between vertical and horizontal modes as necessary. Vertical screens also tend to have the largest accessible space if used in one hand - look at how far your thumb can move side-to-side vs top-to-bottom when operating a phone in one hand.
Smartphones are the form and size that they are because it works well: it is largely accessible, it's convenient, and people find it convenient to use. And it's not like it's just the first thing that we tried that stuck - there are a myriad of failed smartphone concepts that have been tried out but just aren't as convenient.
That's not to say that you have to find the smartphone concept convenient yourself, but it's valuable understanding why they work so well for so many people.
Personally, while I am able to do most everything I do on my computer on my smartphone, I almost never enjoy doing so – one big exception being content consumption. And even then, not being able to quickly make a note or comment on what I'm reading feels constraining.
> I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material.
One seems to be strictly a consequence of the other.
> most phones can switch between vertical and horizontal modes as necessary.
Horizontal mode is usually horrible, both in terms of being able to hold the phone with one hand, and in terms of UI. On iOS for example, Safari's UI becomes extremely wasteful in horizontal mode.
> And it's not like it's just the first thing that we tried that stuck - there are a myriad of failed smartphone concepts that have been tried out but just aren't as convenient.
I think it has at least as much to do with industry momentum. Even if I'd personally prefer another form factor, I won't have many apps optimized for it if it's not in line with mainstream phone usage.
Touchscreen input could actually be quite precise if it was based on specialized gestures such as swiping and pie menus. Extensions of Fitt's law (that mouse-based interfaces are heavily based upon) have been developed that are applicable to swiping tasks, viz. https://en.wikipedia.org/wiki/Steering_law
I'd used it on an old Android 5 device where the pie menus were present for some functions. They don't appear on my e-ink Android 10 device. Not sure if that's the device / Android version or an app update.
<https://pocketbook.ch/en-ch/app>
<https://fbreader.org/android>
(Not positive which it was, though I think it was PocketBook. Device is not presently accessible.)
As for the pie menus: they were useful in some cases, but aren't a universal panacea for all touch UI problems.
That's pretty much the last thing I want. I really like the turn page buttons on my Kobo. My previous kindle did not have them and it was a pain. Somethings like iPod wheel can replace a lot of current touch screen interactions (it's technically touch, but could be a dial) in small screen.
> I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material
My non scientific answer is that it tiring to read a long line. A smaller width gave us more visual landmarks to rest our eyes on. And yes, a vertical form is easier to hold in one hand, but with how big phones are getting, most interactions is two handed.
> it is largely accessible, it's convenient, and people find it convenient to use.
And that's their only strong point: convenience. Ergonomics for a particular task does not translate well to others. If you only have to do one task, a smartphone is always the worst choice. A smartphone is more accidental usage than planned usage. If I know I'm going to take a lot of photos in an event, I want a camera, not a smartphone. If I'm going to write all day, I'm bringing a laptop, not a smartphone...
And regarding touch input: there's no physical feedback. Touchscreens are inferior to buttons you can feel the edges of, or keys you can push and hear as they click. Most of the older people in my life still struggle with touch inputs.
Smartphones are so convenient and versatile, though. I can't imagine any kind of device replacing them.
For Gmail, I use this small extension [1] that only resizes the message text and subject line, keeping other elements like the search bar, buttons, and labels unchanged. I wish every website does this way.
[1] https://chromewebstore.google.com/detail/email-zoom-text-rea...
Not quite the same, but works really well for not breaking any layouts because it just scales the entire display out of the viewable area.
(Something ... notably missing from Apple's desktop mice.)
OTOH Opera mobile supports text reflowing after zoom (to be enabled in settings). It's a compile time feature of Blink and I'm baffled why one else supports it. It eats a bit more battery to reflow on each zoom but come on.
I really really don't. I'm already much shorter of screen space than the designer planned for, and huge headings make that much worse.
Even if a company had in-house people for both branding/identity and interface design, which isn't common, they probably wouldn't even go to each others meetings, just like a database administrator wouldn't go to front-end dev meetings. My having professional experience in both is the exception, not the rule.
The overwhelming majority of the interface work I've done was for applications published by a nonprofit that didn't give a shit about branding or prettiness. They needed their interaction-heavy applications to be very visually parseable and have things like action status and next actions be clear and intuitive instantly. That doesn't happen by accident: you must delve deep into the minutiae of what you communicate with information hierarchy, implied relationships through gestalt or implied lines, and other visual cues that help people subconsciously understand what they're looking at. While these things are very important to everyone trying to use an interface, it's triply so for people that aren't used to staring at dense screens of text all day long, which is why other developers are the only ones that don't hate interfaces made by developers. Branding people care about very general look and feel and are usually satisfied if you use the appropriate colors and typefaces. Interface design is the hard part with layout, has little to do with aesthetics, and is 100% about the use case.
Nothing about this is specific to commercial software. I've got 5 digits of hours in FOSS contributions.
> It was once expected to get training for a tool. But now the trend is for the tool to become a toy. Just play with it until you get light and sounds.
Your stance is pretty common among developers. The fact is that we use so much end-user-facing software for which we don't even think about the interfaces... we just accomplish whatever task you need the tool to accomplish and move on. Think about every phone app, screen, website, ordering system, electronic appliance-- all of those things have designed interfaces. Do you think it's reasonable to require customers to read instructions on using an ordering terminal at a quick serve restaurant? Their phone email app? Web browser? Messaging clients? If every one of those interfaces was assembled according to the developer's fancy rather than someone who knows how to utilize people's existing mental models and cultural understanding, well, that's a whole lot of "RTFM" time that would be better spent on actually getting something done. Most people will never read a single line of software documentation in their entire lives for the same reason they'll never need to learn how to use a Bobcat for yard work-- it's just not necessary for non-professional work. Developers have a fundamentally different perspective on software and it's not 'better.' Needing docs for basic application functionality is the right tool for some jobs, but not for most jobs.
> And for safety, we will reduce the set of actions you can take. Fine for a single purpose application, but not great when you want versatility.
You're conflating bad with intuitive with well-designed. An interface that doesn't let expert users work efficiently is a bad interface. Almost invariably when you see an interface that looks 'designed' but it's not functional, it's because a developer went looking for nifty UI mockups on Dribbbbbble and copied it so they could tell people about the beautiful interface they designed. They think that works because they think UI design is about aesthetics rather that making your interface as useful as possible. Great designs aren't even always intuitive to non-experts. Lots of times it has to be fast and efficient for people who know exactly what they're doing, and training might be appropriate for important, complex interfaces... but complex expert-targeted interfaces are not the same things as interfaces that are confusing because they were assembled rather than designed by someone who knows what they're doing. One of those things looks like the console for a modern X-Ray machine. The other looks like the interface for the Therac-25. I use vim (or, vim keybindings in other editors) these days because it's a great expert tool, and it's about as far from intuitive as you can get. If someone said "make an efficient text editor for people who will spend many thousands of hours at keyboards, there's a good chance interface designers would come up with something just like that, though probably with better visual cues.
As you say, people in different roles don't even have the same meetings
She couldn't add her phone number to her account, because her phone number was already registered in an old (2013) account of hers that she didn't remember existed, and she didn't remember the credentials.
Once she found a way to log into the old account, she was unable to remove her phone number from it without adding in a new number. We had to add my phone number to her old account so that we could use her number in her current account. We couldn't add a 'fake' number because it requires SMS verification.
So, I guess I will not be able to add my phone number to Airbnb if I ever want to use it.
I suppose they do it like this so that phone numbers can be used as username, but they end up pushing this kind of problem onto their users. We were in a hurry and it really was not the appropiate moment for Airbnb to act stupid.
I can somewhat comfortably read HN (though it is a touch small); it's 12px/9pt. I wouldn't recommend anything less than 10pt myself for normal text.
I did hit a site recently whose main copy was 9px, and that was quite annoying, I agree there.
https://nicolas-hoizey.com/articles/2016/03/02/people-don-t-...
Also there are different levels of default. The user can customize the default size of the document element, but this can then be overridden by the web developer.
https://www.smashingmagazine.com/
The headlines are so large that I have to move my head to read them.
And zooming out doesn't reduce the font-size, it just makes headlines narrower to the point where they're one word under another while I still need to move my head around to read them. Except when zoomed out, I still need to move my head horizontally, but now vertically too.
If I’m understanding them correctly isn’t it worse than that? 200% Zoom leaves you with 1/4 of the space you had at 100% I think.
Does it not behave like this for you? I think Chrome handles it better. What browser do you use?
While it doesn’t blow things up by 200% like what AirBnb’s approach supports, it’s a quick way to make a big difference for people.
[0]: https://developer.apple.com/documentation/uikit/uifont/scali...
Display & Brightness -> Display Zoom
Well, duh, that's because you retain so much useless whitespace where you can only fit a single short word "Display" (~30% width vs 70% whitespace) in a line
And the example in the video isn't much rethinking - instead of hiding crucial info with "California" becoming "Ca..." not only can you fit more info if you squeeze the overly wide ... (so readable Cali would fit), but also you could expand into the half-empty 3/4 lines, where a price unit could also be moved to a separate column instead off "night" being repeated, that would fit the whole California right there at high text size (and again you could fit more relatively valuable text if you remove some of the relatively less valuable spacing)
If you size _everything_ in rem, then user-agent font scaling ends up doing pretty much exactly the same thing as user-agent zooming, which is less useful than allowing user-agent font-scaling and zooming to do _different_ things, each of which may have a different context of use.
This seems obvious once said -- but is there an argument against it? I don't think it is the common advice -- I feel like there was a _lot_ of talk about sizing _everything_ using `rem` for accessiblity (that began back before most people knew about sizing anything with rem). And that this is what most people (including me) are doing -- using rem for all sizing. And what many design frameworks (bootstrap?) have and are doing.
It's making me think the standard advice should be as in OP instead, rem for text, px for everything else. And of course to maximize accessibility benfits you then need to actually test under text-scaling (on small screens), but to begin with (and avoid the need for a huge refactor later), it seems like you should start with `px` for grid spacing etc, contrary to much current common conventional wisdom?
Readers who are aware of the ability to set a browser-level font default will be annoyed at any other behaviour or choices. Readers who are unaware of that capacity, the overwhelming majority, are a lost cause regardless, but will likely use other mechanisms to zoom pages to a comfortable reading level.
Otherwise, Air UI/UX are Beyond the Bend.
What bothers me is why does a company find itself in this situation. Why does it not include web accessibility in the building of its product from the start? Why do designers talk to developers in pixels instead of checking how their design decisions on different screens, in different browsers, and with different accessibility settiongs?
> The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.
A lot of things in UI are like this, but given the way the web has developed, it's particularly true. The article goes over some of this, although I think it kind of assumes the reader is more or less familiar with some of the issues that come up, but it could probably still give a naive reader some idea.
- Scaling / reshaping a UI is a fundamentally hard problem that people love to pretend is easy. There are all kinds of tradeoffs that need to be made based on the layout. Which text needs to be preserved? When is it appropriate to show ellipsis? Should padding be dynamic? Apart from CSS another major attempt was GridBagLayout in early Java, which was also a mess.
- Designers tend to be visual arts people who aren't of the correct personality type to dive in and solve all of the nitty gritty issues when making their design. They also like to make complex designs to show how creative they are. They also use their superior social skills to rope high level people to develop and approve the designs with them so that things are final before a dev gets to have a look. Once that happens ego comes into play and they can't be simplified.
- CSS fundamentally doesn't have the correct tools to solve a lot of the issues. CSS first came out in 1996. Line clamping seems like an obvious problem to solve. Yet 28 years later we're still stuck with a prefixed -webkit-line-clamp. In general CSS sees overflowing text as a problem it doesn't want to deal with.
Now you get phones where the zoom in does something utterly useless and people still can't reliably set their own font size.
<meta name="viewport" content="width=device-width, initial-scale=1" />
I find it makes sites much more pleasant to browse.
Without requiring horizontal scrolling?
Still, I find it preferable to messing with font sizes as I hate reading on the phone and want to spend as little time as possible looking at the small screen, so I usually zoom in to what I want to see/read/click on, switching phone orientation if necessary for a 2nd option for the text size.
I could be wrong, or in a minority opinion group.
I thought it just set the initial zoom with initial scale, but didn't prevent zooming in further? But I don't pinch zoom websites much, and maybe I haven't tested my own in a while... googling the usual sources are not clarifying to me the interaction of all these things according to standard.
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=5.0">
Found this info here, and will try it out: https://stackoverflow.com/a/17891937Accessibility aside, their website is an unusable, resource-hogging mess which doesn't even use proper cursor pointers for <a> tags and tries to mess with my scroll.
I don't think I prefer it most of the time, as scrolling is annoying. But it is super useful for sites that break the browser-default scrolling.
Credit: https://superuser.com/questions/1659519/firefox-pinch-zoom-w...
This is the problem though, unfortunately. People aren't even talking about the same thing. Users need to increase their font size so they can read comfortably. But so many people seem to think "zoom" should do what you describe (like zooming in to see small details?). I suppose the best is that web browsers offer both modes. But unfortunately text zoom requires some understanding from the web developer to work (or just a simple web site; a little knowledge is a dangerous thing). So we get stuck with stupid zoom because half the web breaks if you dare to change front size.
Front-end developers: test your layouts in Firefox with "Zoom text only" set. It should work for all settings from 50% to 200%.
These frontend web dev tendencies are devastating to me. I feel like these people haven't lived through the CSS Zen Garden days or the fight for semantic HTML.
I still love the web, but the current frontend culture is batshit.
:root {
--gr: 1.618;
--font-baseline: clamp(16px, calc(5.725vh + 5.725vw), 72px) !important;
--font-baseline: clamp(16px, calc(5.725svh + 5.725svw), 72px) !important;
--baseline-unit-1: var(--font-baseline);
--baseline-unit-2: calc(var(--font-baseline) / var(--gr));
--baseline-unit-3: calc(var(--font-baseline) / pow(var(--gr), 1));
--baseline-unit-4: calc(var(--font-baseline) / pow(var(--gr), 2));
--baseline-unit-5: calc(var(--font-baseline) / pow(var(--gr), 3));
--baseline-unit-6: calc(var(--font-baseline) / pow(var(--gr), 4));
--baseline-unit-7: calc(var(--font-baseline) / pow(var(--gr), 5));
--baseline-unit-8: calc(var(--font-baseline) / pow(var(--gr), 6));
}
(Initially there was no `clamp()`, but I had to concede that point for a better UX on really large and really small screens.)A "motherfucking website" without any css nor js is perfectly readable and usable on all devices and browsers. Users can select their preferred font sizes, and even colors. It is just like an ebook, that is readable everywhere, and responsive with user-chosen display setups and settings. What is the problem, then? Some websites want to look "fancier", and then they specify styles in manner that is incompatible with some usage patterns? This is an entirely self-inflicted problem. The problem did not exist in the first place, they created it.
I have real trouble accepting that "web design" is not a bogus and fully useless human endeavour. I hope someone around here enlightens me to the contrary.
No, I don't. It has scrollable maps, for example. Those require a Javascript-operated canvas.
What I don't understand is why it needs CSS or Javascript for the rest of the interface. It's just text and photos. An empty css with static html would be enough for that, and convey exactly the same information.
I’m also a proponent of simple pages wherever they can be made but we’re not the only audience on the internet. Different people find different UIs effective.
For example: Airbnb (last I looked, anyway) has a little mini carousel in the thumbnail of a listing. I found it mildly useful. I imagine a company the size of Airbnb are tracking if people use that widget so it’s probably earned its place in the interface.
Standing outside the whole thing with no data and saying “none of this is necessary” strikes me as an unhelpful perspective. Neither you nor I actually know.
Users can select their preferred font sizes
Browser vendors actively disrupted these features for decades, cause most of them became biggest sales/tracking platforms.
Most web design today is driven by branding. Everyone seems to feel like they have to be express their uniqueness. This is awful and can widely be regarded as a bad move. I fully agree with you on that front.
On the other hand, the default browser styles are bad in their own way. Look at http://bettermotherfuckingwebsite.com/ for details. In practice, some degree of web design is necessary.
Also, you can create art and beauty on a computer. A well designed website can elevate the experience, just like a well designed book or chair.
Finally, HTML is limited in what it can do. JavaScript, CSS, and WAI-ARIA together form the low-level technologies to extend the web with new functionality. See https://extensiblewebmanifesto.org/ for details.
In summary, I would say that most web design is useless, but not all of it.
seriously?
For example, from this Airbnb article:
> In the case of Airbnb, the team decided to prioritize the use of rem units specifically for font scaling, rather than scaling all elements proportionally.
This can lead to undesirable outcomes as sometimes spacing between elements can have a functional purpose, e.g. making it easier to vertically separate one paragraph from another. If you use `rem` solely for font-size and nothing else users with `32px` as their default font-size would not have the necessary amount of space to help discern one paragraph from another in this case.
PS It looks like they use Linaria, one can simplify the transition from `px` to `rem` by declaring this helper function and using inside their `css` rules:
```ts
export const px = (...spacing: number[]) => spacing.map(s => `${s * (1 / 16)}rem`).join(" ")
// Example usage
const styles = css`
p { // This inline padding is for aesthetic reasons, we don't want this to scale
// with users preferred font-size
padding-inline: 16px;
// This serves a functional purpose, it will become `0.5rem 1rem`
// which should match `8px 16px` if users are using the default 16px font-size
margin-block: ${px(8, 16)};
}````
[0] https://www.joshwcomeau.com/css/surprising-truth-about-pixel...