DEV Community: Caio Marcellus Cabral

Dynamic components – is it worth it?

Caio Marcellus Cabral — Tue, 06 Feb 2024 23:54:21 +0000

A wild problem appears

During a project I stumbled over a problem – like we always do, right?

I had a component in Astro that returned an anchor tag. At one point, I needed that same UI inside of a form. That is, I needed a submit button. How could I create a component that could be two different tags?

I obsessed over this, nerded-out over it, and managed to solve the problem.

For that specific use case, I discovered – spoiler alert – that it was not the best approach. But I learned one or two things about TypeScript along the way, and here I am to share them with you.
Follow me down this rabbit hole, and let’s explore the structure of components.

I am going to use Astro in all of the examples, there could be some syntax differences when applying these techniques in other frameworks. But what is important here is the mental model over the syntax.

What is a component, anyway?

When working with Astro, React or any other web development framework I know of, you will want to use components. Components are reusable structures that contain all the information for that specific element, like its logic and its styling.

For example, without using a component structure we would need something like this to create a container:



.container{
width: min(90%, 80rem);
margin-inline: auto;
}

Here we have a class called container. A developer would need to add that class to every element they wanted to be a container.
That is prone to mistakes, a.k.a. the human-factor.
We don’t want that, right?

One way of solving that is creating a component. This example would be inside of a Container.astro file.



<div class="container"><slot></div>

<style>
.container{
width: min(90%, 80rem);
margin-inline: auto;
}
</style>

That is great, all we need is in the same place, and any developer would just grab that Container and wrap everything inside of it.

But… what if we wanted the tag to be different? Now we don’t want a div, we actually need a section, for example.

Well, of course you could always add the div within that other tag. But let’s try and make our container component more flexible.
All we need to do is create a prop for the tag, and pass that to a variable. Notice that the variable must be capitalized.



---
type Props = {
tag = “div” | “section” | “main”;
}
const {tag} = Astro.props;
const TagName = tag;
---
<TagName class="container"><slot></ TagName >
<style>
.container{
width: min(90%, 80rem);
margin-inline: auto;
}
</style>

And that’s all! Our container now can be called as a div, as a section, or as the main tag. Now you can create projects with better HTML Semantics.

Let’s dive into another example. We re going to create a title component. The challenge here is allowing the user to declare the heading level: h1, h2, h3, etc.

In our Title.astro file we have:



---
type Props = {
tag: "h1" | "h2" | "h3" | "h4" | "h5" | "h6";
};
const {tag} = Astro.props;
const TagName = tag;
---
<TagName class="title"><slot></TagName >

<style>
.title {
margin-block-end: 0.75em;
}
</style>

And that’s all! We have a Title component that can be of any heading level. But right now it is not very flexible style-wise. It can only have one class, and it doesn’t change, it doesn’t matter if it is an h1 or an h4.

One approach for that would be passing props that would broaden our styling possibilities.



---
type Props = {
tag: "h1" | "h2" | "h3" | "h4" | "h5" | "h6";
size?: “big” | “small”;
align?: “center” | “left”; 
};
const {tag, size="small", align="center"} = Astro.props;
const TagName = tag;
---
<TagName class:list={[
"title",
size,
align
]} >
<slot> 
</TagName>

<style>
.title {
margin-block-end: 0.75em;
}

.small{
font-size: 1.25rem
}

.big{
font-size: 2rem
}

.center{
text-align: center
}

.left{
text-align: left
}

</style>

This is awesome and gives us many possibilities, but what if we want to add extra flexibility to that component? What if we want to allow classes to be passed to it, that can extend the core styling of the component? Let’s say one specific heading needs to be red, and another one needs to be underlined. We don’t want to add props for all those possibilities, right?

Well, we can allow that by adding a classList prop, that will add external classes to that instance of our component.



---
type Props = {
tag: "h1" | "h2" | "h3" | "h4" | "h5" | "h6";
size?: "big" | "small";
align?: "center" | "left"; 
classList?: string[];
};
const {tag, size="small", align="center", classList=[]} = Astro.props;
const TagName = tag;
---
<TagName class:list={[
"title",
size,
align,
…classList
]} >
<slot> 
</TagName >

<style>
(...)
</style>

That solves our problems style-wise, but what if we needed to add an id, or an ARIA attribute? We would get an error.

To deal with that we can use rest parameters in our props, and an index signature in our type.



---
type Props = {
    tag: "h1" | "h2" | "h3" | "h4" | "h5" | "h6";
    size?: "big" | "small";
    align?: "center" | "left";
    classList?: string[];
    [index: string]: string | string[];
};

const {
    tag,
    size = "small",
    align = "center",
    classList = [],
    ...rest
} = Astro.props;
const TagName = tag;
---

<TagName
    class:list={["title", size, align, ...classList]}
    {...rest}
>
    <slot />
</TagName>

<style>
    (...)
</style>

Note that we need to pass [index: string]: string | string[] in our type. That allows us to use any string as a prop. We have to add all the types we have to it, otherwise it will make that key invalid. Here in this example, if we had [index: string]: string our classList would be invalid, because it is an array of strings, not a single string.

We must also use the rest parameter in the props destructuring, as seen in ...rest in our example. What that is doing is grabbing all of the elements in the destructuring assignment that were not declared before.

After doing that we need to spread our rest parameters in our attributes, as seen in ...rest inside of the TagName element.

This will allow us to pass any attribute down to the component.

That is great, right?

Right????

Not really. That way we can pass literally any value to the component, even invalid ones, like passing an inexistent value.
Luckily, Astro has some types that can helps us achieve flexibility while maintaining code safety: HTMLTag and Polymorphic.



---
import type { HTMLTag, Polymorphic } from "astro/types";

type TagType = "h1" | "h2" | "h3" | "h4" | "h5" | "h6";

type Props<TagName extends HTMLTag> = {
    size?: "big" | "small";
    align?: "center" | "left";
    classList?: string[];
} & Polymorphic<{ as: TagName & TagType }>;

const {
    as: Tag,
    size = "small",
    align = "center",
    classList = [],
    ...rest
} = Astro.props;
---

<Tag
    class:list={["title", size, align, ...classList]}
    {...rest}
>
    <slot />
</Tag>

<style>
    (...)
</style>

Here we are taking advantage of Astro’s Polymorphic type, that has the "as" key. "as" gets the Generic type we defined in our Props type (TagName), which extends HTMLTag, that is, it needs to be an existing HTMLTag. I then added the TagType using the intersection operator ({ as: TagName & TagType }).

The truth is, we didn’t need the HTMLTag type, since our TagType is already a group of HTML Tags. But it didn't hurt using it.

Notice the syntax for declaring a variable while destructuring: declaring {a: Tag} = Astro.props is the same as declaring {a} = Astro.props, and then setting const Tag = a.

With this code structure, we are not allowed to pass an invalid attribute to our component anymore. Hooray!

Where it all began

Now we finally get to the problem I originally had. When dealing with our Title component, our problems were easier. All heading levels share the same attributes, while an anchor tag and a button tag don’t!

I needed to create a component that could be an anchor or a button, and when the anchor option was chosen, the type attribute should not be available, as well as the href attribute shouldn’t be available to a button.

This is what I came up with before getting to know the Polymorphic type:



---
type Tag = "a" | "button";

type AnchorProps = {
    href: string;
};

type ButtonProps = {
    type?: "submit" | "button" | "reset";
};

type Props<TagGeneric extends Tag> = {
    tag: TagGeneric;
    variant?: "primary" | "secondary";
    classList?: string[];
    [index: string]: string | string[];
} & (TagGeneric extends "a" ? AnchorProps : ButtonProps);

const {
    tag,
    variant = "primary",
    classList = [],
    href,
    type = "button",
    ...rest
} = Astro.props;

const Tag = tag;

const baseAttributes = {
    classes: ["title", variant, ...classList],
    ...rest,
};

const anchorAttributes = {
    href: href,
};

const buttonAttributes = {
    type: type,
};

const attributeBasedOnTag = tag === "a" ? anchorAttributes : buttonAttributes;

const allAttributes = { ...baseAttributes, ...attributeBasedOnTag };

const { classes, ...attributes } = allAttributes;---

<Tag
    class:list={[classes]}
    {...attributes}
>
    <slot />
</Tag>

What is happening here?

I define the type Tag, the AnchorProps and the ButtonProps. Then we have the type for the SharedProps. This structure is already familiar to you based on what we’ve seen up to this point.

What is new here is the conditional structure for types. We are comparing our generic (TagGeneric), which is defined when the prop tag is passed to the component, and we are extending our props based on that. If it equals “a” - in TypeScript: if it extends “a” - we apply our AnchorProps. Otherwise we apply our ButtonProps.

This is great, but with this structure we still can have inexistent attributes being passed, because of our wildcard [index: string]: string.

Using the Polymorphic type, we can avoid that kind of problem:



---
import type { Polymorphic } from "astro/types";

type Tag = "a" | "button";

type Props<TagGeneric extends Tag> = {
    tag: TagGeneric;
    variant?: "primary" | "secondary";
    classList?: string[];
} & Polymorphic<{ as: TagGeneric }>;

const {
    tag: Tag,
    variant = "primary",
    classList = [],
    href,
    type = "button",
    ...rest
} = Astro.props;

const baseAttributes = {
    classes: ["title", variant, ...classList],
    ...rest,
};

const anchorAttributes = {
    href: href,
};

const buttonAttributes = {
    type: type,
};

const attributeBasedOnTag = Tag === "a" ? anchorAttributes : buttonAttributes;

const allAttributes = { ...baseAttributes, ...attributeBasedOnTag };

const { classes, ...attributes } = allAttributes;
---

<Tag
    class:list={[classes]}
    {...attributes}
>
    <slot />
</Tag>

That way we can never pass an attribute that doesn’t belong in our component.

Of course, since in this component I am basically sharing styles between anchor tags and buttons, I only needed to create two components: ButtonAsAnchor and ButtonAsButton, and make them share CSS classes.

Sometimes the best solution is the simplest. But taking the longer way may gift us with some more tools to our utility belt.

Guidelines

Wrapping up, here are some general guidelines:

Avoid props that are protected terms (e.g.: class, style);
Allow classes to be passed, so your component is extensible;
Use the rest parameter if you might need to allow other attributes in your component;
When using the rest parameter, use the index signature feature from TypeScript in your type;
Check for your framework’s implementation of Polymorphic components;

References:

Fluid Typography

Caio Marcellus Cabral — Mon, 11 Sep 2023 15:15:13 +0000

Photo by Ross Findon in Unsplash

You can access this article in Portuguese here
Você pode acessar este artigo em português aqui

A promise is a debt

A few days ago, I wrote about some typography tips. We discussed the importance of using the REM unit and how to make our fonts responsive using Media Queries. With that, you can already create impeccable web projects in terms of font size. But I promised to talk about making fonts responsive without using Media Queries, and a promise is a debt. So, here we go!

The limits of Media Queries

When we adapt font sizes using media queries, our fonts remain the same size until they reach the breakpoint, and only then they change.

Open the CodePen below and adjust the screen width to see the sudden change in font size.

Open the CodePen in another tab.

Using the fluid typography technique, our font will always adjust to the screen size. For every pixel the screen increases, there will be an increment in font size.

"Caio, what kind of witchcraft is this? How is that possible?"

It's not witchcraft, but a powerful CSS function: clamp().

Getting to know 'clamp()'

With clamp(), we can define a minimum value, an ideal value, and a maximum value.

Let's say we want our font to be 16px on a screen width of 320px and 32px on a screen width of 1920px. Our clamp() would look something like this:



clamp(1rem, valor ideal, 2rem);

/*
You noticed that we're using REM, right?
No PX for fonts, remember?
*/

What about the ideal value? Well, since we want our font to adapt to the screen size, we'll use one of the viewport units, VW. 100vw is the size of the screen, and 1vw is 1% of the screen width. On a 320px screen, 100vw is 320px, and 1vw equals 3.2px.

