If you want to maintain a constant relationship between text elements and still have it responsive use pow(). font-size: calc(---size * pow(1.5, 4)); then put the clamp on --size
@@NotKyleChicago In the CSS code snippet you provided, pow is used as a function within the calc() expression to calculate the font size. Here's a breakdown of how it works: * calc() function: This function allows you to perform mathematical calculations directly within CSS values. * pow(1.5, 4): This expression represents the pow function being used with two arguments: * 1.5: The base number. * 4: The exponent. * pow() function: This function calculates the power of the base number raised to the exponent. In this case, it calculates 1.5 raised to the power of 4, which equals 5.0625. * Final calculation: The calc() function then substitutes the result of the pow() function into the expression, resulting in: font-size: calc(--size * 5.0625); This means the font size will be calculated by multiplying the value of the custom property --size by 5.0625. Therefore, pow in this context is used to calculate the exponent of a number within the calc() function, allowing for more dynamic and flexible font size calculations based on other CSS values.
Thank you, nice touch with using vw + rem. Tough sometimes (rarely, but still) vw is exactly what is needed, cqw in my case, without clamp - to match size of message over element, proportionally to element's size.
My goto is just doing a clamp with a calc on :root, then you can just use rems everywhere else like normal. You can fine tune how it scales responsively, and you still get native zoom controls.
Thank you for walking through clamp() like you did here. It never truly made sense to me before but this example and your explanation REALLY helped!!!!
i'm not generally sure about this one.. that's directly too much of definitions, 1 fluid type annotation on root set as a font-size, then rem-ing everywhere else is probably my decision.. maybe id create a utility for myself that will generate these "steps" for me, but i feel like this is way too boilerplaty and in so many cases is an absolute overkill.. thanks for the interesting tip anyways!
In my opinion the issue of mid-range scaling not being proportional to zoom/browser font size settings is more about typography and design than accessibility. The point of accessibility is to make your text readable especially the body copy (this will always be handled by the minimum rem value). What is more problematic is actually the maximum value that tends to reduce readability when zoomed. Example: 4rem will look like 8rem at 200% zoom - causing line breaks too often or in some cases overflowing the page on smaller devices. Keeping the size at 4rem is in most cases what you want - it is readable and does provide some hierarchy compared to the body copy that would be displayed as ~ 2 rem
Nice! I think I will have to revisit a website I did and adjust using the clamp property! With I had known, thank you for this tip!! Using view-port width was my go to for awhile and not I have a better understanding.
Please remember that there are many different use cases for browser based applications. For example, my company provides browser based live scoreboards for sport stadiums. We use these units so that the content remains identical independently from the platform, TV, projector, giant LED screens, etc. Use what is appropriate for your job.
From the implementation perspective, I get the idea of dynamic size is for accessibility and simplicity. From a user perspective, I hate dynamic size a lot due to the overall layout shift and the constant text/image changing is annoying to my eyes. I personally prefer hardcode size based on breakpoint.
The best solution written in article by *Adrian Roselli:* The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet. No need to use viewport values to set up font.
Don’t make text size responsive at all. The layouts / containers can (and should) be flexible so the text will fill the available space on each resolution. Just go with fixed font sizes and adjust at certain breakpoints with media queries
For headings, I’ve often written this for the font-size: min(1rem + 40px, 12vw) which causes it to shrink on smaller screens to avoid overflow. Is using the min() inadequate then for headings, especially when trying to prevent the text from overflowing off the right side of the screen on mobile devices? Clamp() is good, I just worry about the overflow issue with setting a minimum font-size on it. I use pixel units with rems so that the heading doesn’t grow or shrink quite as much as the body text when the user changes the browsers default font size since the heading text starts off being bigger and easier to read.
If it's very large text, you can get away with it, which I'm going to hope is the case if they're being particular with line breaks... I'd probably try pretty hard to educate them on how the web works though, in a very polite way with examples of why not being anal with line-breaks is important.
Im confused. If the point of clamp was to get away from breakpoints, why would you use a scale step? isn't that basically a different flavor of beakpoints, but just for that text? For my header I just have the H1 set globally for clamp(2.5rem, 2rem + 2.5vw, 5rem) with the viewport at 320min 1920max
Nice but Utopia tools is not very fast and easy if you work from a Figma design, let's say a classic 1440px design :). Your UI designer need a H1 with 58px; --fs-6__: clamp(1.86rem, 3.03vw + 0.91rem, 4.03rem); --> hard resize --fs-6_: clamp(2.42rem, 2.02vw + 1.81rem, 4.03rem); --> medium resize --fs-6: clamp(3.15rem, 1.01vw + 2.73rem, 4.03rem); -> soft resize --fs-6-px: 58px; This 3 var will be a exacte 65px render in 1440 screen, but with a diffèrent type of scaling :) .
Of course different places have different rules and ways of working, but most designers care more about the ratios and visual weight of everything rather than exact px values, which tend to fall apart at various screen sizes anyways. If you get a good eye for that, and get a good understanding of what your designer is trying to achieve, it can make things like this much, much easier.
I'm wondering is anyone can help me. I'm working on a website and I have an issue with the font that I am required to use. In in an input field with the same top and bottom padding on a desktop browser uppercase letters are vertically centred. So there is an equal amount of space above the top of an uppercase letter and below the bottom of an uppercase letter. In the same input field on a mobile device the text is aligned differently. There is an equal amount of space above the top of an uppercase letter and below the bottom of a low hanging lowercase letter (e.g. a "g" or a "y"). This leads the text to look misaligned on mobile devices. There's no CSS causing it. If I look at the website in developer tools on desktop at a mobile device size it is aligned the same as in a regular desktop browser window. It's just aligned differently on actual mobile devices. And it's the same in all the mobile browsers I've tested it in (Chrome, Edge, Firefox, and Opera). I wondered if it was the font itself causing it so I switched to a different font (Roboto) and while it's very marginally better it's still clearly misaligned. So while the font I have to use might sit a little high, it's not really the font doing it. Does anyone know if this is just how mobile browsers align text or is there something I can do about it that doesn't involve adjusting padding on every single text element? I tried playing with line-height and that didn't achieve anything, I think because it's just adding or subtracting the same amount of space above and below the font. It's not shifting the baseline that the text sits on.
How much did I do font: #vw back before clamp? all the time on some major sites and still see it when I go to them. Should I have, nope but what could we do instead. @media 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 and that was a pain.
Seems like they've addressed the main points I made about issues with viewport units. I've never used it myself, and generally I'm not a fan of overly-fluid designs, but without having used it, I can't say for sure... but they seem to have taken accessibility in mind 👍
When i start to build my first web page during my college days. I often use vmin & vmax for font size. After sometimes only i came to know that these font units won't bring responsiveness 😅
These days there is no benefits in IT jobs where you can survive with rhe core quality expertise of HTML, CSS, Responsive Design Skills, Hadling Cross Browser Compatibility issues etc. IT companie are focusing only Angular and React skills and once they hired Angular/React guys, therefter they expect 100% expertise in CSS ad HTML from them and the result comes they have to hire an UI/UX designer separately, but in my 16 years of experience working as an UI/UX designer in multiple MNCs I never met single guy who is expert in both - core UI skills like HTML, CSS and React/Angular. IT industries are doing injustice with core UI designers these days bcoz of React and Angular.
In my opinion, we should never even change the font size at all. Smaller screens are held closer, and larger screens are held farther. And high res screens of the same size are scaled to make the font size bigger anyway.
@@n_mckeanEasy to tut, but in reality users are much more likely to change the browser size via the zoom functionality rather than the more obscure way of changing the default rem though. Yes, ideally both ways should be supported but px are still accessible despite common belief thanks to browser zoom.
@@BigBlueRabbit Find an old person, get their phone and look at the size of their menu items and text messages, they'll have scaled their default font size. This function in OS and browsers was created for a reason. Zoom is site-scoped. A user shouldn't have to zoom every site they visit when there is a function to scale everything without intervention. God forbid also the person has poor sight AND mobility issues as you are making them work even harder. It is easy to tut. It is equally easy to apply the basic CSS tools (rem, no max height, word wrapping) etc to your text that have existed for 15 years. Anyone coding like it is 2010 needs to rethink their career or read up.
I immediately got triggered when I saw the thumbnail "font-size: 5vw", thinking "who on earth does this way?!" LOL. Font clamping with a scaling factor generator is what I usually use all the time and I've been trying to get my designers to do the same because, not only it is so much more easier to implement and it's not based on some arbitrary sizing, it is consistent and it's visually pleasing to look at.
Jesus wept, are people just overcomplicating things for no reason? The entire point of REM is that it's relative to the root of the document, not its ancestors. Put the clamp() font-size stuff in the html element and then specify multiples of REM however you see fit for your actual text content. No need to magic number things or use an insane number of arbitrary custom properties, just 1 item that does the fluidity and every size thereafter derived from it. Fudging the vw unit in the clamp is still horrible though, but done once could be an acceptable trade-off. Or, and here's a WILD idea, don't have completely responsive text. Even with different pixel densities, all device categories are generally in the same ballpark as each other, so just set up a few media queries with common width ranges and set a fixed unit size for font-size. Hell, put these fixed sizes on the html element and stick with rems for actual text and not only do you preserve the proportionality of size across your different text elements, but you automatically adjust everything based on your device. And browser zooming works are expected as well. However, the difference between zooming the browser and a user's font size preference for the browser are two different things, and px for font sizes regardless of where you use them is going to break the latter.
Scaling font sizes for me only make sense when you have design elements with a fixed width and height. 1rem (usually 16px by default) looks perfectly fine on ANY device. Increase regular text a little but on mobile if necessary, but that's it. I actually worked at a company where they scaled everything by setting a calculated font-size via javascript on the html element and scaled EVERYTHING with rem. They considered it perfectly fine, even though everything would jump until all scripts were loaded, everything was too large on phones and tablets in landscape and font sizes were down below 10px on mobile, basically treating the entire page as if it was an image with a width of 100% and height of auto.
@@Azurryu well, that sounds...competent. Honestly I'll never understand how supposedly professional developers can think insane shit like you describe, or what I see in my own place of work, is a good idea. Hell, how the idea even formed in the first place.
This is making things more SIMPLE in my opinion. For example, you probably want to have bigger difference between "h1" and "p" on a big screen than on a phone. And then you have to use media queries. This just eliminates that part.
There’s just one issue: zooming. In most browsers, zooming doesn’t change the font size or affect REM units. Even with a 200% zoom, 1rem will still render as 16px instead of 32px. REM only adjusts if someone manually increases the font size in their browser settings to 200%. The regular zoom is in most browser the default zoom. Text zoom is mostly hidden in settings, because it also is effected by OS settings.
You're current that it doesn't change the font-size or `rem` in the strictess of definitions, but it does zoom in/out because it's changing the size of the pixel unit. Even if you set your font sizes in pixels, it will increase decrease the font size. If you zoom to 200%, you've effectively made your CSS pixels 2x bigger than they used to be (because a CSS pixel is not a screen pixel). You can see it in my demo, and you can try it right now on RUclips, or any other site. You can also see in the video when I have the font-size in viewport units and zoom in and out, the margin on the sides of the pages is increasing/decreasing because of it (because the pixels are getting bigger/smaller), but the font-size isn't changing. As long as you use em, rem, pixels, or whatever else, you can allow the site to zoom in and out. There are ways to allow for font scaling without zooming. Wikipedia has a control for this right now, and I think offering that is awesome, but as long as you can zoom in/out and have larger/smaller text without any issues, it's perfectly fine.
@@KevinPowell Hey, I really enjoyed your video, but just wanted to clarify a small point! Zooming (graphical zoom) is more of a fallback mechanism and doesn’t fully comply with WCAG 1.4.4, which focuses on scaling text across all websites using relative units like rem or em. When you adjust the font size in the browser, it applies globally, and that’s the ideal way to ensure accessibility for users who need larger text. You made a great point about the Wikipedia feature-it’s awesome! But for users who rely on larger text, they’ve probably already set a default font size in their browser, making that control less useful for them. Also, about your vw*rem solution, if you’re already using relative units for both the min and max font sizes, that should be enough to ensure a good balance without complicating things further. Thanks again for the great video-it was mostly spot on, just thought this might help clear things up a bit! :)
"Please, don’t use viewport units for font sizes". Sad about this catchy title, since at the end the conclusion is that it's a good idea to use viewport units when done correctly.
coder coder created video "Please stop using px for font-size." now you "Please, don’t use viewport units for font sizes" waiting someone create video on "Please, don’t use rem units for font sizes" 😂😂
If you're working on government websites, certain private business sites, healthcare or education websites, you HAVE to follow accessibility guidelines by law.
As ZeeZeeGaming said, accessibility rules are generally written in stone. A lot of companies have already faced lawsuits around inaccessible websites, in the US and EU, and the EU is making their accessibility rules even stricter very soon... That said, there are times when it's less likely to be an issue, like a very large font-size where it probably doesn't matter if it can't be zoomed in on. But as I showed in the video, most of the time if you only use viewport units for font-sizes without a clamp, you're going to get either too big at one point, or too small. Someone out there on their 54" widescreen display is going to full-screen your site and end up with some *very* big type 😆 I'd also say I'm giving some recommendations and best practices here, and in knowing those, it means that you can usually find the times when it's okay to break the rules as well :)
Just because 99.99% of cases should not use vp units for fs, there are legit reasons to do so. Saying don't use them is disingenuous. Always use the right tool for the job.
@@Mecabricks Aha, interesting use case and I see your point now. Definitely the 00.01% of uses though and whilst you're right that accessibility isn't harmed in that case and nor is the design very fluid, sometimes people just need simple rules to follow and saying "never" is probably more helpful than harmful even if not quite correct. You can still deliver on a scoreboard use case without straight viewport units.
There are many cases where you would want paragraphs at different font sizes. Different sections on your site may have different visual weight because it is primary vs tertiary content, some sort of callout, etc.
yes, because "cutting edge" CSS techniques are pushed by grifters and elitists trying to make CSS - and web development as a whole - significantly more complex than it needs to be in order to shill their unnecessary tools and products, and lock out the self-taught from emerging markets. If somebody with "industry experience" says X is a good approach, it'll instantly be copied by everybody who doesn't know better.
I’m experimenting using clamp in combination with container query units like font-size: clamp(1.125em, .625em + 7.25qci, 2.25em) And I can say, it‘s kind of neat, but also buggy. As long as I don’t resize the Chrome window, everything is fine. But the Chrome tab dies so often if I do. Don‘t have a clue why. 🥲
Utopia keeps being awesome! Good on them for calling out WCAG failures.
If you want to maintain a constant relationship between text elements and still have it responsive use pow(). font-size: calc(---size * pow(1.5, 4)); then put the clamp on --size
What is pow()? I'm thinking power, as in "2 to the power of 3 equals 8".
@@NotKyleChicago
In the CSS code snippet you provided, pow is used as a function within the calc() expression to calculate the font size.
Here's a breakdown of how it works:
* calc() function: This function allows you to perform mathematical calculations directly within CSS values.
* pow(1.5, 4): This expression represents the pow function being used with two arguments:
* 1.5: The base number.
* 4: The exponent.
* pow() function: This function calculates the power of the base number raised to the exponent. In this case, it calculates 1.5 raised to the power of 4, which equals 5.0625.
* Final calculation: The calc() function then substitutes the result of the pow() function into the expression, resulting in:
font-size: calc(--size * 5.0625);
This means the font size will be calculated by multiplying the value of the custom property --size by 5.0625.
Therefore, pow in this context is used to calculate the exponent of a number within the calc() function, allowing for more dynamic and flexible font size calculations based on other CSS values.
basically as @DeepTitanic said but without the --size var, they just use 1rem 😎
Thank you, nice touch with using vw + rem. Tough sometimes (rarely, but still) vw is exactly what is needed, cqw in my case, without clamp - to match size of message over element, proportionally to element's size.
My goto is just doing a clamp with a calc on :root, then you can just use rems everywhere else like normal. You can fine tune how it scales responsively, and you still get native zoom controls.
Same!
Thank you for walking through clamp() like you did here. It never truly made sense to me before but this example and your explanation REALLY helped!!!!
i'm not generally sure about this one.. that's directly too much of definitions, 1 fluid type annotation on root set as a font-size, then rem-ing everywhere else is probably my decision.. maybe id create a utility for myself that will generate these "steps" for me, but i feel like this is way too boilerplaty and in so many cases is an absolute overkill.. thanks for the interesting tip anyways!
In my opinion the issue of mid-range scaling not being proportional
to zoom/browser font size settings is more about typography and
design than accessibility.
The point of accessibility is to make your text readable especially the
body copy (this will always be handled by the minimum rem value).
What is more problematic is actually the maximum value that tends
to reduce readability when zoomed.
Example: 4rem will look like 8rem at 200% zoom - causing line breaks
too often or in some cases overflowing the page on smaller devices.
Keeping the size at 4rem is in most cases what you want - it is
readable and does provide some hierarchy compared to the body
copy that would be displayed as ~ 2 rem
Nice! I think I will have to revisit a website I did and adjust using the clamp property! With I had known, thank you for this tip!! Using view-port width was my go to for awhile and not I have a better understanding.
well shit... (although I use clamp with it)
same !
I use Calc and clamp
Same, lots of designs I do can't be done otherwise
Same, never had any issues with the min and max of clamp.
Yupp
Great tip! Utopia's accessibility check is a huge deal.
Thanks for the video. I haven't used it in production yet, but I've been liking some prototyping I've done with container-query-units and clamp.
this vw trick is actually really cool for game UI's where everything must scale uniformly
Yeah it can definitely be useful for things like that :)
Oh man... I just got done making a thing with 'vw' units. Now I gotta go back and change stuff. Grumpy hand clap in your general direction 😏
the way this video came out IMMEDIATELY after id JUST done precisely this (with clamp) on a frontend mentor challenge dhdhdh
Please remember that there are many different use cases for browser based applications. For example, my company provides browser based live scoreboards for sport stadiums. We use these units so that the content remains identical independently from the platform, TV, projector, giant LED screens, etc. Use what is appropriate for your job.
From the implementation perspective, I get the idea of dynamic size is for accessibility and simplicity.
From a user perspective, I hate dynamic size a lot due to the overall layout shift and the constant text/image changing is annoying to my eyes. I personally prefer hardcode size based on breakpoint.
The best solution written in article by *Adrian Roselli:* The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet.
No need to use viewport values to set up font.
Thank you for highlighting accessibility as a measure of successful web design.
Don’t make text size responsive at all. The layouts / containers can (and should) be flexible so the text will fill the available space on each resolution. Just go with fixed font sizes and adjust at certain breakpoints with media queries
For headings, I’ve often written this for the font-size: min(1rem + 40px, 12vw) which causes it to shrink on smaller screens to avoid overflow. Is using the min() inadequate then for headings, especially when trying to prevent the text from overflowing off the right side of the screen on mobile devices? Clamp() is good, I just worry about the overflow issue with setting a minimum font-size on it.
I use pixel units with rems so that the heading doesn’t grow or shrink quite as much as the body text when the user changes the browsers default font size since the heading text starts off being bigger and easier to read.
What if the client is reallllly uptight of about never ever having text that line breaks how they don't want it to line break, on any screensize?
Not sure that's even possible with responsive design! You would potentially fall down the hole of overflow 😮
I mean use Clamp and text-wrap:nowrap;
Then test it on the 5 common breakpoints and you should be fine.
Mostly for company names and or slogans.
If it's very large text, you can get away with it, which I'm going to hope is the case if they're being particular with line breaks... I'd probably try pretty hard to educate them on how the web works though, in a very polite way with examples of why not being anal with line-breaks is important.
Im confused. If the point of clamp was to get away from breakpoints, why would you use a scale step? isn't that basically a different flavor of beakpoints, but just for that text? For my header I just have the H1 set globally for clamp(2.5rem, 2rem + 2.5vw, 5rem) with the viewport at 320min 1920max
Nice but Utopia tools is not very fast and easy if you work from a Figma design, let's say a classic 1440px design :).
Your UI designer need a H1 with 58px;
--fs-6__: clamp(1.86rem, 3.03vw + 0.91rem, 4.03rem); --> hard resize
--fs-6_: clamp(2.42rem, 2.02vw + 1.81rem, 4.03rem); --> medium resize
--fs-6: clamp(3.15rem, 1.01vw + 2.73rem, 4.03rem); -> soft resize
--fs-6-px: 58px;
This 3 var will be a exacte 65px render in 1440 screen, but with a diffèrent type of scaling :) .
Of course different places have different rules and ways of working, but most designers care more about the ratios and visual weight of everything rather than exact px values, which tend to fall apart at various screen sizes anyways. If you get a good eye for that, and get a good understanding of what your designer is trying to achieve, it can make things like this much, much easier.
I'm wondering is anyone can help me. I'm working on a website and I have an issue with the font that I am required to use. In in an input field with the same top and bottom padding on a desktop browser uppercase letters are vertically centred. So there is an equal amount of space above the top of an uppercase letter and below the bottom of an uppercase letter. In the same input field on a mobile device the text is aligned differently. There is an equal amount of space above the top of an uppercase letter and below the bottom of a low hanging lowercase letter (e.g. a "g" or a "y"). This leads the text to look misaligned on mobile devices. There's no CSS causing it. If I look at the website in developer tools on desktop at a mobile device size it is aligned the same as in a regular desktop browser window. It's just aligned differently on actual mobile devices. And it's the same in all the mobile browsers I've tested it in (Chrome, Edge, Firefox, and Opera). I wondered if it was the font itself causing it so I switched to a different font (Roboto) and while it's very marginally better it's still clearly misaligned. So while the font I have to use might sit a little high, it's not really the font doing it. Does anyone know if this is just how mobile browsers align text or is there something I can do about it that doesn't involve adjusting padding on every single text element? I tried playing with line-height and that didn't achieve anything, I think because it's just adding or subtracting the same amount of space above and below the font. It's not shifting the baseline that the text sits on.
How much did I do font: #vw back before clamp? all the time on some major sites and still see it when I go to them.
Should I have, nope but what could we do instead. @media 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 and that was a pain.
What is qci? I don't remember seeing that unit type before.
Hi, what so you Thing about Finsweet Fluid responsive generator?
Seems like they've addressed the main points I made about issues with viewport units. I've never used it myself, and generally I'm not a fan of overly-fluid designs, but without having used it, I can't say for sure... but they seem to have taken accessibility in mind 👍
I'm using Bootstrap, are rfs functions included? Or should I use your technique?
BS still exist ? ^^
Why isn't the Variable part of Clamp function not wrapped in a calc() function?
Is something wrong in doing so?
you could put the calc() in there if you want, but you don't need to. clamp(), like min(), max() and others don't require a calc() to do calculations.
@@KevinPowell
Oh! Okay. Thanks. I've been adding the calc() believing that it's necessary.
When i start to build my first web page during my college days. I often use vmin & vmax for font size. After sometimes only i came to know that these font units won't bring responsiveness 😅
But for web based ui editor, wouldn't that be desireable to use vw for font size? Kind of being zoomed out/zoomed in.
You always want to make sure the user is able to enlarge the font-size by themselves.
hey sir, I'm a beginner and I want to know more about the pseudo elements
These days there is no benefits in IT jobs where you can survive with rhe core quality expertise of HTML, CSS, Responsive Design Skills, Hadling Cross Browser Compatibility issues etc. IT companie are focusing only Angular and React skills and once they hired Angular/React guys, therefter they expect 100% expertise in CSS ad HTML from them and the result comes they have to hire an UI/UX designer separately, but in my 16 years of experience working as an UI/UX designer in multiple MNCs I never met single guy who is expert in both - core UI skills like HTML, CSS and React/Angular. IT industries are doing injustice with core UI designers these days bcoz of React and Angular.
I am still barebacking CSS with DP for font-size :)
In my opinion, we should never even change the font size at all. Smaller screens are held closer, and larger screens are held farther. And high res screens of the same size are scaled to make the font size bigger anyway.
Found a height with vw today on the codebase. And not it didn't make any sense.
Back to the drawing board
Well, I'm still using good old px with different media queries for different screen sizes, works just fine.
px is not accessible. Static font sizing should be avoided as changing font size in the browser doesn’t work. Use rem/em as a minimum.
@@n_mckeanEasy to tut, but in reality users are much more likely to change the browser size via the zoom functionality rather than the more obscure way of changing the default rem though. Yes, ideally both ways should be supported but px are still accessible despite common belief thanks to browser zoom.
@@BigBlueRabbit Find an old person, get their phone and look at the size of their menu items and text messages, they'll have scaled their default font size. This function in OS and browsers was created for a reason. Zoom is site-scoped. A user shouldn't have to zoom every site they visit when there is a function to scale everything without intervention. God forbid also the person has poor sight AND mobility issues as you are making them work even harder.
It is easy to tut. It is equally easy to apply the basic CSS tools (rem, no max height, word wrapping) etc to your text that have existed for 15 years. Anyone coding like it is 2010 needs to rethink their career or read up.
Bootstraps Sass RFS system uses calc with em and vw
I immediately got triggered when I saw the thumbnail "font-size: 5vw", thinking "who on earth does this way?!" LOL.
Font clamping with a scaling factor generator is what I usually use all the time and I've been trying to get my designers to do the same because, not only it is so much more easier to implement and it's not based on some arbitrary sizing, it is consistent and it's visually pleasing to look at.
I like `font-size: clamp(16px, 3vw, 20px);`
I have a sass function for this
That seems like a good approach. I hope we can do similar with CSS soon.
Jesus wept, are people just overcomplicating things for no reason? The entire point of REM is that it's relative to the root of the document, not its ancestors. Put the clamp() font-size stuff in the html element and then specify multiples of REM however you see fit for your actual text content.
No need to magic number things or use an insane number of arbitrary custom properties, just 1 item that does the fluidity and every size thereafter derived from it. Fudging the vw unit in the clamp is still horrible though, but done once could be an acceptable trade-off.
Or, and here's a WILD idea, don't have completely responsive text. Even with different pixel densities, all device categories are generally in the same ballpark as each other, so just set up a few media queries with common width ranges and set a fixed unit size for font-size. Hell, put these fixed sizes on the html element and stick with rems for actual text and not only do you preserve the proportionality of size across your different text elements, but you automatically adjust everything based on your device. And browser zooming works are expected as well.
However, the difference between zooming the browser and a user's font size preference for the browser are two different things, and px for font sizes regardless of where you use them is going to break the latter.
Scaling font sizes for me only make sense when you have design elements with a fixed width and height. 1rem (usually 16px by default) looks perfectly fine on ANY device. Increase regular text a little but on mobile if necessary, but that's it.
I actually worked at a company where they scaled everything by setting a calculated font-size via javascript on the html element and scaled EVERYTHING with rem. They considered it perfectly fine, even though everything would jump until all scripts were loaded, everything was too large on phones and tablets in landscape and font sizes were down below 10px on mobile, basically treating the entire page as if it was an image with a width of 100% and height of auto.
@@Azurryu well, that sounds...competent. Honestly I'll never understand how supposedly professional developers can think insane shit like you describe, or what I see in my own place of work, is a good idea. Hell, how the idea even formed in the first place.
This is making things more SIMPLE in my opinion. For example, you probably want to have bigger difference between "h1" and "p" on a big screen than on a phone. And then you have to use media queries. This just eliminates that part.
Can you make a tutorial on how to make Drake’s 100 GIGS Site?
I thought the accessibility issue was obvious. But maybe I've just been doing this too long.
Some backend nerds says: Frontend is easy!
Watch this, mf!
Real Front-end Friends use "1in" for H1, "2in" for H2, etc.
I learn something new about css everyday and it just keeps getting more confusion sigh
There’s just one issue: zooming. In most browsers, zooming doesn’t change the font size or affect REM units. Even with a 200% zoom, 1rem will still render as 16px instead of 32px. REM only adjusts if someone manually increases the font size in their browser settings to 200%.
The regular zoom is in most browser the default zoom. Text zoom is mostly hidden in settings, because it also is effected by OS settings.
You're current that it doesn't change the font-size or `rem` in the strictess of definitions, but it does zoom in/out because it's changing the size of the pixel unit. Even if you set your font sizes in pixels, it will increase decrease the font size. If you zoom to 200%, you've effectively made your CSS pixels 2x bigger than they used to be (because a CSS pixel is not a screen pixel). You can see it in my demo, and you can try it right now on RUclips, or any other site.
You can also see in the video when I have the font-size in viewport units and zoom in and out, the margin on the sides of the pages is increasing/decreasing because of it (because the pixels are getting bigger/smaller), but the font-size isn't changing. As long as you use em, rem, pixels, or whatever else, you can allow the site to zoom in and out.
There are ways to allow for font scaling without zooming. Wikipedia has a control for this right now, and I think offering that is awesome, but as long as you can zoom in/out and have larger/smaller text without any issues, it's perfectly fine.
@@KevinPowell Hey, I really enjoyed your video, but just wanted to clarify a small point! Zooming (graphical zoom) is more of a fallback mechanism and doesn’t fully comply with WCAG 1.4.4, which focuses on scaling text across all websites using relative units like rem or em. When you adjust the font size in the browser, it applies globally, and that’s the ideal way to ensure accessibility for users who need larger text.
You made a great point about the Wikipedia feature-it’s awesome! But for users who rely on larger text, they’ve probably already set a default font size in their browser, making that control less useful for them.
Also, about your vw*rem solution, if you’re already using relative units for both the min and max font sizes, that should be enough to ensure a good balance without complicating things further. Thanks again for the great video-it was mostly spot on, just thought this might help clear things up a bit! :)
It doesn't technically say you can't make users resize the window to change text size 😂
I learnt not to do that the hard way 😂
"Please, don’t use viewport units for font sizes". Sad about this catchy title, since at the end the conclusion is that it's a good idea to use viewport units when done correctly.
coder coder created video "Please stop using px for font-size." now you "Please, don’t use viewport units for font sizes" waiting someone create video on "Please, don’t use rem units for font sizes" 😂😂
Please don't use fonts. Make everything images, they will always scale.
One criterion, two criteria. "Criterions" is not a thing :)
Ummm... I don't like rules written in stone. I think many things can be done if you know when and why you're doing them.
If you're working on government websites, certain private business sites, healthcare or education websites, you HAVE to follow accessibility guidelines by law.
As ZeeZeeGaming said, accessibility rules are generally written in stone. A lot of companies have already faced lawsuits around inaccessible websites, in the US and EU, and the EU is making their accessibility rules even stricter very soon...
That said, there are times when it's less likely to be an issue, like a very large font-size where it probably doesn't matter if it can't be zoomed in on. But as I showed in the video, most of the time if you only use viewport units for font-sizes without a clamp, you're going to get either too big at one point, or too small. Someone out there on their 54" widescreen display is going to full-screen your site and end up with some *very* big type 😆
I'd also say I'm giving some recommendations and best practices here, and in knowing those, it means that you can usually find the times when it's okay to break the rules as well :)
Just because 99.99% of cases should not use vp units for fs, there are legit reasons to do so. Saying don't use them is disingenuous. Always use the right tool for the job.
What is the legit reason that would have you disregard accessibility?
@@n_mckeanbrowser based scoreboards displayed on big LED screens in stadiums. These units work perfectly for this use case.
@@Mecabricks Aha, interesting use case and I see your point now. Definitely the 00.01% of uses though and whilst you're right that accessibility isn't harmed in that case and nor is the design very fluid, sometimes people just need simple rules to follow and saying "never" is probably more helpful than harmful even if not quite correct. You can still deliver on a scoreboard use case without straight viewport units.
As the website name suggests: Only useful in an utopia world 😂
🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣
Setting font-size to the p element is common bad practice... please don't do that.
There are many cases where you would want paragraphs at different font sizes. Different sections on your site may have different visual weight because it is primary vs tertiary content, some sort of callout, etc.
Please use whatever works in the context of the design being implemented and don't pay any attention to the has-been hipsters on RUclips.
Inaccessible design is lazy and immoral.
Just use clamp with VW and problem solved.....
Still not accessible.
@@n_mckean why are u gay?
People really do this?
yes, because "cutting edge" CSS techniques are pushed by grifters and elitists trying to make CSS - and web development as a whole - significantly more complex than it needs to be in order to shill their unnecessary tools and products, and lock out the self-taught from emerging markets.
If somebody with "industry experience" says X is a good approach, it'll instantly be copied by everybody who doesn't know better.
First❤🎉
I’m experimenting using clamp in combination with container query units like
font-size: clamp(1.125em, .625em + 7.25qci, 2.25em)
And I can say, it‘s kind of neat, but also buggy. As long as I don’t resize the Chrome window, everything is fine. But the Chrome tab dies so often if I do. Don‘t have a clue why. 🥲
Huh, that's strange. I haven't run into issues yet, but I haven't played with it too much yet either.