I can see that REMs should be used for all text so that when a user increases their font size in their browser settings, exactly what they want happens: the font size increases.
Client first implements this well by using “container” classes such as “container-large” with a max width of 80rem so that the whole website is narrow and has space on the left and right. This means that when the user increases the font size, the whole page grows (as everything is in rems) into that available space and the design becomes essentially full-screen when then text size is set to large. You see this in all of the finsweet made client-first cloneables.
However, in Finsweet’s actual portfolio, you often see different behaviours. For example, in the build for WeTransfer, you can see that a majority of the site is built in REMs, but in a lot of places where it’s not optimal the developers used pixels. See how the nav bar stays consistent and doesn’t grow as I change the font size.
Where as, in the client-first cloneables, you see this kind of behaviour where the nav bar uses REM for absolutely everything.
Elements gets quashed and go off-screen when the users text size is set to large.
In a lot of client first templates there is also a slight issue with screen real-estate. When every nav element is in REMs, every element grows in size when a user increases their default font size. This makes the elements too wide to fit on one line and often they default to a new line so that they don’t go off-screen. This makes the nav bar multiple lines in height.
As the sticky nav bar becomes taller, it gives the user less and less screen space to view and scroll through the website’s main content, making the website less accessible at large text sizes. You’ll also notice that client-first cloneables typically have very few nav bar links to compensate for the limited space there will be at larger text sizes.
If a client asks for a fair few nav links and a search bar, basket etc, it would make more sense to have all the text/small icons in REM but have their padding/margins in pixels like in the build below. This is so that at least the space between them isn’t also growing and limiting the space when the text size is increased.
There are also times a designer has designed a component to be full width like in the below product carousel. A small part of an image is shown on the far right and left to show a user that there are more products if they scroll left/right. The carousel is built using vw units for the height and width of the images so that they scale perfectly to any laptop/monitor screen size.
This sort of design/functionality would be difficult to implement using rems alone. The design couldn’t be full screen as it would have to fit in a narrow 80rem “container-large”, for example, so that when the users font size increases, theres room for it to grow into. I also find that implementing the javascript functionality of the slider (where the slider moves by one product in either direction) is far easier when you can move it by a proportion of the user’s screen size rather than having to adjust it for multiple media queries with different rem sizes.
Forcing the client’s design into a narrower container when the design was intended to be full-screen to fit the client first framework doesn’t seem like putting the “client first”, it would be putting the framework first.
There is also little advantage to using rems in the above case. Because they are built using vw units, the images don’t grow larger with browser zoom and they don’t grow when a user increases their text size, but the images are already very large by default, for all users. When a user increases their default “text” size, they aren’t expecting the large images to becomes larger, they are trying to magnify the text. By making large images even larger, it makes the entire website harder to navigate because sections become really large and require more scrolling to see in their entirety.
As you can see, there are a lot of cases where using REMs for everything leads to a lot of headaches, so I can see why many of Finsweet’s portfolio websites don’t use REMs for absolutely everything. However, the documentation for client first states that everything should be in REMs, always.
The reason I find this significant is because I see more and more job listings asking for client first v2 and I become apprehensive to apply for them because they sound like jobs with a lot of headaches if the developer is forced to use REMs to comply with the client first framework.
Using REMs for everything feels like giving a mechanic a really versatile screwdriver with lots of attachments and saying “use this for everything at all times because its versatile”. But then there are times when the mechanics life would be so much simpler if they just used a wrench or hammer and used the correct tool for the job. In the same way, using rems for everything inside a “container-large” or “container-medium” makes sense as everything will grow proportionally into the available space, but full width sections and nav bars call for different tools.
So this is why my question here is “are the use of REMs strict in client first?” - is it still client first v2 if you use folders, naming conventions, the client first structure model, but then use px and vw where they make the build more efficient?