Let's temporarily use the value of 5vw.



clamp(1rem, 5vw, 2rem)

With this, our font still has those minimum and maximum limits of 16px and 32px (based on the browser's default font), but with 5vw as the ideal value, it will always try to be 5vw in size.

Let's see some examples:

On a 300px screen: 5vw would be 15px. 15px is less than 16px - our minimum font size. In this case, the font would be 16px.

On a 320px screen: 5vw would be 16px. The font used would be 16px.

On a 500px screen: 5vw would be 25px. 25px is greater than 16px, and it's less than the maximum limit of 32px. So, the font used would be 25px.

On a 1000px screen: 5vw would be 50px. Since this value is greater than our limit, the font used would be 32px.

See this applied in the example below:

Open the CodePen in another tab.

Not everything is perfect

We have two problems here:

1) Our font is growing too quickly in this example. It reached our limit at a screen width of 640px, but we wanted it to vary fluidly up to 1920px. It becomes static for 1280px!

2) Using a font based solely on viewport units poses an accessibility problem. Try going back to the previous CodePen and zoom in on the screen. Users cannot zoom in on the font, which remains frozen since it's based on the screen size. You'll notice that the text in the center of the screen doesn't change in size, while the screen and font size counter in the upper-left corner increases.

Using VW + REM

A technique that helps with these two problems is to define the ideal value, the one in the middle of the clamp(), not just in VW, but as a sum of VW and REM.

Let's use the following values:



clamp(1rem, .8rem + 1vw, 2rem)

See in the example below that the font starts to grow exactly after 320px and stops just before 1920px!

Open the CodePen in another tab.

"Caio, you're a genius! How did you come up with that value?"

I hate to disappoint you, dear reader, but I didn't do this calculation in my head! There is a formula to calculate this ideal value, and all the explanations for that will be in one of the articles I'll leave in the references. In this example and in my daily work, I use a tool that calculates it for me.

You can access this tool here.

The Fluid Type Calculator

Here, we can define the minimum and maximum screen widths and the minimum and maximum font sizes — let's just ignore the Type Scale option for now.

The tool provides the clamp() values for you. Then, just add them to your code, and you're good to go.

Dealing with multiple font sizes simultaneously

"Caio, I've never worked on a project with just one font size!"

I know, I know. The example with only one font size was to make things simple. But there's no catch 22 here. Let's apply this logic to our first example, the one with fonts using Media Queries.

There, we had the following font model:

Level 1 -> 16px to 18px;

Level 2 -> 20px to 24px;

Level 3 -> 25px to 32px;

Level 4 -> 31px to 42px;

Now we just need to use our calculator for each of these ranges!

Previously, we had:



:root{
  --fs-1: 1.125rem;
  --fs-2: 1.5rem;
  --fs-3: 2rem;
  --fs-4: 2.625rem
}

@media (max-width: 40em){
  :root{
    --fs-1: 1rem;
    --fs-2: 1.25rem;
    --fs-3: 1.5625rem;
    --fs-4: 1.9375rem
  }
}

Now we end up with this:



:root{
  --fs-1: clamp(1.00rem, calc(0.98rem + 0.13vw), 1.13rem);;
  --fs-2: clamp(1.25rem, calc(1.20rem + 0.25vw), 1.50rem);
  --fs-3: clamp(1.56rem, calc(1.48rem + 0.44vw), 2.00rem);
  --fs-4: clamp(1.95rem, calc(1.81rem + 0.71vw), 2.66rem)
}

See the example below:

Open the CodePen in another tab.

Ok, what about the Type Scale Thing?

As developers, we often don't take part in the font size selection process. Designers usually lead that decision. "And how do they do that?", you might be wondering.

That's a science of its own. There are different systems: the 4-point grid, the 8-point grid, Google's Material Design, and many others. None of these systems can do without the trained eyes of design professionals: systems are not magic and often require adaptations.

One of these systems is modular scale typography. In this system, we start with a font size and increase or decrease it based on a multiplication factor. For example, let's say our smallest font is 10px, and the multiplication factor is 2. Our font system could have the following values: 10px, 20px, 40px, 80px, and so on. This example is exaggerated for didactic purposes, of course.

This methodology adds objectivity to font size selection and helps make our typography hierarchy more consistent.

The Type Scale field in our calculator helps generate fonts using this type of methodology. Let's say I have a project with 4 font levels (4 different sizes), and the smallest font should be 14px on mobile and 20px on monitors.

Here, I'm applying a growth rate of 1.25 on 320px screens while applying a growth rate of 1.414 on 1900px screens. The result is as follows:

Note that font sizes grow much faster on the 1900px screen because we used a higher rate. I invite you to read the excellent articles on modular typography scales that will be in the references of this article to better understand when to choose which rate for your scale. I also encourage you to generate and test different scales and compare the results. What happens when the scale rate is higher on larger screens than on smaller screens? What happens when the rate is the same? And when it's smaller?

Conclusion

We've learned how to apply the fluid typography technique using CSS. Fluid typography is an elegant solution that brings visual integrity to your project on various screens.

Always remember that accessibility is a priority. To ensure your website is accessible, always test it with a 200% zoom.

References

Kevin Powell - Simple solutions to responsive typography
https://www.youtube.com/watch?v=wARbgs5Fmuw

Modern Fluid Typography Using CSS Clamp
https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/

Generating font-size CSS Rules and Creating a Fluid Type Scale
https://moderncss.dev/generating-font-size-css-rules-and-creating-a-fluid-type-scale/

Responsive Type and Zoom
https://adrianroselli.com/2019/12/responsive-type-and-zoom.html

Resize text
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html

Should I change the default HTML font-size to 62.5%?
https://fedmentor.dev/posts/rem-html-font-size-hack/

4-Point Grid System for more consistent interface design
https://medium.com/@aratidube12lns/4-point-grid-system-for-more-consistent-interface-design-efea81dea3f3

More Meaningful Typography
https://alistapart.com/article/more-meaningful-typography/

Um guia prático para criar um tipo de escala modular para suas interfaces
https://www.ux-republic.com/pt/guia-pr%C3%A1tico-para-criar-um-tipo-de-escala-modular-para-suas-interfaces/

Tipografia fluida

Caio Marcellus Cabral — Mon, 11 Sep 2023 15:14:43 +0000

Foto por Ross Findon no Unsplash

You can access this article in English here
Você pode acessar este artigo em inglês aqui

Promessa é dívida

Alguns dias atrás escrevi sobre algumas dicas de tipografia. Vimos a importância de usarmos a unidade REM, e como tornar responsivas nossas fontes usando Media Queries. Com isso você já consegue fazer projetos para a web impecáveis do ponto de vista do tamanho de fontes. Mas eu prometi que iria falar sobre como tornar as fontes responsivas sem usar Media Queries, e promessa é dívida. Vamos lá!

Os limites das Media Queries

Quando adaptamos o tamanho de fontes usando media queries, nossas fontes ficam com o mesmo tamanho até atingir o ponto de quebra, e só aí mudam.

Abra o codepen abaixo e mexa na largura da tela para ver a mudança repentina no tamanho da fonte.

Abra o codepen em outra aba.

Usando a técnica de tipografia fluida, nossa fonte vai sempre se ajustar ao tamanho da tela. A cada pixel que a tela aumenta, há um incremento nas fontes.

“Caio, que bruxaria é essa? Como isso é possível?”

Não é bruxaria, mas uma função poderosíssima do CSS: o clamp().

Conhecendo o clamp()

Com o clamp a gente pode definir um valor mínimo, um valor ideal, e um valor máximo.

Digamos que queremos que nossa fonte seja 16px em uma largura de tela de 320px, e que seja de 32px numa largura de tela de 1920px. Nosso clamp ficaria mais ou menos assim:

clamp(1rem, valor ideal, 2rem);

/*
Notou que estamos usando REM, certo? 
Nada de PX para fontes, lembra?
*/

E para o valor ideal? Bem, como a gente quer que nossa fonte se adapte ao tamanho da tela, vamos aplicar uma das viewport units, o VW. 100vw é o tamanho da tela. 1vw é 1% da largura da tela. Numa tela de 320px, 100vw são 320px, 1vw é igual a 3.2px.

Vamos usar temporariamente o valor de 5vw.

clamp(1rem, 5vw, 2rem)

Com isso, nossa fonte ainda tem aqueles limites mínimo e máximo de 16px e 32px (pela fonte padrão do navegador), mas com o 5vw como valor ideal ela vai sempre tentar ter 5vw de tamanho.

Vejamos alguns exemplos:

Em uma tela de 300px: 5vw seria 15px. 15px é menor que 16px – nossa fonte mínima. Nesse caso, a fonte seria 16px.

Em uma tela de 320px: 5vw seria 16px. A fonte usada seria 16px.

Em uma tela de 500px: 5vw seria 25px. 25px é maior que 16px, e é menor que o limite máximo de 32px. A fonte usada seria 25px.

Em uma tela de 1000px: 5vw seria 50px. Como esse valor é maior que o nosso limite, a fonte utilizada seria de 32px.

Veja esse exemplo aplicado abaixo:

Abra o codepen em outra aba.

Nem tudo são flores

Temos dois problema aqui:

1) Nossa fonte está crescendo rápido demais nesse exemplo. Ela atingiu o nosso limite em 640px de largura de tela, e nós queríamos que ela variasse de forma fluida até 1920px. Ela ficaria estática por 1280px!

2) Usar uma fonte baseada somente em unidades de viewport traz um problema para a acessibilidade. Experimente voltar no codepen anterior, e dê zoom na tela. A pessoa usuária não consegue dar zoom na fonte, que fica congelada já que está baseada no tamanho da tela. Veja que o texto no centro da tela não altera de tamanho, enquando o contador de tamanho de tela e fonte no canto superior esquerdo aumenta.

Usando VW + REM

Uma técnica que ajuda com esses dois problema é definir o valor ideal, do meio do clamp, não apenas em vw, mas em um cálculo da soma de vw com rem.

Vamos usar os seguintes valores:

clamp(1rem, .8rem + 1vw, 2rem)

Veja no exemplo abaixo que a fonte começa a crescer exatamente depois de 320px, e para logo antes de 1920px!

Abra o codepen em outra aba.

“Caio você é um gênio! Como você chegou nesse valor?”

Odeio desapontar você, querida pessoa leitora, mas eu não fiz essa conta de cabeça! Existe uma fórmula para calcular esse valor ideal, e toda a explicação disso vai estar em um dos artigos que vou deixar nas referências. Nesse exemplo e no dia-a-dia eu uso uma ferramenta que calcula isso pra mim.

Você pode acessar essa ferramenta aqui.

O Fluid Type Calculator

Aqui a gente pode definir a largura mínima e máxima de tela e o tamanho mínimo e máximo de fonte - ignore por hora a opção de Type Scale (Escala de tipografia).

A ferramenta já dá os valores em clamp para você. Daí é só colocar no seu código e correr pro abraço.

Lidando com mais de um tamanho ao mesmo tempo

“Caio, eu nunca trabalhei em um projeto com um tamanho de fonte só!”

Eu sei, eu sei. O exemplo com só um tamanho de fonte era pra facilitar o entendimento. Vamos aplicar essa lógica para aquele nosso primeiro exemplo, das fontes com Media Queries?

Lá tínhamos o seguinte modelo de fonte:

Nível 1 -> 16px até 18px;

Nível 2 -> 20px até 24px;

Nível 3 -> 25px até 32px;

Nível 4 -> 31px até 42px;

Daí é só a gente entrar naquela nossa calculadora e fazer cada um desses intervalos!

Antes tínhamos:

:root{
  --fs-1: 1.125rem;
  --fs-2: 1.5rem;
  --fs-3: 2rem;
  --fs-4: 2.625rem
}

