by mleonhard on 3/13/24, 3:31 AM
No! If you mess with the font size, you make your page hard to read for people who adjust their font size in their browser. They set their font size very carefully, to the smallest size they can comfortably read. Your site had better not change that.
Medium.com is the worst offender. Their font size is small and they disable zooming on mobile!
by stevetron on 3/14/24, 2:47 PM
I have found myself in my own private war against web sites over text viewability. Gievn that I am a longtime-coder, and longtime-electronics engineer, I had a life-altering experience a few years ago: as I was laying out a new circuit board design via CAD for a longtime client, a board which I would also have to write all the code for, my eyesight went all-goofy <technical term?>. I had to depend on family members to get me an emergency admission to an eye clinic, where I learned I had a detached-retina in one eye, was told it must hurt, and they didn't have anyone on-staff that could fix it. A few years later, and I have my vision blocked in that same eye due to a cataract, they won't do surgery becuase I'm 'allergic to lasers' and I need to shift to audio books. Huh. No, here's what I need from web pages and web browsers: an end to de-emphasised background comments that appear as light-gray on white background, and a quick button that let's me view everything in undecorated font Libre Sans (Libre mono for code), Boldface, and 14-pixel. The boldface is a huge sticking point, and I really need it. And nobody supports it :(
My eyesight is like viewing everything through a 'snowstorm whiteout'. The thin strokes of non-Boldface are nearly invisible, and size-alone doesn't quite fix it enough. Then there are the web site that insist on havign a hard-lock on low-contrasty themes......they seem to feel their precious theme to be more important than the word.
by mariocesar on 3/14/24, 11:29 AM
I like how it behaves on desktop, but I don't like making it "responsive" on mobile.
We can fix that :D
:root {
font-size: 1rem;
}
@media (pointer: fine) {
:root {
font-size: calc(1rem + 0.25vw);
}
}
@media (pointer: coarse) {
:root {
font-size: 1.25rem;
}
}
"pointer" refers to the way a user interacts with a device's screen, either using a precise pointing device like a mouse (fine pointer) or a less precise one like a finger on a touchscreen (coarse pointer).
by lifthrasiir on 3/14/24, 5:42 AM
Please, please please have reasonable bounds around that if you do want to use a responsive font-size. `clamp(10px, 1rem + 0.25vw, 60px)` (say) doesn't harm anyone else.
by youngtaff on 3/13/24, 8:05 AM
Really need to adjust more than just the font size, line height, grid spacing etc all need adjusting too
https://utopia.fyi/ is good for these calculations
by Ennea on 3/14/24, 7:59 AM
This is going to make text very large whenever somebody with an ultrawide monitor decides to maximize their browser window.
by xz18r on 3/14/24, 5:13 AM
Ironically, the font is too large for the table to fit on the screen, introducing horizontal scroll on this mobile page which I’m sure isn’t best practice. (I’m viewing this page on an iPhone 15)
by ceving on 3/13/24, 12:01 PM
Silly idea! A font size must depend on the vision of the reader.
by Cloudef on 3/14/24, 6:39 AM
Isn't the whole point of em that you don't have to do this?
by happytoexplain on 3/14/24, 12:53 PM
What is the motivation behind changing font size between mobile and desktop? My understanding is that browsers and apps already show the same font size at roughly the same perceptual physical size based on DPI and likely viewing distance, using relative units (em/rem on web, points on iOS, dp/sp on Android).
I'm guessing it's one of these two things?
1. Designers now disagree with the result of that preexisting calculation.
2. Designers are OK with making fonts on mobile smaller than the ideal reading size so that they can fit more content on screen (doesn't seem like a very designer-y thing to do).
Edit:
Or, #3, this is an alternative to the trick I assumed was ubiquitous:
<meta name="viewport" content="width=device-width, initial-scale=1" />
Which, I never understood why this is necessary in the first place (I'm not an experienced web dev). Based on the MDN docs (
https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_m...), we're setting the viewport's width to "100% of the viewport width", and initial-scale to "1", both of which sound obviously redundant, and yet if you omit this you get tiny fonts on mobile.
Edit 2:
Scratch theory #3. The author's site and all three of the sites he cites have that viewport line.
by juancroldan on 3/14/24, 8:23 AM
The point of having font size jumps is to only test screen dimensions right before and after the jump, to check for overflow or excessively large containers. But with a linear scaling this checking requires looking at all resolutions
by chrismorgan on 3/14/24, 10:10 AM
My strong recommendation is to stick to 1 browser em (~16px) on mobile-sized displays, and not to exceed 1.25 browser ems (~20px) on large displays. The formula provided in this article starts you at around ~17px, and exceeds ~20px on viewports wider than 1600px (quite common). That is: it’s too big.
I’d suggest instead something like ~16px at 360px viewport width, and ~20px at 1600px viewport width, and clamping at these values. Slightly different curve, and capped a little more sensibly, in my opinion. (Personally, I tend to stop shy of ~20px, going more for ~18px.)
With these specific values, a verbose expression of the font-size is:
/* 1rem @ 22.5rem, 1.25rem @ 100rem */
clamp(1rem, 1rem + ((1.25 - 1) / (100 - 22.5) * (100vw - 22.5rem)), 1.25rem)
I author fluid clamps in this form, and leave it to build tools like Lightning CSS to simplify the calc expression. For the specific values shown here: 22.5rem = ~360px, 100rem = ~1600px. You can definitely comfortably play fast and loose with the actual numbers.
by kingkool68 on 3/14/24, 4:30 PM
by ericselin on 3/14/24, 3:13 PM
While I agree with most of the comments that font-size for body text should ideally be 1rem (and certainly clamped), what about headings? When I think about different font sizes I think about headings, where it absolutely makes sense to have a much larger size on wide (/"desktop") screens.
by account42 on 3/14/24, 12:26 PM
This absolutely the wrong thing to do. Don't scale font size with viewport size. CSS "pixels" are already an abstract concept - if things are too small on your high-DPI screen adjust your pixel ratio accordingly instead of wasting everyone elses screenspace.
by ecaron on 3/14/24, 12:32 PM
My favorite solution in this space remains
https://www.modularscale.com/, because (like others mentioned) different device types warrant different scales, BUT ALSO changing line height and padding on a modular scale (also per device type) takes the math out of my responsibilities and puts it on the computer - where it belongs.
by chapterjason on 3/13/24, 6:37 AM
by irrational on 3/14/24, 12:57 PM
by uj8efdjkfdshf on 3/14/24, 8:54 AM
Huh, interesting. I've been using a clamped version of 1.5vw + 1vh for landscape and 1vw + 1vh for portrait, and then scaling everything else by rem for consistency. Might give this a try though.
by bromuro on 3/14/24, 3:06 PM
I don’t understand why font size on mobile should be smaller. Being he device smaller, font sizes should increase, if any.
Others commenters are right here - don’t mess up with the font size, please.
by bkyan on 3/14/24, 9:59 AM
Is there a way to do a curved function instead of a linear function?