# Fluid Sizing Instead Of Multiple Media Queries?

#### About The Author

Ruslan Yevych is a senior researcher in the Research Institute of Physics and Chemistry of Solid States of Uzhhorod National University (Uzhhorod, Ukraine) and …

More about

Ruslan ↬

If you like math and CSS, you’ll love this one. We don’t need to use media queries to change the values of some CSS properties —

*font-size*,

*padding*,

*margin*etc. — depending on the viewport width, with the CSS

`clamp`

function. But: we still need to use media queries for changing colors, borders, shadows and other CSS styles. This article is an enhanced release of the tutorial published earlier.Media queries are a great concept. Building a complex structure in an HTML document and adapting it for various devices is not often possible without them (for the moment at least). Here we will talk about the fact that one of the drawbacks of **fluid typography**, namely the appearance of a large number of media queries, can be avoided. Or, at least, the number of records in *@media* rule can be reduced.

The advent of `vw`

and `vh`

relative units, the `calc`

function, and later the `min`

, `max`

, `clamp`

functions in CSS gave us a lot of power. An exhaustive review of Modern Fluid Typography Using CSS Clamp has been recently published by Adrian Bece. I advise everyone to get acquainted with it.

The advantages of the ** clamp function** are obvious. We can define a change, for example, of a font size in a certain range of viewport (screen size) and, at the same time, limit it by maximum and minimum values. In such a simple case, we automatically (thanks to clamp) do not need to use media queries for changing sizes on breakpoints.

So, the following block in the CSS:

…can be easily replaced using `clamp`

with a single line:

But what if we need to set a **more complex behavior** which is determined by variety of unique behavior on different ranges of the screen width? Look at the following modified code:

Can the `clamp`

help us again?

Let’s take a closer look: from simple to complex.

## Brief Digression Into Mathematics

As we all know, there is only one way to **draw a straight line** through two points. There are several ways to write equations to define the straight line. Below, it will be convenient for us to write the equation in the form:

$$(1)\;\;\; y=y_0 + k*x$$

where *y _{0}* is a

**point of intersection**of the line with the

`Y`

-axis (fig.1), `k`

parameter defines the slope of the straight line to the `X`

-axis and represents the growth/fall rate. Using the following canonical representation of the equation of a straight line:$$\frac{y – y_1}{y_1 – y_2}=\frac{x – x_1}{x_1 – x_2}$$

It is easy to connect the *y _{0}* and

`k`

parameters with the coordinates of the two points that belong to this line:$$(1a)\;\;\; k=\frac{y_2 – y_1}{x_2 – x_1} ,\;\;\; y_0=y_1 – k*x_1$$

It should be noted that in such problems it is convenient to **define the input parameters** (point coordinates) in pixels. But at the output the relative unit `rem`

is preferable. We should also remember the fact that viewport width is equal to `100vw`

(this follows from the definition of `vw`

unit). So, in equation (1) we must replace `x`

variable by just `100vw`

. Hence, we’ll have:

$$(1b)\;\;\; y=y_0 + k*100vw$$

Now it becomes clear the origin of expressions like `1rem + 2.5vw`

as one of the arguments of `clamp`

or `calc`

function. The first term (`1rem`

) is the *y _{0}* parameter expressed in relative units (

`rem`

), and the second one (`2.5vw`

) is the parameter `k`

multiplied by `100vw`

since `x=100vw`

. The choice of such units — relative unit (`rem`

) for values of output variable and viewport unit (`vw`

) for screen size — has been made due to **accessibility and responsiveness**, respectively.

So, now we know how to determine the parameters in the equation of the form (1) or (1b) of a straight line drawn through two points. This will be used in the next section.

**front-end & UX**, with practical takeaways, live sessions,

**video recordings**and a friendly Q&A. On design systems, UX, web performance and CSS/JS. With Brad Frost, Stephanie Troeth and so many others.

Jump to online workshops ↬