@media (max-width: 40em){
  :root{
    --fs-1: 1rem;
    --fs-2: 1.25rem;
    --fs-3: 1.5625rem;
    --fs-4: 1.9375rem
  }
}

O resultado é esse daqui:

:root{
  --fs-1: clamp(1.00rem, calc(0.98rem + 0.13vw), 1.13rem);;
  --fs-2: clamp(1.25rem, calc(1.20rem + 0.25vw), 1.50rem);
  --fs-3: clamp(1.56rem, calc(1.48rem + 0.44vw), 2.00rem);
  --fs-4: clamp(1.95rem, calc(1.81rem + 0.71vw), 2.66rem)
}

Veja no exemplo abaixo:

Abra o codepen em outra aba.

E aquele lance de Type scale?

Nós, como desenvolvedores, muitas vezes não participamos do processo de escolha do tamanho de fontes. Designers costumam estar à frente dessa decisão. “E como eles chegam naqueles valores?”, você pode estar se perguntando.

Isso é uma ciência à parte. Há diferentes sistemas: o 4-point grid, o 8-point grid, o Material Design do Google, e muitos outros. E o uso de nenhum desses sistemas prescinde do olhar treinado dos profissionais de design: sistemas não são mágica, e muitas vezes necessitam de adaptações.

Um desses sistemas é a tipografia com escala modular. Nesse sistema, nós partimos de um tamanho de fonte, e aumentamos ou diminuímos a partir de um fator de multiplicação. Por exemplo, digamos que nossa menor fonte seja 10px, e que o fator de multiplicação seja 2. Nosso sistema de fontes poderia ter os seguintes valores: 10px, 20px, 40px, 80px, etc. Esse exemplo é um exagero, apenas com fins didáticos, claro.

Essa metodologia imprime uma maior objetividade na escolha dos tamanhos de fonte, e ajuda a hierarquia da nossa tipografia a ser mais consistente.

O campo Type Scale da nossa calculadora ajuda a gerar fontes usando esse tipo de metodologia. Digamos que eu tenha um projeto com 4 níveis de fonte (4 tamanhos diferentes), e o menor deles deve ser 14px em celulares e 20px em monitores.

Aqui estou aplicando uma taxa de crescimento de 1.25 em telas de 320px, enquanto aplico uma taxa de crescimento de 1.414 em telas de 1900px. O resultado é o seguinte:

Note que os tamanhos de fonte crescem bem mais rápido na tela de 1900px, porque a taxa que usamos é maior. Convido você a ler os excelentes artigos sobre escalas modulares em tipografia que estarão nas referências deste artigo para entender melhor em que situações escolher qual taxa para a sua escala. Encorajo ainda a gerar e testar diferentes escalas e comparar o resultado. O que acontece quando a a taxa da escala em telas grandes é maior que em telas pequenas? O que acontece quando a taxa é a mesma? E quando é menor?

Conclusão

Aprendemos como aplicar a técnica de tipografia fluida usando CSS. A tipografia fluida é uma solução elegante que traz integridade visual para o seu projeto nas mais diversas telas.

É sempre importante lembrar que a acessibilidade é uma prioridade. Para garantir que seu site está acessível, faça sempre testes com zoom em 200%.

Referências

Kevin Powell - Simple solutions to responsive typography
https://www.youtube.com/watch?v=wARbgs5Fmuw

Modern Fluid Typography Using CSS Clamp
https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/

Generating font-size CSS Rules and Creating a Fluid Type Scale
https://moderncss.dev/generating-font-size-css-rules-and-creating-a-fluid-type-scale/

Responsive Type and Zoom
https://adrianroselli.com/2019/12/responsive-type-and-zoom.html

Resize text
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html

Should I change the default HTML font-size to 62.5%?
https://fedmentor.dev/posts/rem-html-font-size-hack/

4-Point Grid System for more consistent interface design
https://medium.com/@aratidube12lns/4-point-grid-system-for-more-consistent-interface-design-efea81dea3f3

More Meaningful Typography
https://alistapart.com/article/more-meaningful-typography/

Um guia prático para criar um tipo de escala modular para suas interfaces
https://www.ux-republic.com/pt/guia-pr%C3%A1tico-para-criar-um-tipo-de-escala-modular-para-suas-interfaces/

Using REM Doesn't Make Your Website Responsive - Here's Why

Caio Marcellus Cabral — Wed, 30 Aug 2023 16:14:15 +0000

You can access this article in portuguese here
Você pode acessar este artigo em português aqui

I love being part of technology communities. Besides learning a lot from people with more experience than me, it allows me to share some of what I've learned with other developers. In addition to that, while trying to answer some of the questions that come up, I am compelled to do a lot of research, which leads me to deeply understand some techniques that I knew to work but didn't know why.

Recently, in Alura’s Discord community, I came across a question from a user who wanted to solve a layout problem on smaller screens. Her font sizes were too big, and layout would break. One of the Discord users advised her to change the font size measurements to REM.

And this isn't the first time I've seen this misconception.

I've worked on a project where an experienced developer used a library that converted all measurements originally in pixels to REM, believing that this contributed to the site's responsiveness.

Knowing that typography is a topic that gets so little attention from developers (yeah, I am talking to you, who only declares font-size and font-family and completely ignores font-weight and line-height), I decided to write this article to talk about best practices when working with text in web development.

1) Organize your typography information in one place

The first thing I see very often is the repetition of font size declarations. On the header, the developer declares:



.cabecalho{
  font-size: 18px
}

Moments later, they need to declare:



.titulo{
  font-size: 18px
}

This works, of course. But what if there's a change in the font sizes used in the project? You'll need to go on a scavenger hunt to find all occurrences.

And change them.

One.

By.

One.

Not very practical, right?

There's a programming principle we can use to solve this problem: DRY (Don't Repeat Yourself). It states that if we're copying a piece of code or information, it could be isolated in a function or variable that can be called or referenced elsewhere in the code.

So, we could declare our font sizes as CSS Custom Properties, aka "CSS variables":



:root{
  --fs-1: 12px;
  --fs-2: 16px;
  --fs-3: 20px;
}

.cabecalho{
  font-size: var(--fs-2)
}

.hero-banner{
  font-size: var(--fs-3)
}

main .titulo{
  font-size: var(--fs-3)
}

.rodape{
  font-size: var(--fs-2)
}

This way we reduce the chance of errors, as well as keep this information in one place, greatly improving the maintainability of our code.

2) Never use PX again

In programming, it's rare being able to say something so straightforward: never do X, always do Y. Usually, there are multiple ways to achieve a goal, different techniques with pros and cons, and we need to analyze each case to determine the best approach. And that’s the beauty of this field. I like to think that in programming there is no right way of doing anything, just not-wrong ways.

But in this case, I say it without hesitation: you shouldn't use PX for your font sizes.

Let me tell you a story: Alberto can't read very small letters. They seem to shuffle in front of him, making it difficult for Alberto to do web research for school. This changed when Alberto discovered he could change the default font size in his browser! The default font size in browsers is 16px, but Alberto can change it to 24px, which makes his life much better.

The problem is that the developer who created one of the sites Alberto wants to access used pixels (PX) for all fonts. And 18px will always be 18px because it's an absolute measurement that doesn't adapt to user preferences. Using PX for font size made Alberto's experience less satisfactory, perhaps even preventing him from accessing that content.

That's what happens when we use PX for font sizes: we ignore user preferences and impose the exact size we've chosen.

Fortunately, we can overcome this problem by using the REM unit.

REM is based on the browser's default font size, which is typically 16px. So, usually, 1rem is equal to 16px.

"But, Caio, I need to use 18px in my project, not 16px." .

Easy-peasy: in the default measurement, 18px is equal to 1.125rem. We just need to divide the value we want by 16.

Here's a list of some frequently used values:
.25rem = 4px;
.5rem = 8px;
.75rem = 12px;
1.5rem = 24px;

Notice that I said these are generally the REM values in pixels because this conversion was done using browsers’ default values. In Alberto's case, it would be different: 1rem would be equal to 24px, and 1.125rem would be equal to 27px.

So, everyone wins: those who use the default font size will have the same experience, but those who choose to change it will have their choice respected.

Let's see how our declaration from item 1 would look like:



:root{
  --fs-1: 12px;
  --fs-2: 16px;
  --fs-3: 20px;
}

This would become:



:root{
  --fs-1: .75rem;
  --fs-2: 1rem;
  --fs-3: 1.25rem;
}

Easy, right?

One more thing: many people, finding it difficult to divide by 16, do the following:



html{
  font-size: 62,5%
}

This sets the default font size to 10px, making it much easier to define values in REM.

Sounds great, doesn't it?

But, please, don’t do it.

Doing this can confuse other developers, it is difficult to undo, and can conflict with libraries possibly used in the project.

So, don't change the base font size of the browser. It might provide some comfort and convenience for you now, but it could have negative consequences for your users and project collaborators.

3) REM doesn't solve responsiveness

Now that you know what REM is and how to use it, your website will be fully responsive and beautiful, right?

If you've been paying close attention, you've already read the introduction to this article, and you know that's not the case. Let's understand why that is.

When we talk about responsiveness, we're generally referring to a website that adapts to various screen sizes: the site should work well on smartphones, tablets, laptop screens, and ultrawide monitors.

However, REM has nothing to do with screen size. 1rem will be, by default, 16px on a smartphone screen or a television.

Since it doesn't care about the screen size, let's say you create a rectangle for screens of 1600px width, and you define the width of this rectangle like this: width: 100rem.

You'll get a 1600px rectangle for users who use the default font size. But if a user changes the default font size to 20px, your rectangle will now be 2000px wide, causing overflow on the screen you had in mind.

I created an example of this on CodePen. Since each reader will be viewing this on different screens, I replicated the scenario of using REM to adjust content to the screen size by setting the width to 100%, then subtracting 16px and adding 1rem.

In this way, with the default size, everything works fine, but when the user's default size is different, our layout breaks. That's because in this context, we shouldn't use REM or PX. It's ideal to work with percentages. But delving into responsiveness is a topic for another article!

Or access here.

Note: I am deining the font size on HTML to 16px to allow us to test changing the default font size more easily. That code snippet is for didactic purposes only.

On the next example, you can see that the text inside the box will sometimes fit and sometimes overflow as we play with resizing the screen and changing the default font size via the input.

The behavior is erratic.

The width and height of the box are set in a way that, when the content varies, the layout breaks. The conclusion is that defining our H1 font size with REM didn't help with responsiveness at all.

Or access here.

Note: I set the height of this div using height for didactic purposes. Setting height on elements with content is a bad practice for responsiveness.

"Caio, my world fell apart! How do I make the fonts in my project responsive?"

The most common way to make your fonts responsive is by using them: media queries.

This allows you to define that from a certain screen size—let's say, 1200px—your fonts that were 12px, 16px, and 20px will have sizes of 18px, 24px, and 32px—yes, in this blog, we preach the gospel of mobile-first.

It would look something like this:



:root{
  --fs-1: .75rem;
  --fs-2: 1rem;
  --fs-3: 1.25rem;
}

@media (min-width: 75em){
  :root{
    --fs-1: 1.125rem;
    --fs-2: 1.5rem;
    --fs-3: 2rem;
  }

}

Don't be scared of the EM unit in the media query. It's a good practice to declare media queries with this unit. I can talk more about that another time.

As seen in the previous section, REM helps make our site accessible. Note that I said "help make accessible." Accessibility is a complex and multifaceted issue, and we need to take many steps to ensure accessibility on our site for as many people as possible. We need to pay attention to colors, keyboard navigation, screen readers, and much more. In the case of REM, we're only dealing with one aspect of it: font size.

To illustrate the distinction between responsiveness and accessibility, I created this example. It includes four text cases:

1) Not responsive and not accessible (doesn't change with screen size, uses PX)

2) Not responsive and accessible (doesn't change with screen size, but uses REM)

3) Responsive and not accessible (changes with screen size, but uses PX)

4) Responsive and accessible (changes with screen size and uses REM)

Change the screen width and the font size to see how the font sizes behave.

Or access here

With these examples, we can see that it's past time for you to replace all your PX fonts with REM, but don't fool yourself: this alone won't make your site responsive.

4) Define your line heights

When you were working on school or college assignments that needed a certain number of pages, you may have been tempted to increase the line height to make the content take up more space.

"Set double-spacing. Do it, no one will notice.", said the voice in your head.

The truth is, line height makes all the difference in text legibility (the correct term here would be "readability." I encourage you to look up the difference).

It's very common to find projects where the font family, weight, and size are defined, but the line height is not declared.

When we do this, we delegate the setting of line height to the browser, and each browser has a different default. Sounds bad, right?

So, we should always explicitly declare our line height. But how do we do that? With the line-height property!

We should follow the same principles as with font size: no PX!

Imagine you have a font of 1rem (remember, no PX for font size), and you set the line height to 20px. What will happen if the user's default font size is 24px? That's right: the font size will become 24px, but the line height will remain locked at 20px, and the text will become cluttered.

Or access here

One solution would be to define the line height in REM, this was it could vary along with the font size. However, by doing that, every time we change the font size within a media query we would have to change the line height too, to maintain the scale.

There's an easier way: this property accepts percentages. So, we can declare the line height as we used to in Microsoft Word: 1, 1.2, 1.5, 2.

In our example, if I have a font of 1rem and a line height of 1.25, the values will generally be 16px and 20px. But if the user's default font size is 24px, the values will be 24px and 30px. This way, we always maintain the same proportion between font and line height. What's even better is that if the size of our font changes with media queries, we don't need to redeclare the line height!

See this example: here we are using REM units, changing them with media queries, and defining the line height relatively to the font size.

Or access here

Conclusion

In this article, we learned some typography best practices, saw how to have more control over our fonts, how to avoid code repetition, and how to make our texts more accessible and responsive.

With everything we've seen here, you already know everything you need about typography to create flawless web projects. But we can always go further, right?

Did you notice that I mentioned, "The most common way to make your fonts responsive is with them: media queries."?

What if I told you that you can make your font sizes vary WITHOUT USING MEDIA QUERIES???

So, stay tuned, because soon there will be an article about how to implement the technique of fluid typography.

Usar REM não torna seu site responsivo – entenda por quê

Caio Marcellus Cabral — Wed, 30 Aug 2023 16:13:36 +0000

You can access this article in English here
Você pode acessar este artigo em inglês aqui

Eu adoro participar de comunidades de tecnologia. Além de aprender muito com pessoas com mais experiência do que eu, eu tenho a oportunidade de dividir um pouco do que aprendi com outros desenvolvedores. Além disso, ao tentar responder algumas dúvidas que surgem, eu me obrigo a pesquisar e acabo conhecendo profundamente algumas técnicas que eu sabia que funcionavam, mas não sabia por quê.

Recentemente no Discord da Alura eu esbarrei com uma dúvida de uma usuária que queria resolver um problema de layout em telas menores. As fontes dela estavam grandes demais, e o conteúdo quebrava. Um dos usuários do Discord orientou ela a mudar as medidas dos tamanhos de fonte para REM.

E não é a primeira vez que vi essa confusão.

Já trabalhei em um projeto em que um desenvolvedor experiente utilizava uma biblioteca que convertia todas as medidas originalmente em PX (pixel) para REM, acreditando que assim estava contribuindo com a responsividade do site.

Sabendo que tipografia é um assunto que recebe tão pouco carinho dos desenvolvedores (sim, eu tô falando com você que só declara font-size e font-family, e ignora completamente font-weight e line-height), resolvi escrever este artigo para falar de algumas boas práticas ao trabalhar com texto no desenvolvimento web.

1) Concentre as informações de tipografia em um único lugar

A primeira coisa que vejo com muita frequência é a repetição da declaração de tamanho de fonte.

No cabeçalho, a pessoa desenvolvedora declara:

.cabecalho{
  font-size: 18px
}

Alguns momentos depois, essa pessoa vai precisar declarar:

.titulo{
  font-size: 18px
}

Isso funciona, é claro. Mas e se houver uma mudança nos tamanhos de fonte usados no projeto? Vamos precisar fazer uma gincana para encontrar todas as ocorrências.

E mudar.

Uma.

Pouco prático, né?

Há um princípio na programação que podemos usar para pensar como resolver esse problema: o DRY (Don’t repeat yourself – Não se repita). Ele postula que, se estamos copiando um trecho de código ou informação, aquilo poderia ser isolado em uma função ou variável, que poderão ser chamadas ou referenciadas em outros pontos do código.

Poderíamos, então, declarar nosos tamanhos de fonte como Custom Properties do CSS (Propriedades Personalizadas, vulgo “variáveis do CSS”).

:root{
  --fs-1: 12px;
  --fs-2: 16px;
  --fs-3: 20px;
}

.cabecalho{
  font-size: var(--fs-2)
}

.hero-banner{
  font-size: var(--fs-3)
}

main .titulo{
  font-size: var(--fs-3)
}

.rodape{
  font-size: var(--fs-2)
}

Assim, reduzimos a chance de erros, além de ter essas informações concentradas em um só lugar, aumentando em muito a manutenibilidade do nosso código.

2) Nunca mais use PX

É muito raro em programação a gente poder falar algo com essa força: nunca faça X, sempre faça Y. Com frequência temos múltiplas maneiras de atingir um objetivo, técnicas diferentes com vantagens e desvantagens, e temos sempre que analisar o caso para pensar qual a melhor forma de implementar. E essa é uma das belezas desse ramo. Gosto de pensar que em programação não existe uma forma certa de fazer algo, apenas formas não-erradas.

Mas nesse caso eu falo sem medo de errar: você não deveria usar PX para o tamanho das suas fontes.

Deixa eu contar uma história: Alberto não consegue ler com letras muito pequenas. Elas parecem se embaralhar diante dele, ficam borradas, o que desmotivava Alberto ao fazer pesquisas na web para a escola. Isso mudou quando Alberto descobriu que poderia alterar a fonte padrão do seu navegador! A fonte padrão dos navegadores é 16px, mas Alberto consegue alterar para 24px, o que torna sua vida muito melhor.

Acontece que a pessoa desenvolvedora que fez um dos sites que o Alberto quer acessar usou PX (pixels) em todas as fontes. E 18px sempre vão ser 18px, porque ele é uma medida absoluta, ou seja, não se adapta às preferências do usuário. Usar PX no tamanho da fonte tornou a experiência do Alberto menos satisfatória, talvez até impossibilitando ele de acessar aquele conteúdo.

É isso que acontece quando usamos PX no tamanho das fontes: nós estamos ignorando a preferência dos usuários e impondo o tamanho exato que nós escolhemos.

Felizmente temos como contornar esse problema usando a unidade de medida REM.

O REM se baseia no tamanho de fonte padrão do navegador. Como o padrão é de 16px, geralmente 1rem vai ser igual a 16px.

“Mas, Caio, eu preciso usar 18px no meu projeto, não 16px.”.

Moleza: na medida padrão, 18px é igual a 1.125rem. É só dividir o valor que você quer por 16.

Segue uma listinha de alguns valores comuns:
.25rem = 4px;
.5rem = 8px;
.75rem = 12px;
1.5rem = 24px;

Perceba que eu falei que esses são geralmente os valores de REM em PX. Isso porque essa conversão foi feita usando os valores padrão do navegador. No caso do nosso amigo Alberto, isso seria diferente: 1rem seria igual a 24px, e 1.125rem seria igual a 27px.

Assim, todo mundo sai ganhando: quem usa o tamanho padrão de fonte vai ter a mesma experiência, mas quem escolhe mudar, tem a sua escolha respeitada.

Vejamos como ficaria a nossa declaração lá no item 1:

:root{
  --fs-1: 12px;
  --fs-2: 16px;
  --fs-3: 20px;
}

Viraria:

:root{
  --fs-1: .75rem;
  --fs-2: 1rem;
  --fs-3: 1.25rem;
}

Fácil, né?

Mais uma coisa: muita gente, por achar difícil fazer a divisão por 16, faz o seguinte:

html{
  font-size: 62,5%
}

Assim a fonte padrão passa a ser 10px, e fica muito mais fácil definir o valor em REM. Maravilha, né?

Só que não.

Fazer isso pode confundir outros desenvolvedores, é difícil de desfazer, e pode trazer conflito com bibliotecas possivelmente utilizadas no projeto.

Então, não mude a fonte base do navegador. Isso pode trazer algum conforto e facilidade para você agora, mas pode trazer consequências ruins para os seus usuários, e para colaboradores do projeto.

3) REM não resolve responsividade

Agora que você sabe o que é o REM e como usá-lo, seu site vai ficar todo responsivo e bonitão, né?

Você, pessoa leitora atenta, leu a introdução desse artigo e já sabe que não. Vamos entender isso direito.

Quando falamos de responsividade estamos geralmente falando de um site que se adapte aos diversos tamanhos de tela que existem: o site funciona sendo aberto em celulares, em tablets, em telas de laptop, e em monitores ultrawide.

Acontece que o REM não tem nada a ver com tamanho de tela. 1rem vai ser, por padrão, 16px em uma tela de celular ou em uma televisão.

Como ele não liga para o tamanho da sua tela, digamos que você crie um retângulo para telas de 1600px. E você define a largura desse retângulo assim: width: 100rem.

Você vai conseguir um retângulo de 1600px para os usuários que usarem a fonte padrão, mas se algum usuário mudar a fonte padrão para 20px, seu retângulo passa a ter 2000px, gerando transbordamento na tela que você tinha em mente.

Fiz um exemplo disso no CodePen. Como cada um dos leitores vai estar vendo isso em telas diferentes, eu reproduzi o cenário de uso de REM para ajustar conteúdo ao tamanho da tela estabelecendo a largura como 100%, daí diminuí 16px e aumentei 1rem.

Dessa forma, com o tamanho padrão vai dar tudo certo, mas quando o padrão do usuário for diferente, nosso layout quebra. Isso porque nesse tipo de contexto nós não queremos usar REM, nem PX. O ideal é trabalhar com porcentagem. Mas o mergulho em responsividade fica para outro artigo!

Ou acesse aqui.

Observação: Eu estou definindo a fonte no HTML em 16px para permitir que façamos o teste da mudança da fonte padrão de forma mais fácil. Esse trecho de código tem fins puramente didáticos.

No próximo exemplo, podemos ver que o texto dentro da caixa vai estar ora dentro, ora transbordando, conforme a gente brinca de diminuir e aumentar a tela, ou de mudar a fonte padrão pelo input.

O comportamento é errático.

A largura e altura da caixa são estabelecidas de forma que, quando o conteúdo varia, temos quebra do layout. A conclusão é: nosso H1 ter a fonte definida com REM não ajudou em nada a responsividade.

Ou acesse aqui.

Observação: eu estabeleci a altura dessa div usando height com fins didáticos. Estabelecer height em elementos com conteúdo é uma prática ruim para responsividade.

"Caio, meu mundo caiu! Como eu faço para deixar as fontes do meu projeto responsivas?"

A forma mais comum de tornar as suas fontes responsivas é com elas: as media queries.

Com isso você define que a partir de determinado tamanho de tela – digamos, 1200px - suas fontes que eram 12px, 16px e 20px vão ter um tamanho de 18px, 24px e 32px – sim, nesse blog difundimos a palavra do mobile-first.

Ficaria algo mais ou menos assim:

:root{
  --fs-1: .75rem;
  --fs-2: 1rem;
  --fs-3: 1.25rem;
}

@media (min-width: 75em){
  :root{
    --fs-1: 1.125rem;
    --fs-2: 1.5rem;
    --fs-3: 2rem;
  }

}

Não se assuste com a media query definida com EM. É uma boa prática declarar media queries com essa medida. Um dia posso falar disso por aqui.

O REM, como vimos no tópico anterior, vai ajudar a tornar nosso site acessível. Veja que eu disse “ajudar a tornar acessível”. O assunto acessibilidade é extenso e multifacetado, e precisamos tomar muitas medidas para garantir a acessibilidade no nosso site para o máximo de pessoas possível. Temos que atentar às cores, à navegação com teclado, leitores de tela e muito mais. No caso do REM, estamos lidando apenas com um aspecto: o tamanho das fontes.

Para ilustrar essa distinção entre responsividade e acessibilidade eu criei esse exemplo. Nele, temos 4 casos de texto:

1) não-responsivo e não-acessível (não muda de acordo com o tamanho da tela, e usa PX)

2) não-responsivo e acessível (não muda de acordo com o tamanho da tela, mas usa REM)

3) responsivo e não-acessível (muda de acordo com o tamanho da tela, mas usa PX)

4) responsivo e acessível (muda de acordo com o tamanho da tela, e usa REM)

Mexa na largura da tela e no tamanho da fonte para ver como o tamanho de fonte se comporta em cada caso

Ou acesse aqui

Com esses exemplos a gente consegue ver que, sim, já passou da hora de você substituir todas as suas fontes de PX para REM, mas não se engane: isso não vai tornar seu site responsivo.

4) Defina o tamanho das suas linhas

Quando você ia fazer trabalhos da escola ou faculdade que precisavam ter um número X de páginas, você tinha a tentação de mudar a altura da linha, para o conteúdo ocupar mais espaço.

“Coloca o espaçamento 2x, ninguém vai perceber”, diz a vozinha na sua cabeça.

A verdade é que a altura da linha faz toda a diferença na legibilidade de um texto (o termo correto aqui seria leiturabilidade. Fique aí com esse palavrão e pesquise a diferença).

É muito comum encontrar projetos em que o texto tem a família da fonte definida, o peso e o tamanho, mas a altura da linha não é declarada.

Quando fazemos isso, delegamos para o navegador a escolha da altura de linha, e cada navegador tem um padrão diferente. Não é uma boa, né?

Por isso devemos sempre declarar explicitamente nossa altura de linha. Mas como fazemos isso? Com a propriedade line-height!

A gente deve seguir os mesmos princípios que para tamanho de fonte: nada de PX!

Imagina que você tenha uma fonte de 1rem (nada de PX pra fonte, lembra?), e coloca a altura da linha com 20px. O que vai acontecer se a fonte padrão do usuário for 24px? Isso mesmo: a fonte das letras vai passar a ser de 24px, mas a altura da linha vai ficar travada em 20px, e o texto vai ficar todo embolado.

Ou acesse aqui

Uma saída seria definir a line-height em REM, assim ela poderia variar junto com o tamanho da fonte. Porém, fazendo dessa forma, sempre que a gente mudar o tamanho da fonte em uma media query a gente precisaria lembrar de mudar a line-height também, para manter sempre a mesma proporção.

Tem uma forma mais fácil de fazer isso: essa propriedade aceita porcentagem. Então a gente pode declarar a line-height como a gente fazia no Microsoft Word: 1, 1.2, 1.5, 2.

Nesse nosso exemplo, caso eu tenha uma fonte de 1rem e line-height de 1.25, os valores por padrão serão 16px para o tamanho da fonte e 20px para o tamanho da linha. Mas se a fonte padrão da pessoa usuária for 24px, os valores serão 24px e 30px respectivamente. Assim teremos sempre a mesma proporção entre fonte e altura de linha. Para melhorar: caso o tamanho da nossa fonte mude com media queries, não precisamos redeclarar a line-height!

Veja esse exemplo: aqui estamos usando REM para as fontes, mudando elas com media query e definindo line-height proporcionalmente ao tamanho da fonte.

Ou acesse aqui

Conclusão

Neste artigo aprendemos algumas boas práticas de tipografia, vimos como ter mais controle sobre as nossas fontes, como evitar a repetição de código, e como tornar nossos textos mais acessíveis e responsivos.

Com tudo que vimos aqui, você já sabe tudo que precisa sobre tipografia para fazer projetos para a web impecáveis. Mas a gente sempre pode ir além, né?

Você notou que eu falei que “A forma mais comum de tornar as suas fontes responsivas é com elas: as media queries.”?

E se eu te dissesse que você pode fazer o tamanho das suas fontes variar SEM USAR MEDIA QUERIES???

Pois fique de olho, que em breve sai um artigo falando sobre como implementar a técnica de tipografia fluida.

Dicas para criar projetos front-end melhores e mais rápido - Parte 2

Caio Marcellus Cabral — Mon, 12 Jun 2023 16:48:31 +0000

Essa é a segunda parte do artigo. Não deixe de ler a anterior aqui. Vou te dar uns minutinhos pra ir lá e voltar.

Pronto! E aí, gostou? Então vamos ver mais algumas dicas para a criação de projetos de front!

2) HTML

Ufa, planejamos bastante, temos uma boa noção dos estágios que vamos seguir com o desenvolvimento da nossa aplicação, e se você seguiu tudo certinho até aqui já temos até algum CSS escrito.

O próximo passo que costumo dar é construir todo o HTML de uma página sem me preocupar com a estilização. É isso mesmo que você leu: antes de colocar cor, mudar fonte, fazer coisinhas bonitas e animações, eu crio o esqueleto da página toda.

Aqui eu me preocupo basicamente com a semântica do HTML, ou seja, em usar as tags HTML que mais fazem sentido de acordo com o conteúdo.

Fazendo dessa forma eu sinto que consigo me concentrar primeiro em escrever um bom HTML sem me preocupar com estilização, o que aumenta minha chance de manter coerência interna nas decisões que tomar.

Importante dizer que nesse momento já entram as tags img, mas eu não adiciono a src delas.

Faço isso porque as imagens por padrão, sem nenhum CSS, tendem a ficar do tamanho do arquivo original delas, o que faz uma bagunça danada na nossa tela.

3) CSS

Finalmente chegou a hora do nosso site deixar de parecer um grande documento do Word!

a) Aplicando os componentes

Lembra que criamos classes utilitárias e componentes? Esse é um bom momento para aplicá-las na página toda.

Como um desses componentes era o container, isso já deixa o nosso grid do site no lugar, e evita que a gente estrague o alinhamento por descuido.

Além disso, vamos ver todas as fontes configuradas, talvez um botão já tomando forma aqui e ali.

O coração fica até quentinho.

b) Avançando um passo de cada vez

Minha abordagem, como já adiantei, é utilizar o paradigma mobile-first. O que eu fazia no começo: montava uma página inteira para celular e depois ia adaptando ela para telas maiores.

E o que acontecia: o Caio do Futuro se deparava com um código escrito pelo Caio do Passado, e nem sempre entendia muito bem: "como você fez essa seção daqui? Qual a lógica por trás desse calc, Caio do Passado? O que a classe T60 quer dizer?????".

Escrever códigos bem organizados é uma forma de mitigar esse problema. Lembre-se: um código bem escrito é um agrado para outros devs, mas também é um carinho no seu Eu do Futuro.

Mas além de escrever um código bem organizado e documentado, existe outra forma de reduzir esse problema: reduzindo a distância temporal entre o seu Eu do Passado e seu eu do Futuro.

E não, eu ainda não estou falando de viagem no tempo!

Qual é o pulo do gato aqui: eu não faço a estilização do site inteiro no mobile, para depois adaptar para desktop. Eu gosto de fazer a estilização do site seção por seção.

Sempre sigo a ordem das seções, então começo pelo header, por exemplo. Faço o header para celulares. Quando está tudo certo, antes de ir para a próxima seção, faço a responsividade do header para telas maiores, e testo aquela seção da largura de tela mínima até a máxima, para me certificar que todas as fotografia do meu filme estão funcionando.

Assim, tudo que fiz está mais fresco na memória, e fica muito mais fácil adaptar.

Além disso, eu garanto que só passo de uma seção para outra quando não tem nenhum bug na anterior. Assim, quando algum problema surge, provavelmente tem a ver com a seção na qual estou trabalhando naquele momento, em vez de ter que caçar na página toda o que ocasionou aquele overflow que atormenta a gente!

c) Padronize as suas propriedades CSS

Você provavelmente já teve que voltar em um código que escreveu e teve dificuldade em encontrar alguma informação que queria, ou entender o que estava acontecendo ali, né?

Isso acontece por conta da organização do código.

Por mais que a ordem das propriedades do CSS não faça diferença para o computador, nós não escrevemos o nosso código para máquinas, mas para outros desenvolvedores. E seres humanos gostam de padrões, lembra?

Quando estamos começando, nosso CSS sai na ordem em que escrevemos. Conforme a gente precisa, ou lembra de uma propriedade, a gente coloca no código, e elas ficam lá na ordem em que escrevemos.

Fica algo mais ou menos assim:

.card{
top: 20%;
width: 350px;
display: flex;
border: 1px solid red;
padding: 30px 20px;
position: absolute;
flex-direction: column;
justify-content: center;
width: 300px;
height: 250px;
left: 50%;
transform: translateX(-50%);
}

Esse código todo funciona, mas ele traz dois problemas: ele é um pouco complicado de ler, e ele permite que erros bobos aconteçam, como a redeclaração da propriedade width (você tinha percebido?).

Por isso é importante que a gente siga alguma padrão na hora de fazer o nosso CSS.

Muitas pessoas usam o padrão alfabético. Eu gosto de seguir um padrão que divide em propriedades de display, posicionamento, box-model, tipografia e depois uma miscelânea. Vou falar sobre isso em outro artigo, mas o mais importante é: escolha um padrão e seja coerente. Isso vai tornar seu projeto mais fácil de ler, de fazer manutenção, e evita declaração redundante de propriedades.

Crie um padrão, documente e siga em frente. Na dúvida, coloque em ordem alfabética.

Como ficaria nossa classe card em ordem alfabética:

.card{
border: 1px solid red;
display: flex;
flex-direction: column;
height: 250px;
justify-content: center;
left: 50%;
padding: 30px 20px;
position: absolute;
top: 20%;
transform: translateX(-50%);
width: 300px;

Aqui resolvemos o risco de declarar duas vezes a mesma propriedade, já que ao colocar em ordem alfabética ficaria gritante que temos duas propriedades repetidas, mas eu ainda acho que o código fica confuso de ler.

Como eu faria no meu dia-a-dia:

.card{
display: flex;
flex-direction: column;
justify-content: center;

position: absolute;
top: 20%;
left: 50%;
transform: translateX(-50%);

height: 250px;
width: 300px;
padding: 30px 20px;
border: 1px solid red;

Dessa maneira, as propriedades afins estão agrupadas, e eu consigo saber como elas trabalham em conjunto para atingir o leiaute desejado.

d) Evite usar código inútil

Essa parece óbvia, mas não é: é muito importante, até mesmo para que você atinja o domínio das linguagens com que for trabalhar, que mantenha apenas códigos que você realmente quer usar, que sabe o que estão fazendo naquela situação.

É muito comum ver códigos com várias propriedades CSS que não tem nenhuma função.

Uma div com todas as técnicas para centralizar um elemento aplicado nela, por exemplo. Dá pra ver a história por trás daquilo: o desenvolvedor back-end colocou uma propriedade, não funcionou; Colocou outra, não funcionou. No fim temos 10 declarações diferentes, e a div continua torta. (Esse relato é uma obra de ficção, qualquer semelhança com a realidade é mera coincidência. Beijo pra galera do back <3).

Ao usar somente propriedades CSS que tenham utilidade no seu projeto, seu código fica mais legível, e você fortalece seu conhecimento das ferramentas que usa.

Dica: use e abuse do DevTools. Você pode marcar e desmarcar as propriedades para ver o que acontece, e ele até mostra que propriedades estão declaradas, mas não estão sendo usadas.

e) Como nomear as suas classes?

Para finalizar o tópico do CSS, o temido momento: como vamos nomear as nossas classes?

A resposta é bem simples: tanto faz, mas seja coerente.

Existem diversas metodologias, e isso pode variar de equipe para equipe quando trabalhamos com outros devs. O importante é experimentar, e encontrar uma que faça sentido para você. A metodologia BEM é muito utilizada, e é um ótimo lugar para começar.

Eu, particularmente, uso uma adaptação dela, mas só nomeio novas classes quando estritamente necessário. Se posso resolver algo com seletores do CSS, eu não crio uma classe nova. Todas as seções do site têm uma classe específica (ou compartilhada, se forem seções-gêmeas), e a partir daí vou selecionando os elementos filhos com seletores CSS.

Uso as classes apenas quando há possível ambiguidade, como no exemplo abaixo.

header nav > ul{
   display: flex;
   justify-content: space-between;
   align-items: center;
}

header ul.menu-options{   
   position: absolute;
   top: 0;
   right: 0;

   padding: var(--fs-1);
   background-color: var(--colorMain);

   transform: translateY(-100%);
   transition: top 1s ease-in, transform 1s ease-in;
}

Nesse caso eu criei uma classe específica pois havia duas uls no meu header.

Esse código foi retirado do projeto criado durante o Challenge Front-End da Alura que aconteceu em março de 2023. Você pode conferir o projeto completo aqui.

f) Organização de arquivos e pastas

Por fim, tenha sempre seu CSS bem organizado. Eu costumo dividir ele em arquivos diferentes para cada seção, além de ter um arquivo para a estilização geral (guia de estilo, variáveis, componentes, classes utilitárias). Há quem goste de ter um arquivo separado para as media queries, mas eu prefiro que em cada arquivo eu tenha as media queries relevantes para aquela seção.

4) Bônus

Queria falar de alguns princípios que costumo seguir quando estou escrevendo código:

a) Legibilidade é mais importante que brevidade

Muitas vezes vejo pessoas felizes da vida porque conseguem juntar a declaração de várias propriedades CSS em uma única propriedade. ‘font’ por exemplo substitui outras SETE propriedades.

Usar esse artifício torna seu código mais curto, mas será que torna ele mais legível?

Sempre que me deparo com uma dessas escolhas, esse é o primeiro princípio que me vem à mente: é mais importante ter um código legível, organizado e intuitivo do que deixar de escrever algumas linhas de código para no futuro ter dificuldade de fazer manutenção no código.

Isso não quer dizer que está liberado o Ctrl + C; Ctrl + V!

“Ah, o Caio falou que legibilidade é tudo e brevidade não importa. Vou fazer um código gigantesco e redundante e vou dormir feliz”.

Intepretação de texto freestyle não se cria aqui, não. Por isso, vamos para o próximo tópico.

b) DRY (Don’t repeat yourself/Não se repita)

Sempre que no nosso código estamos copiando e colando alguma estrutura, é sinal de que poderíamos abstrair aquela estrutura para evitar a repetição.

Essa abstração pode ser na forma de uma classe ou Custom Property do CSS, ou mesmo uma variável ou função no JavaScript, depende do ambiente em que estamos.

Nesse artigo já apliquei o DRY sem nomeá-lo: quando criamos nossas classes de componentes, estávamos abstraindo propriedades CSS para uma classe, a fim de não termos que repetir aquelas propriedades várias vezes.

c) Intencionalidade e Coerência

Aqui a coisa fica meio abstrata, mas talvez seja o ponto mais importante: tenha uma razão por trás de suas escolhas, e não mude essa racionalidade no meio de um projeto.

Digamos que você está fazendo um site, e dentro de uma seção você tem três informações: título, texto e uma foto, um embaixo do outro. No figma, todos eles têm o mesmo espaçamento inferior: 24px.

Você pode construir essa tela assim. Você pode abrir em outra tela para ver melhor:

Mas isso, por mais que funcione agora na sua tela, pode trazer alguns problemas.

Como escolhemos o tamanho da fonte do h1 utilizando px e do p utilizando rem, caso haja a mudança da fonte padrão do browser a relação entre as nossas fontes vai mudar.

Pior que isso: se essa relação entre fontes mudar, como escolhemos as margin-bottom de cada um utilizando também padrões diferentes, o espaçamento inferior entre eles também vai ser prejudicado.

Podemos consertar esse problema assim:

O segundo código muda pouca coisa, mas muda tudo: nele escolhemos as nossas medidas com a intenção de manter o tamanho da fonte adaptável para os diferentes padrões de fonte que nossos usuários podem ter.

E usamos a mesma racionalidade para o h1 e para o p, sendo coerentes com a nossa escolha inicial.

Isso não significa ser obrigado a usar a mesma unidade sempre, mas, sim, usar sempre a mesma linha de raciocínio.

Talvez a gente possa resumir isso em dois princípios:

não use unidades diferentes para o mesmo objetivo;
não use técnicas diferentes para fazer a mesma coisa;

d) Não use números mágicos

Quem nunca foi posicionar um elemento na tela e usou aquele número super preciso, que funciona perfeitamente, mas... de onde ele veio mesmo?

“Tentativa e erro, Caio. Deixa eu ser feliz!”.

Claro, claro. Mas eu estou aqui para te poupar de dores muito maiores, jovem gafanhoto.

Para exemplificar isso, me inspirei na Natália e fiz o começo de um desenho com CSS.

Na minha tela, essa posição para os olhos está funcionando perfeitamente. 58px! O que poderia dar errado?

Err... será que em outras telas funciona também?

Convido você a brincar de arrastar o tamanho da tela para ver que só em uma largura de tela específica que os olhos ficam no lugar desejado.

Lembre-se, temos sempre que pensar no filme, não na foto.

Conclusão

Esses são alguns dos princípios e técnicas que sigo ao criar projetos Front-end.

Planejando, tendo organização, coerência e tendo domínio do código que produzimos conseguimos criar projetos mais robustos.

Espero que você tenha gostado das dicas. Me conta aqui nos comentários algo que você faz e que eu não comentei. Me conta também sobre qual das dicas você nunca tinha parado para pensar.

Aproveito para agradecer à leitura atenta e às contribuições da Ângela e da Moni, que além de terem dado pitacos valiosos no texto, são inspirações para mim.

Dicas para criar projetos front-end melhores e mais rápido - Parte 1

Caio Marcellus Cabral — Mon, 05 Jun 2023 16:17:28 +0000

Quando estamos aprendendo a programar a gente se acostuma a seguir tutoriais. O instrutor faz, a gente segue tin tin por tin tin, a coisa (quase sempre) funciona, o mundo é lindo e os passarinhos cantam.

Aí a gente vai fazer nosso primeiro projeto por conta própria (ou segundo, ou terceiro...) e bate aquela sensação... E agora? O que eu faço? Por onde começo?

Eu passei por essa situação bem mais de três vezes, cara leitora/caro leitor. Com o tempo, fui reunindo alguns hábitos e práticas que me ajudam a ter maior controle e eficiência nos projetos em que trabalho. Reuni neste artigo algumas dessas dicas/conselhos que vão aumentar sua produtividade, a qualidade do seu código, além de te ajudar a ter mais segurança na hora de começar novos projetos.

É bom logo tirar uma coisa do nosso caminho: não existe maneira certa de fazer esse tipo de coisa, apenas maneiras não-erradas. Essas práticas me ajudam, e pode ser que algumas dessas coisas não funcionem para você. Ficarei feliz em ler todos os feedbacks e experiências, o campo de comentários está aberto. Educados comentam.

1) Planejamento

A primeira coisa a se fazer para escrever um bom código é: não abra o seu editor de código favorito agora.

É isso mesmo que você leu. Deixa para abrir o VS Code daqui a pouco.

A gente começa planejando. E para isso vamos abrir o leiaute que vamos construir.

Com sorte, você recebeu um arquivo de referência criado por uma/um designer. Com mais sorte ainda, a/o designer teve tempo de ser meticulosa/o e todos os elementos do leiaute seguem uma lógica: os espaçamentos, respiros, tamanhos de fontes, tudo tem alguma coerência interna.

Mas no mundo real estamos todos trabalhando com prazos apertados, e algumas coisas podem passar batidas. É nosso trabalho interpretar aquele arquivo, entender qual era a intenção de quem criou, perguntar quando houver dúvidas e sugerir alterações.

Com o leiaute aberto, você vai prestar atenção nos seguintes pontos:

a) Existe um guia de estilo?

Aqui é a hora de construir o nosso guia de estilos no CSS. Vamos olhar para o leiaute e nos perguntar: Quais são as cores utilizadas? Quais são as fontes utilizadas (família, tamanho, peso)?

Eu costumo fazer isso criando propriedades personalizadas no CSS (CSS Custom Properties), que muitas vezes chamamos de variáveis CSS.

Nas Custom Properties eu defino todas as cores do projeto, font-family, font-weight e font-size. Assim, alguns tipos de mudanças podem ser feitas no guia de estilo do projeto, sem precisar acessar cada ocorrência daquela propriedade.

O resultado fica algo mais ou menos assim:

:root{
--color-main: #FF0000;
--color-secondary: #00FF00;

--ff-arial: 'Arial', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 32px
}

Não reparem na escolha de fontes e cores. O que quero demonstrar aqui é que nosso guia de estilos vai estar definido nessas variáveis e pode ser acessado e modificado com facilidade, pois a fonte daquela informação está em apenas um lugar.

Um exemplo do que poderia acontecer: digamos que a empresa foi comprada por outra, que reformula a identidade visual, mudando as cores da marca. Em vez de correr atrás de todas as ocorrências de cores, podemos apenas alterar no nosso guia de estilos:

:root{
--color-main: #FFFF00;
--color-secondary: #00FFFF;

--ff-arial: 'Arial', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 32px
}

Assim as mudanças serão replicadas onde quer que eu tenha colocado as Custom Properties "color-main" e "color-secondary".

b) Qual o alinhamento? Existe uma linha de grade?

O alinhamento é um dos principais responsáveis por orientar a leitura do usuário. Alinhamento é aquela linha invisível que passa pelas extremidades do conteúdo do site. A ponta esquerda do conteúdo do seu header é uma das linhas de grade do seu site. Um site com alinhamento coerente e intuitivo melhora muito a experiência do usuário. Por isso é importante que você tenha clareza no início do projeto quantas larguras diferentes de seção vai haver no site.

Aqui temos um exemplo de um site desalinhado. Criei as bordas laterais para que a gente possa ver como não existe padrão nenhum no alinhamento.

Olha só como fica bem melhor com um alinhamento feito com mais cuidado:

Quando estamos começando, fazemos o alinhamento caso a caso, seção a seção. O que acaba acontecendo: seguimos critérios diferentes a cada vez que fazemos. Uma hora definimos a width da seção com px, depois com %, mais na frente fazemos usando padding. Isso faz com que a gente não tenha clareza de qual é o tamanho que cada tipo de seção do site deve ter. E se isso não está claro na sua cabeça enquanto você está programando, isso não vai estar claro no seu código, nem vai estar claro na tela.

Para fazer esse trabalho a gente usa os containers. A gente ouve essa palavra, vê em códigos de cursos, mas muitas vezes não paramos para pensar qual a finalidade desse tal de container.

O papel de um container é... conter um determinado conteúdo.

Tá, tá, vou dar uma definição menos óbvia.

O container é responsável por definir a largura máxima dos elementos que estão dentro dele. Se temos dois conteúdos distintos com a mesma largura e alinhados ao centro, podemos ter (quase) certeza que esses conteúdos estão alinhados. Digo 'quase' porque podemos quebrar esse alinhamento colocando padding no container, por exemplo, estragando o alinhamento que o container estava tentando criar.

Há duas técnicas para a criação de um container. Uma usa width e a outra usa padding lateral. Elas tem suas vantagens e desvantagens e vou explorar isso mais a fundo em um artigo em breve.

“Tá, Caio, mas e se eu tiver várias larguras diferentes?”

Pode ser o caso de você conversar com o designer para entender melhor as linhas de grade do projeto. Pode ser que determinada seção possa aumentar um pouco, outra possa diminuir e vocês consigam uniformizar um pouco as linhas de grade.

Nos seus projetos pessoais, comece usando um tamanho só de container. Depois aumente para dois. Isso vai te dar uma clareza maior, e treinar seu olhar para identificar conteúdos desalinhados.

Naquele exemplo do caio-chella - projeto criado durante o Challenge Front-End da Alura que aconteceu em março de 2023) - eu estruturei da seguinte maneira:

:root{
--container-width: 86.5%;
}

.container{
   width: var(--container-width);
   margin-inline: auto;
}

Dessa forma eu estabeleci uma mesma largura para todos os meus containers, e na classe container eu aplico essa largura, além de alinhar ao centro com a propriedade margin-inline.

Se quiser conferir o projeto, dá um pulo no meu github: https://github.com/marcelluscaio/Codechella_AluraChallenge/tree/main

c) Há elementos gráficos repetidos?

O cérebro humano evoluiu para reconhecer padrões. E que sensação gostosa quando nós identificamos um! Essa sensação boa que a familiaridade traz está chumbada no nosso cérebro. Isso se reflete no design de sites.

Seria muito estranho que um botão na primeira seção do site fosse retangular e azul e outro no final fosse redondo e rosa, não é? Por isso, normalmente o design de um site costuma ter elementos semelhantes.

Esses elementos semelhantes terão a estilização semelhante no CSS. Agora é a melhor hora para identificar esses elementos e criar componentes e classes utilitárias. Para isso, a gente vai criar classes no CSS que reúnem todas as características comuns daquele componente.

A distinção que faço aqui entre componentes e classes utilitárias é meramente teórica, e tem a ver com o tipo de propriedade que as classes manipulam. Se está lidando apenas com elementos da tipografia, por exemplo, entendo que estamos diante de uma classe utilitária (como no exemplo de fontes que irei dar mais adiante). Se estamos lidando com mais de uma característica do elemento, entendo que estamos diante de um componente (como no caso do container ali em cima, e do botão que vou mostrar logo adiante).

Essa distinção é menos importante que a lógica por trás dela, não se apegue muito a isso.

Digamos que você viu que os botões do seu site todos tem fundo vermelho e cor do texto verde. O que você faz?

Demite seu designer!

Brincadeira! Ao percebermos esse padrão, podemos criar uma classe que vai reunir essas características:

:root{
--color-main: #ff0000;
--color-secondary: #00ff00;

}

.button{
background-color: var(--color-main);

color: var(--color-secondary)
}

Você pode observar ainda outras características em comum aos botões, como padding, border-radius e text-align, por exemplo.

Outro elemento de um site que costuma ter um alto grau de padronização é a tipografia.

Vale a pena dedicar um tempo para anotar todos os tamanhos de fonte, famílias, peso e altura da linha para compreender o padrão do site. Fazendo isso, podemos chegar ao seguinte resultado:

:root{
--ff-calistoga: 'Calistoga', cursive;
--ff-raleway: 'Raleway', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 24px;
--fs-3: 48px;

}

.title{
font-family: var(--ff-raleway);
font-weight: var(--fw-2);
font-size: var(--fs-3);
line-height: 1.2;
}

.title--small{
font-size: var(--fs-2)
}

.text{
font-family: var(--ff-calistoga);
font-weight: var(--fw-1);
font-size: var(--fs-1);
line-height: 1.5;
}

.text--bold{
font-weight: var(--fw-2);
}

E aí no seu HTML você pode fazer algo do tipo:

<h1 class="title">Título</h1>
<h2 class="title title--small">Título menor</h2>
<p class="text">Texto</p>
<p class="text text--bold">Texto em negrito</p>

d) Qual foi a largura de tela utilizada no leiaute?

Muitas vezes nós olhamos o leiaute e tentamos replicar ele na nossa tela: “O designer colocou 30px de padding lateral na página? Vou colocar o mesmo aqui na minha página e vai ficar igualzinho”.

Eis que você chega num ponto em que não consegue reproduzir fielmente o que vê no leiaute. “Mas eu coloquei exatamente as mesmas medidas que estavam lá! Viu, Caio, por isso que eu não gosto de front!”.

Eu entendo a sua revolta, mas eu posso te ajudar a nunca mais ter esse problema. A questão aqui é simples: o leiaute é apenas uma fotografia da nossa aplicação.

Essa foto é como um mapa que vamos seguir, e ali estão representados alguns momentos-chave da nossa aplicação – no geral a versão mobile e desktop (se você tem mais do que isso você é privilegiado SIM).

O desenvolvimento do site é um filme, a junção de todas essas fotografias/cenas.

Cada cena é uma largura de tela, e devemos pensar como toda a movimentação dos atores - nossos componentes/elementos em tela - está acontecendo. Algo pode sair muito bem na foto aos 1700px, mas quando chega aos 1300px alguma coisa pode quebrar, ficar fora de quadro.

Um grande salto na mentalidade de um bom desenvolvedor é parar de olhar a foto (“funciona na minha tela!”) e passar a se preocupar com o filme (“Como será que isso vai se comportar quando a tela for menor/maior que a minha? Qual é a experiência do usuário do produto que estou criando?”).

Então, quando olhamos para o leiaute é essencial pensar qual momento do nosso site aquele leiaute está retratando. Se olharmos para um leiaute construído em 1700px e começarmos a construir o nosso site na nossa tela de 1300px vamos criar distorções involuntariamente.

Lembre-se, o dev tools é o seu melhor amigo.

e) Mobile-first ou Desktop-first?

Outro ponto para considerar é: qual paradigma adotar no projeto, mobile-first ou desktop-first? Caso você não saiba do que estou falando, esses são dois paradigmas que definem como vamos começar o nosso projeto: “mobile-first” (celular primeiro) desenvolve primeiro a versão mobile e “desktop-first” (computador primeiro) começa pela versão desktop.

É bom você se acostumar com esses conceitos. =)

Mas afinal, por onde começar, pelo desenvolvimento para celulares ou para desktop?

Se alguma vozinha aí dentro da sua cabeça já está tipo a Hermione, afoita para responder, gritando “DEPENDE! DEPENDE!” você está no caminho para se tornar sênior! 500 pontos para a grifinória!

Na minha experiência, começar pelo desenvolvimento para celulares facilita muito o trabalho, mas não quero me aprofundar nesse tema aqui, senão a gente se perde do assunto principal. A escolha entre os dois paradigmas é livre, mas deve ser consciente. E ela é importante porque isso vai afetar como você declara as suas media queries.

Se você começa desenvolvendo para uma tela de 370px, por exemplo, quando for adaptar para telas maiores, digamos 1200px, vai usar min-width 1200px.

Se, por outro lado, começou desenvolvendo para 1653px, quando for fazer a versão tablet vai precisar declarar a media query com max-width 768px, por exemplo.

Manter suas media queries em ordem é muito importante para não surtar na hora de caçar bugs.

Conclusão

Seguindo todos esses passos do planejamento nossos projetos ficam muito melhor organizados, e a gente passa a ter muito mais controle sobre o que está acontecendo na tela.

Mas a gente mal começou a escrever código. Semana que vem eu trago mais dicas para tornar o seu projeto ainda mais robusto.

Me conta aqui nos comentários: qual dica você mais gostou, e de qual sentiu falta?

Quem tem medo do nth-child?

Caio Marcellus Cabral — Mon, 03 Apr 2023 16:34:53 +0000

Digamos que você precisa dar manutenção em um código na empresa em que você trabalha, e se depara com isso daqui no CSS:

li:nth-child(n + 2):nth-child(-n + 9):nth-child(4n + 2)

Talvez a sua primeira reação seja essa daqui:

Palma, palma, não priemos cânico! Pega um café e vamos destrinchar passo a passo de como esse megazord funciona. Depois de ler esse artigo você vai entender e apreciar essa ferramenta poderosa que é a pseudo-classe :nth-child(). Ficou na dúvida do que é uma pseudo-classe? Dá uma olhada no artigo da @sucodelarangela que está lá nas referências. Mas, em linhas gerais, é só lembrar da partícula “pseudo” que a gente viu na escola (pseudociências, pseudofrutos), que significava aquilo que parece ser, mas não é. As pseudo-classes são seletores do CSS que ajudam a mirar em certos elementos sem necessidade de criar uma classe específica para eles.

Vamos estudar alguns casos?

1 – Usando :nth-child() com um número absoluto

Aqui a coisa é bem intuitiva: você seleciona o elemento que é o enésimo filho dentro de outro.

Enésimo????

Tá, talvez fique mais fácil com exemplos, né? É o seguinte: se você colocar :nth-child(1), vai selecionar o primeiro elemento, :nth-child(2), o segundo, e assim por diante.

No exemplo abaixo eu usei o seletor

.filho:nth-child(3)

para pintar o terceiro quadrado de verde.

O que está acontecendo aqui: estamos selecionando o elemento com classe "filho" que também seja o terceiro filho de outro elemento. E isso é muito importante, como vamos ver a seguir.

Um erro muito comum é pensar “Eu quero o terceiro elemento com a classe ‘filho’” e usar o nth-child. Veja o exemplo abaixo:

No primeiro cenário, estamos tentando mirar no elemento com classe filho que seja o terceiro filho de algum elemento. Acontece que nesse caso, o terceiro filho é uma tag p sem a classe “filho”. Então o CSS não encontra ninguém para pintar de verde.

No segundo cenário, corrigimos usando nth-child(4), mas a correção vai depender de qual o nosso objetivo (poderia ser aplicar ‘.pai > :nth-child(3)’, ou mesmo ‘:nth-of-type(3)’, atingindo resultados diferentes).

Aí você que leu até aqui pensa “Que moleza! Já entendi, nem vou ler o resto” e corre pro seu projeto querendo estilizar aquela lista de links. Com a segurança de quem sabe que CSS se aprende em 30 minutos, você digita:

.lista__item__link:nth-child(3){ color: red;  }

Ao ver que não funcionou, com lágrimas nos olhos, você corre para o twitter e lança a hashtag #ocaiomentiupramim.

Mas calma lá. Vamos entender o que aconteceu aqui hipotética pessoa apressada.

Sua lista de links tem mais ou menos essa cara aqui:

O que acontece é que você estava dizendo pro CSS: “Corre lá, e busca o 'lista__item__link' que seja o terceiro filho de alguém”. O CSS foi e só encontrou “lista__item__link” que era o primeiro filho do “lista__item”. Ele ficou bem confuso, e com um balde de tinta vermelha inutilizado.

Agora você já entendeu e já sabe como consertar: é só mirar no terceiro “lista__item”, e depois selecionar o filho dele.

.lista__item:nth-child(3) > .lista__item__link{
  color: red;  
}

Até agora os exemplos que vimos não parecem tão úteis. Como estamos mirando em apenas um elemento, todas as vezes seria possível utilizar classes sem prejuízo da manutenibilidade do código. E se precisássemos aplicar uma ação nos elementos múltiplos de 3? Você precisaria aplicar várias vezes aquela classe no HTML. Daria para usar nth-child(3), nth-child-(6), nth-child-(9), nth-child(12), mas e se você não soubesse de antemão quantos elementos vão estar naquela lista?

É aí que o nth-child começa a brilhar.

2 – Usando múltiplos

Quando usamos o ‘n’ do nth-child, é como se substituíssemos esse ‘n’ por cada posição dos elementos filhos. Uma ul que tenha 6 li’s, e na qual colocássemos o seletor “li:nth-child(2n)” faria por trás dos panos algo assim:

li:nth-child(2 * 1), logo li:nth-child(2);
li:nth-child(2 * 2), logo li:nth-child(4);
li:nth-child(2 * 3) , logo li:nth-child(6);
...
li:nth-child(2 * 6) , logo li:nth-child(12);

Então ele iria selecionar o 2º, 4º e 6º elementos.

Digamos que a gente precise pintar todo o terceiro quadrado de uma lista de 20 quadrados de verde. Agora a gente já consegue fazer isso bem fácil:

Agora, e se a gente precisasse fazer isso, só que começando do primeiro? No caso, pintar o primeiro e depois ir pulando de três em três (4º, 7º, etc)?

3 – Adicionando deslocamento

Bem , nós já sabemos fazer a seleção do 3º, 6º, 9º... certo?

Agora compare essas duas seleções:

0º, 3º, 6º, 9º...
1º, 4º, 7º, 10º...

A diferença entre elas é que na segunda, em vez de começarmos do zero, começamos do número 1

Para fazermos isso com nth-child basta a gente somar o deslocamento que a gente quer ao múltiplo de 'n'. Nesse caso, nth-child(3n + 1).

Na dúvida, substitua o n pelo número de elementos, em sequência, começando do zero.

nth-child(3n + 1) =>
nth-child(3 * 0 + 1), logo nth-child(1);
nth-child(3 * 1 + 1), logo nth-child(4);
nth-child(3 * 2 + 1), logo nth-child(7);
...
nth-child(3 * 20 + 1), logo nth-child(61);

Isso também pode ser usado para mirar em todos os elementos menos alguns do início. Digamos que a gente quer pintar todos os quadrados de verde, menos os três primeiros.

Se usássemos “nth-child(n)” estaríamos dizendo para selecionar todos os elementos. Se somássemos 1, o resultado seria... o mesmo!

Aqui temos que entender o pulo do gato do nth-child: a contagem dele começa do 0. Então, quando somamos 1, não vamos ver diferença no resultado. Temos sempre que pensar um número à frente para compensar esse primeiro “n-fantasma”.

É só fazer aquela substituição marota:
nth-child(n + 1) =>
nth-child(0 + 1), logo nth-child(1);
nth-child(1 + 1), logo nth-child(2);
nth-child(2 + 1), logo nth-child(3);
...
nth-child(20 + 1), logo nth-child(21);

Com isso, podemos concluir que para pular os três primeiros elementos, temos que somar 4, usando nth-child(n + 4). Podemos ainda pensar da seguinte forma: usando nth-child(n + 4) estamos selecionando do 4º elemento em diante,

Um outro pulo do gato do nth-child: a contagem do 'n' na verdade não para na quantidade de elementos da lista. Por isso um seletor como nth-child(n - 5), que poderia servir para selecionar todos os itens, menos os cinco últimos não funciona. Esse seletor vai selecionar TODOS os elementos. Mas a gente consegue contornar isso.

4 –Olhando só para os primeiros

No tópico anterior, aprendemos a olhar para todos menos para os primeiros com a notação nth-child(n + X). Podemos fazer o inverso disso, e mirar somente nos primeiros X elementos e não no resto.
Para isso, usamos “-n”. Não se assuste, é tão fácil quanto os outros!

Quando declaramos nth-child(-n), não vamos ver nada acontecendo. Isso porque por trás dos panos o CSS vai fazer numa lista, por exemplo, de 6 itens:

nth-child(-n) =>
nth-child(-1 * 0), logo nth-child(0);
nth-child(-1 * 1), logo nth-child(-1);
nth-child(-1 * 2), logo nth-child(-1);
...
nth-child(-1 * 6), logo nth-child(-6);
...

Como não temos elementos negativo no nth-child, nenhum será selecionado.

Mas se somarmos ao “-n” uma quantidade X, podemos selecionar quantos elementos do início da lista nós quisermos!

nth-child(-n + 3) =>
nth-child(-1 * 0 + 3), logo nth-child(3);
nth-child(-1 * 1 + 3), logo nth-child(2);
nth-child(-1 * 2 + 3), logo nth-child(1);
...
nth-child(-1 * 6 + 3), logo nth-child(-3);
...

Note que nesse caso nós vamos selecionar os três primeiros elementos. Logo, podemos pensar que o seletor nth-child(-n + 3) está dizendo “selecionar todos, mas só até o terceiro elemento”.

Veja ainda o exemplo abaixo:

5 –Montando nosso Megazord

Agora estamos prontos para montar o nosso nth-child monstrão!

Digamos que a gente queira selecionar a partir do sétimo quadrado, e parar no décimo-quinto.

Para fazer isso a gente pode encadear seletores nth-child!

.container__square:nth-child(n + 7):nth-child(-n + 15){
  background-color: green;
}

Assim, estamos falando pro CSS: “Vai lá, e pinta de verde todos os quadrados a partir do sétimo, mas não vá além do décimo quinto”.

E se agora nós quiséssemos fazer a mesma coisa, mas pulando um?

.container__square:nth-child(n + 7):nth-child(-n + 15):nth-child(2n + 1){
  background-color: green;
}

Conseguimos!

Aquele emaranhado que parecia indecifrável agora parece bem mais simpático, não é?

Utilizando nth-child nos seus projetos você consegue criar seletores complexos sem poluir seu código com classes muito específicas, que tornariam difícil a inserção de novos elementos em uma lista, por exemplo.

Parabéns por ter mais uma ferramenta no seu cinto de utilidades.

Referências:

:nth-child
https://css-tricks.com/almanac/selectors/n/nth-child/

:nth-child()
https://developer.mozilla.org/en-US/docs/Web/CSS/:nth-child

How does CSS nth-child() really work?
https://www.youtube.com/watch?v=KIIktcWu6hc&ab_channel=WesBos

Entendendo CSS: Pseudo-Classes e Pseudo-Elementos
https://dev.to/sucodelarangela/entendendo-css-pseudo-classes-e-pseudo-elementos-b83

Mais 5 atalhos do VS Code que você precisa conhecer

Caio Marcellus Cabral — Fri, 17 Feb 2023 20:23:14 +0000

No último post eu falei sobre alguns atalhos do VS Code que eu uso sempre. Como toda boa lista, ela teve ausências notáveis, ausências que vocês me ajudaram a compilar e a trazer nesse segundo post. Vamos lá!

Duplicando código

Essa daqui foi uma que aprendi com vocês e não consigo parar de usar! Digamos que você vai fazer um card, e dentro dele tem 8 filhos. Uma forma de otimizar esse trabalho seria fazendo o primeiro e copiando ele 7 vezes. Todos os cards iguais, com a mesma estrutura, sem margem para erros.

Dar Ctrl + C, Ctrl + V é a primeira solução que a gente pensa, mas e se eu te disser que tem uma forma ainda mais fácil de resolver isso?

Alt + Shift + ↑
Alt + Shift + ↓

Usando esse comando você copia uma bloco de código para cima ou para baixo, a depender da seta que apertou. Então para fazer o card, você só precisaria segurar o Alt + Shift e apertar a seta para baixo 7 vezes.

Corrigindo e refatorando código

Eis que você está revisando seu código e viu que precisava mudar o nome de uma classe. O que era “cartaozinho” vai virar “client-card”. Só que no seu HTML tem 10 elementos com essa classe. E o pior, como você é adepto da convenção BEM, dentro desses elementos tem diversas classes “cartaozinho_titulo”, “cartaozinho_numero”. E ainda têm todos os seletores no CSS... Desesperador, né?

Não! Afinal você já leu este artigo, e você sabe como resolver sem ter que passar um pente fino à olho no código todo!

Ctrl + F

Apertando esse comando você abre uma aba de pesquisa como essa:

Agora é só você colocar que vai substituir cartaozinho por client-card, e o VS Code substitui um a um, ou todas as ocorrências.

Para substituir caso a caso, aperte Enter. Se você tem confiança que não vai quebrar nada no código (ou se você é vidaloka #YOLO) você pode mudar todos de uma vez apertando Ctrl + Alt + Enter.

Salvando

Essa daqui é bem simples, mas vai que alguém não conhece, né? Para salvar o seu código sem ter que clicar em File > Save, você pode apertar Ctrl + S. Eu confesso que faço isso de forma quase obsessiva a cada alteração no código rs.

Indentando código

Indentar bem o código é fundamental para um código legível, e um código legível é o que diferencia um bom programador de um ótimo programador que está preparado para trabalhar em equipe.

Para adicionar indentação ao código, selecione a seção e aperte Tab. Exagerou? Aperte Shift + Tab.

Simples, mas essencial.

Abrindo o terminal

Não adianta fugir, você vai usar o terminal. Seja para instalar frameworks, bibliotecas ou para subir seu código para o GitHub. O VS Code ajuda bastante nessas tarefas com seu terminal integrado.
Uma maneira de abrir ele é clicar em Terminal > New. Mas você pode fazer isso com uma só mão apertando Ctrl + J.

Me conta, o que mais ficou faltando?

Bons códigos!

3 atalhos do VS Code que você precisa conhecer (+ 1 bônus)

Caio Marcellus Cabral — Wed, 18 Jan 2023 23:24:27 +0000

Olá, pessoa. Espero que você esteja bem!

Programar é muito mais que digitar código rápido. Planejar, estruturar e produzir código legível e de fácil manutenção são de longe características mais desejáveis em um programador que a velocidade para escrever o código em si.

Ainda assim, convém ter algumas cartas na manga que acelerem alguns processos para a gente, ou que diminuam atividades repetitivas. Isso é quase um lema para nós programadores, né? Por isso vim aqui dividir com vocês as três funcionalidades do VS Code que eu uso sempre que estou programando

Comentar bloco de código

A arte de comentar (ou não) o código rende um artigo à parte, mas não entraremos nessa seara: o fato é que todo mundo comenta o código em algum momento, seja como um recado para o seu eu do futuro, ou como uma instrução para outros devs, ou apenas para neutralizar alguns fragmentos do código durante um processo de ~~dedetização~~ debugging. Para comentar um bloco de código, o VS Code tem dois atalhos:

alt + shift + a

ctrl + /

Mover fragmento de código

Suponhamos que você tomou pouco café, e que acabou colocando o seu footer antes do header. Uma solução possível é dar ctrl + x para recortar o footer todo, e ctrl + v para colar ele no lugar certo. Resolvido, muito bom.

Você também poderia fazer isso usando os atalhos:

alt + ↑
alt + ↓

Você pode usar eles em uma linha ou bloco de código. Se for uma linha, não precisa selecionar ela inteira. O atalho vai funcionar só de estar com o cursor nela. É ótimo para fazer pequenos ajustes, e movimentar blocos de código, reordenar listas, tirar ou colocar um elemento dentro de outro, etc.

Alterar múltiplas linhas

Esse daqui é o meu favorito. Imagine que você estruturou sua navbar toda bonitinha. De repente você percebe que não colocou o href dentro da tag a. Bateu um desânimo? Não precisa mais chorar! O VS Code tem os seguintes atalhos:

ctrl + d
alt + click

Com esses atalho você pode multiplicar o seu cursor e alterar, acrescentando ou apagando, diversas linhas de código ao mesmo tempo. Nesse caso, teríamos duas alternativas:
1) Selecionar a tag <a> clicando e arrastando o mouse, e apertar o ctrl + d até que todas estejam selecionadas. Então você digita o href somente uma vez para todas.
2) Você poderia ainda segurar o alt e clicar em todas as linhas que quer alterar. Estando com todas selecionadas, é só inserir a informação que ficou faltando.

Depois de ter feito isso, é só apertar o esc que tudo volta ao normal.

Eu prometi um bônus, né?

Essa não vale pelo atalho em si, mas para acessar outros atalhos do VS Code. Utilizando ctrl + shit + p e digitando "Open Keyboard Shortcuts" você tem acesso a uma lista vertiginosa de atalhos. Divirta-se.