 A thread de hoje é sobre :focus

Porque usamos :focus? O que um indicador de foco precisa ter?
Nessa thread vou me aprofundar nos conceitos por detrás do foco, então  se você é de UI talvez te ajude também!

Segue a thread -> 🧵
Focus

Pra começar, foco é uma ferramenta de semântica de interatividade. A web é uma superfície, logo questões como ergonomia e affordance se aplicam a ela.

As semânticas de ergonomia são as características que tornam um elemento interativo operável.

As semânticas de affordance tratam de como a superfície é percebida pelos mecanismos cognitivos do cérebro - percepção de relevo, toque, pressão e destaque fazem parte disso.

Ambos conceitos são necessários pra que a web como superfície "diga" pro usuário como operá-la

Fiz questão de trazer esses conceitos pra demonstrar a importância dos indicadores de foco, inclusive pra acessibilidade.

O critério de sucesso 2.4.7 da WCAG (Foco visível) explica que o foco ajuda tanto quem opera apenas pelo teclado como pessoas com problemas cognitivos

Link da WCAG sobre foco visível
https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html

O que um indicador de foco precisa ter?
- Bom contraste com a cor de fundo
- Pelo menos 1px de espessura

A especificação 2.4.11 (aparência do foco) trás uma ótima explicação sobre o pq desses itens
https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html


Os elementos interativos "focáveis" são links, botões, campos de formulário, itens de menu, elementos engatilhados por hover como tooltips e widgets como calendários.

O site abaixo tem uma lista completa de elementos com foco e a sua compatibilidade
https://allyjs.io/data-tables/focusable.html

A Sara Soueidan tem um artigo incrível sobre como criar focos que atendem os critérios de sucesso de acessibilidade E de design, beneficiando devs e UI designers

https://www.sarasoueidan.com/blog/focus-indicators/#what-exactly-is-a-focus-indicator%3F

Pra finalizar, o papel da pessoa designer é se assegurar de que os padrões visuais de acessibilidade e heurísticas de layout estão sendo atendidos, sem abrir mão da identidade visual

O papel das pessoas devs é garantir que a mecânica de interação e gestão de foco faça sentido

Eu trouxe bastante conceitos de design e acessibilidade, me contem se quiserem algo mais aprofundado sobre esses tópicos. Essa thread vai ter que virar artigo pra caber tudo que tange essas questões

Até a próxima!

You can read the unrolled version of this thread here: https://typefully.com/lixeletto/DdtTBGa

Indicadores de foco em UI e Desenvolvimento

Quando se fala em layout responsivo, as pessoas, até as mais experientes recorrem imediatamente às media queries.
Layouts como o da imagem abaixo viriam com breakpoints determinados, que seriam reproduzidos na forma @media no código.

Nessa thread vamos aposentar as media queries

Há 10 anos atrás, quando íamos executar um layout, precisávamos de instruções precisas de como ele iria ficar nos dispositivos mais populares da época, protótipos como pequenos retratos - cada retrato de um tamanho, um breakpoint.

As media-queries definiam as posições de cada elemento de forma que quando a tela fosse do tamanho do viewport, o layout seria idêntico, e antes de atingir o próximo breakpoint ou anterior, o layout ficaria solto, se contentando apenas em caber naquele retrato sem overflow

Overflow é o fenômeno que acontece quando um conteúdo qualquer não cabe na caixa em que ele foi colocado, e isso pode acontecer por diversos motivos - ausência de box-sizing: border-box, width em %, etc

As media-queries são apenas uma válvula de escape pra fugir do overflow

O overflow acontece, pois declaramos 2 ou 3 retratos perfeitos via código, evitamos que a foto escape dos limites entre os breakpoints e -principalmente - definimos ou layout como se ele fosse uma reprodução estática e declarativa, não um algoritmo

O layout acima pode ser reproduzido usando uma margem horizontal automática e fixando os elementos do container pra que ele nunca seja maior que o breakpoint definido no media query.
Alteramos também o font-size

Ele basicamente diz:
"Quero que o container tenha 1224px,e que no viewport de 440px tenha 336px"

É uma forma de layout completamente declarativa.

Agora uma forma imperativa de descrever o layout seria assim:

A propriedade:
grid-template-columns: 1fr min(1244px,100%) 1fr

Está dizendo:
Quero que o layout fique em na coluna do meio
Se o espaço disponível for maior que 1244px, a largura será de 1244px, senão, 100%
As colunas da extremidade vão ocupar 1 unidade do espaço disponível cada

Pra criar layouts que são imperativos, intrínsecos, precisamos entender que as propriedades de CSS não declaram apenas fotografias estáticas de layout - hoje elas são capazes de declarar algoritmos completos.

E esses algoritmos não são simplesmente o uso de flexbox, grid e %

Eles são

- Tamanhos intrínsecos
max-content, min-content, fit-content e auto definem o algoritmo que o container utiliza pra controlar o conteúdo interno e evitar o overflow

Falei muito mais sobre isso nesse post
https://dev.to/lixeletto/alem-das-unidades-css-intrinsic-sizing-e-responsividade-gl

- Unidades relativas
E não só o uso delas, mas o entendimento de que relação delas com o contexto do layout vai trabalhar com o algoritmo desejado.

Ícones que escalonam com o tamanho da fonte podem usufruir de uma unidade relativa à fonte (No caso, `em` ou `ch`)

Se a escala tipográfica depende do viewport que ela está inserida, podemos nos beneficiar de unidades de viewport pra calculá-las

Ex:
https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/

Inclusive, abordo mais sobre o que cada unidade proporciona nesse post
https://dev.to/lixeletto/entendendo-unidades-css-e-quando-utiliza-las-3ecc

- Wrapping (quebra de conteúdo)
Texto, flex-items e grids contém suas próprias lógicas de wrapping.

Pra texto, por exemplo, espaço em branco, hifenação e o algoritmo de limites (boundaries) do container definem essa quebra - conforme explico nesse artigo
https://dev.to/lixeletto/como-fazer-pro-texto-nao-quebrar-de-linha-no-css-5440

Elementos flex recebem como parâmetro um eixo e distribuem seus filhos de acordo com o espaço disponível - ou na mesma linha do eixo, tornando os flex-items elementos `min-content` ou mantendo o tamanho dos filhos e quebrando eles em outras linhas.

O grid permite que a quantidade de colunas seja definida pela quantidade de filhos (auto-fit e auto-fill), mas diferente do flex, o grid que define a largura dos filhos, usando suas colunas.

Esse é o princípio utilizado pelo RAM (repeat, auto-fit, minmax)
https://dev.to/lixeletto/padroes-de-layout-com-css-grid-2li0#:~:text=Grid%20da%20lista%20de%20cards%20%2D%20o%20RAM

- Limites
Definimos a responsividade de forma intrínseca não só no layout geral, mas como em seus componentes.
Ao invés de declarar o tamanho do componente em cada viewport, podemos usar uma unidade relativa ao contexto (auto, fit-content) ou ao pai (%) e +

Definir quão grande esse elemento pode ser e ainda permanecer legível (max-width) e quão pequeno ele pode ser antes que seu conteúdo dê overflow (min-width).

Podemos, em todos os navegadores modernos, resumir isso em um clamp()

`clamp(<min-width>, 100%, <max-width>)`

Se notarmos, flexbox segue um algoritmo parecido, só que ele leva em consideração os outros elementos no container (siblings)

`flex: <shrink> <grow> <basis>`

Isso não é magia, e já foi defendido pela Jen Simmons há 4 anos atrás - Intrinsic Layouts
https://www.youtube.com/watch?v=jBwBACbRuGY&ab_channel=AnEventApart

Pelo Josh Comeau ano passado
https://www.joshwcomeau.com/css/understanding-layout-algorithms/

Pelo Ahmad Shadeed ainda esse ano
https://ishadeed.com/article/responsive-design/

E o que sobra pras media queries em 2023?
- Redefinições bruscas de layout
- Experiências customizadas
- Ajustes pra edge cases
- Media features de acessibilidade (color-scheme, color-contrast, reduced-motion, etc)

Não sabe o que é media feature? Vem cá!
https://dev.to/lixeletto/a-anatomia-das-media-queries-1jn0


"Mas Cu, eu não sei fazer responsividade com media queries"

Tudo bem uai.
Layout intrínseco é um tópico que exige bastante estudo e, sinceramente, ninguém nunca me cobrou de quantas media queries eu usava, e provavelmente não vai cobrar você

A proposta dessa postagem é tanto fronts quanto designers entenderem que podem se beneficiar muito mais deixando o navegador calcular o layout do que tentando chutar generalizações de dispositivos pra produzí-los, ou declarar limites e comportamentos ao invés de definir padrões.

E que se antes breakpoints eram um lastro de controle que designers e webdesigners tinham sobre um número limitado de dispositivos, hoje é só um chute educado, do mar de dispositivos e formas de usar a web que existe ai fora

Existe uma vasta literatura de como pessoas exploraram formas diferentes de construir layouts robustos com poucas linhas de CSS, sem magia, sem float, sem table e com poucas media-queries. Inclusive compilei minhas favoritas nesse repositório aqui:
https://github.com/allyhere/expert-css#layout

Então n se acanhem ou se sintam mal sobre media-queries, mas entendam que existe um mundo muito vasto de layout pela frente, e que mesmo que infelizmente n haja muito incentivo do mercado pra se aprofundar dessa forma vc ainda pode se beneficiar do quanto isso facilitará sua vida

Falei que não era bait?
Pretendo transformar essa ideia em artigo, então dúvidas e críticas seriam incríveis. Espero ter despertado curiosidades.

You can read the unrolled version of this thread here: https://typefully.com/lixeletto/tl0CfbE

Aposentando Media Queries no Design Responsivo

Na ultima thread sobre formulários, bora falar sobre CSS?

Vou contar como podemos criar estilos pra cada estado de validação de formulário sem usar UMA gota de javascript, bora?

Segue a 🧵

Antes de começar:
A imagem foi tirada do artigo da Kate Sipkina na Smashing Magazine.
Ela aparece num artigo INCRÍVEL sobre UX em formulários
https://www.smashingmagazine.com/2018/03/ux-contact-forms-essentials-conversions/

O conteúdo de hj é muito inspirado nesse post do Jonathan Harrell
https://www.jonathan-harrell.com/blog/advanced-css-only-form-styling/

Porém não será só uma tradução, abordarei com um ponto de vista voltado também pra UX e acessibilidade.

Tal como no artigo dele, separarei as estilizações com base nos atributos da ConstraintValidation API.

Não sabe o que é isso? Falei na thread de ontem
https://twitter.com/lixeletto/status/1655387521575165952?s=20

Podemos usar as pseudo-classes `:require` e `:optional` pra estilizar campos obrigatórios ou não obrigatórios.

No CSS abaixo selecionamos o irmão imediato do input quando ele estiver no estado de :required ou :optional, inserindo um texto no span .help-text via pseudo-elemento

É uma solução interessante, porém não recomendada pra campos obrigatórios por questões de acessibilidade, pois pseudo-elementos como `::before` não podem ser lidos por leitores de tela.

Uma solução é uma combinação de asterisco após o nome do campo e a propriedade aria-required

Outras formas de solucionar essa questão estão nesse artigo da Deque University
https://www.deque.com/blog/anatomy-of-accessible-forms-required-form-fields/

Já campos opcionais podem ser indicados dessa forma, pois é o comportamento padrão esperado

A pseudo-classe :disabled é a mais comumente conhecida, geralmente associada a campos com contraste baixíssimo e cores de fundo acinzentadas



Esse tipo de abordagem é comum, mas bem ruim pra acessibilidade e usabilidade se mal utilizado.
Um campo desabilitado é simplesmente ausente pra tecnologias assistivas, logo, pra alguém que não enxerga é um campo que está faltando misteriosamente.

Quais os problemas de desabilitar campos indiscriminadamente são abordados de forma incrível pelo Chris Atherton no seu post do Medium. Recomendo tanto pra pessoas de UX como desenvolvedoras.

https://uxdesign.cc/why-you-shouldnt-include-disabled-interaction-elements-in-your-design-system-76a2d4307faf

Mas TL;DR:

- Prefiram usar renderização condicional quando não faz sentido o campo desabilitado existir
- Prefiram prover contexto se o campo está desablitado pra um fluxo específico
- Deixem sempre o motivo da indisponibilidade do elemento claríssima (e acessível)

Campos `:readonly` geralmente são estilizados com um pouco mais de contraste que os `:disabled`. Ele serve pra mostrar campos preenchidos automáticamente ou pelo sistema, como informações de endereço geradas à partir de uma API de CPF.

As pseudo-classes :valid e :invalid são geradas à partir dos estados emitidos da Constraint Validation API

Um campo `required` cujo o conteúdo está vazio emite um evento do tipo `invalid` e o valor do seu estado de validade (`element.validity.valid`) se torna falso.

Isso faz com que mesmo que haja validação pelo Javascript e pelo backend, a validação correta por atributos HTML seja importante. Dessa forma conseguimos acessar esses mesmos parâmetros de validade pelo CSS e estilizar sem a necessidade de adicionar uma classe `.valid`

Conseguimos estilizar também inputs que possuem as propriedades `min` e `max` usando a pseudo-classe `:in-range` e `out-of-range`

Os inputs que podem receber essa pseudo-classe são `date`, `month`, `week`, `time`, `datetime-local`, `number` e `range`

Outro bem conhecido é o `:checked`

Ele é MUITO utilizado pra estilizar outros elementos que usam o checkbox como interruptor, mas também pra controlar estados de inputs do tipo checkbox customizados, como demonstrado nesse artigo da maravilhosa @5t3ph

https://moderncss.dev/pure-css-custom-checkbox-style/

Checkboxes podem ter os estados de checked, unchecked e indeterminate. Pra esse ultimo tempos o pseudo `:indeterminate` que controla esse estado da mesma forma que o `:checked`

Esse artigo do CSS tricks fala mais sobre esse estado
https://css-tricks.com/indeterminate-checkboxes/

Temos vários outros pseudo-elementos de input, como o `:placeholder-shown` (vou falar só dele depois), o `:blank` e um que eu to doido pra ter suporte: o `:user-invalid`

https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-classes#input_pseudo-classes

Essa thread tá pedindo muito pra ser melhor explicada em um artigo, por isso caso tenham dúvidas ou sugestões, lancem ai que eu responderei lá no artigo.

Dêem um salve nas indicações de leitura dessa thread e se vocês já escreveram sobre isso, mandem seus artigos!

CSS Form Validation Styling

Validar formulários pode ser meio treta, e por mais que libs facilitam muito esse trabalho a API nativa de validação de formulário é mais simples do que parece e muito foda

Na thread de hoje, bora conhecer a Constraint Validation API?

Segue a 🧵

A Constraint Validation API tem uma série de métodos e atributos que nos ajudam na hora de validar nossos elementos de HTML.

Essa API está disponível nos elementos:

<form>
<button>
<fieldset>
<input>
<output> (conhecia esse?)
<select>
<textarea>

Ela basicamente torna disponível nesses elementos 3 atributos e 3 métodos de instância

Os atributos são:
- validationMessage
Retorna uma mensagem localizada (sim!) dos elementos que estão invalidos

- validity
Checa a validade de cada propriedade relacionada a um elemento

- willValidate
Retorna se o elemento será validado (Se o form ou o button dele tiver o atributo novalidate, retornará false)

Os métodos são:
- checkValidity()
retorna true ou false da validade do elemento



- reportValidity
dispara um evento que reporta quais elementos estão invalidos.
Exemplo: https://googlechrome.github.io/samples/report-validity/

- setCustomValidity(mensagem)
Define uma mensagem de validação customizada (Aparece em um tooltip padrão do navegador que você estiver usando

Mas como usar na prática?
Bora usar o formulário abaixo como exemplo.

No input de texto temos apenas a restrição required, ou seja, o será inválido se não preenchido

No do número, só é aceito entre 1000 e 1

No do email, usamos patterns pra aceitar apenas e-mails @cuInc.com

Pra validar o formulário acima, usamos o método checkValidity pra retornar se todos os elementos do formulário passavam nas validações e depois validamos cada um:
- O preenchimento do campo de nome
- Se o campo de número estava no limite
- E o campo de e-mail respeitava o pattern

Podemos customizar a mensagem de validação de um input usando a função setCustomValidity(mensagem)

Ao usar reportValidity(), fazemos com que o erro seja reportado a cada input, não apenas no submit.

Quando usar essa API?

Se pergunte "Se não houvesse validação alguma, esse formulário causaria danos ao site, a mim ou a algum cliente?"

Digo isso pois essa validação depende apenas de atributos que cada elemento do HTML, que podem ser facilmente removidos pelo devTools

Isso significa que alguém pode simplesmente apagar patterns, requireds e outras validações, enviando dados incorretos ou maliciosos. A pessoa pode inclusive forçar um envio mesmo com o botão desabilitado usando a função `submit()` do formulário.


Portanto, se a validação for importante, é necessário que ela seja apenas uma de muitas camadas de segurança.

Quase tudo o que você precisa saber sobre essa API está na documentação
https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation#the_constraint_validation_api

Infelizmente a versão em português não está correta, mas vc pode ajudar

Se você nunca contribuiu open source, uma boa oportunidade é fazer um fork desse artigo e mandar uma tradução decente para o MDN. Dessa forma você aprende como contribuições funcionam e ainda tornam a web um lugar melhor

https://github.com/mdn/content/edit/main/files/en-us/learn/forms/form_validation/index.md

E sobre validação nativa de formulários é só - pretendo me aprofundar mais no artigo que vem ai!

Próxima publicação (e ultima) vai ser sobre formulários e CSS!

Validações simples de formulário com a API nativa de constraint validation

Off topic de formulários, mas é importante !!!!!

Já aconteceu com você de o texto de um container não ficar numa linha só nem fodendo?

E te recomendarem

- word-break
- white-space
- overflow-wrap(?)

Segue o fio e bora entender de uma vez por todas pq isso acontece -> 🧵

Primeira coisa, provavelmente seu problema não tem nada a ver com nenhuma dessas 3 propriedades.

Quebra de linha no HTML é que nem sexo anal

Se quebrou, ou você tá colocando errado ou só não cabia mesmo

Se você não relar o dedo no elemento, o valor padrão da width dele será "auto"

A width de "auto" primeiro faz a soma da largura total do seu conteúdo + border + margin + padding (só left e right nesse caso)
Se a soma disso for menor que o espaço disponível, a width vai ocupar td

MAS se for menor que o espaço disponível, ela vai procurar oportunidades de soft wrap (ou quebra fofo), ela visa caracteres de espaço (U+0020) e sinalizadores de quebra de linha (U+000D), que é o que provavelmente decidiu por você que seu texto não cabe em 1 linha só

Isso é um problema de width que pode ser resolvido com intrinsic-sizing!

A propriedade max-content vai dizer que o container tem que ser no mínimo do tamanho do conteúdo.

Eu falo bem mais detalhadamente nesse meu artigo sobre intrinsic sizing
https://dev.to/lixeletto/alem-das-unidades-css-intrinsic-sizing-e-responsividade-gl

Mas e essas propriedades que eu citei no começo do post?
Elas usam da engine do navegador que lida com espaço em branco.

Whitespace (pra ser curto) é de extrema importância pro navegador - ele mantem as tabulações da sua identação, espaço entre palavras, mas...

Se você escreve algo como exemplo abaixo com espaçamento escagalhado, ele interpreta corretamente os espaços que ele tem que deletar.

Daqui pra baixo é nerdagem, então TL:DR
Essas propriedades chupinham da lógica de quebra de espaço do navegador

🤍white-space
Quando o Whitespace é delimitado pra elementos inline (texto, spans, etc), o navegador cria um contexto específico pra eles chamado Inline Formatting Context (vou chamar de IFC)

O IFC calcula as quebras de espaço e tbm coordena eixo de leitura (text-orientation)

O calculo do IFC tá descrito nessa imagem e pode ser encontrado na seguinte documentação
https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Whitespace#how_does_css_process_whitespace

Estava em inglês, traduzi usando o designMode do navegador, é tipo um contenteditable. Não sabe o que é isso? Leia essa thread do @omariosouto
https://twitter.com/omariosouto/status/1653356007391649794?s=20

O whitespace usa isso pra calcular as "soft wrap opportunities" que são espaços e tabs, mas também quebras de palavras se a propriedade `hyphens: auto;` estiver presente pro elemento.

Essa propriedade aplica hífen em quebras de palavras de acordo com o atributo lang do seu HTML

Quais são os valores aceitos por essa propriedade?

MDN mais uma vez explica melhor do que eu:
https://developer.mozilla.org/pt-BR/docs/Web/CSS/white-space#valores

🗾word-break
Define como o navegador vai calcular o agrupamento de caracteres, quais são quebráveis por hyphens ou soft wrap opportunities, especialmente necessário em caracteres CJK (Chinese, Japanese, Korean)

Seus valores são normal, keep-all e break-all

normal é... bem lkkkkk do jeito que tá

keep-all não permite quebra nenhuma pra caracteres CKJ, mas age como normal pra outros caracteres

break-all, vai inserir quebra em qualquer espaço entre caracteres, mesmo CKJ

⛔overflow-wrap
Ele não cuida do espaço em branco, nem dos soft wraps e hifenações entre palavras.

Ele cuida da lógica que o container pai usa pra decidir se as palavras dentro dele devem quebrar de linha ou não

É o MESMO algoritmo que intrinsic sizing utiliza!!!!

Os seus valores são

normal, anywhere e break-word

normal
é o comportamento normal - quebra em soft wraps se o texto não couber no container

anywhere
Vai quebrar TODAS as palavras em soft wraps, e na ausência deles só vai quebrar msm, e sem hífen!!!

Já o break-word (antigamente valor da propriedade word-break!!)
Vai funcionar que nem o anywhere MAS vai manter palavras na mesma linha se elas couberem.

Eles funcionam mais ou menos como

width: max-content, min-content e fit-content, respectivamente;

E por hoje é isso!

Essa definitivamente vai virar artigo pois tem MUITA coisa interessante que precisei deixar de lado.

E ai, vocês já tiveram esse tipo de problema? Como resolveram?
Espero que tenha ajudado algumas pessoas a chutar menos!

You can read the unrolled version of this thread here: https://typefully.com/lixeletto/YgZ4Ogd

Meu texto quebrou, e agora?

Se você quer aprender a nomear suas classes no CSS, acredito que aprender essas 3 coisas possa te ajudar:
- Tomar decisões de arquitetura de CSS
- Expandir seu vocabulário de tokens e componentes
- Conhecer padrões de CSS (como BEM ou CubeCSS)

"Arquitetura CSS" pode assustar um pouco, mas a proposta é basicamente você pensar no seu CSS de forma estrutural antes de escrever.
Você pode, por exemplo, escrever unicamente classes utilitárias, que são classes que fazem uma coisa só e a fazem bem, como no tailwindCSS

Ou você pode construir CSS pensando nos seus componentes, como acontece em frameworks de componente como Material UI, Bootstrap, UI Kit ou Ant Design.
Você pode seguir qualquer uma das abordagens ou ambas, mas sempre adotando de forma consistente!

Expandir seu vocabulário de componentes é importante pois ao escrever uma classe, a maioria das vezes acabamos descrevendo o conteúdo do elemento ao invés de descrever o que o elemento é semanticamente.
Vamos usar o componente abaixo como exemplo, como vocês o nomeariam?

Se você pensou em .invitation ou .connection, entendo sua lógica. Porém se existir outro componente igual a esse só que avisando que vc recebeu uma mensagem, com um layout um pouco diferente, vc:
- Usaria a mesma classe mesmo não sendo um convite
- Criaria outra classe parecida??

Nenhuma das duas soluções parece ideal né? Com uma você tá referenciando uma classe pra um contexto diferente do que ela foi criada, o que é no mínimo confuso.
No outro você duplicou código, o que é beeem ruim pra performance e legibilidade.
Ambas soluções não escalam.

Em bibliotecas de componente esse mesmo elemento se estático pode ser chamado de Card, se feedback de uma ação pode ser chamado de Alert, se for um aviso do sistema pode ser Notification, Snackbar ou Toast.
Esses nomes são padrões consistentes entre várias bibliotecas de UI

A gente poderia criar uma classe base pra todas as notificações e classes modificadoras pra cada tipo de notificação contendo apenas o código que diferencia uma da outra.
Essa abordagem funciona, mas o problema dela é a especificidade.

Por usar duas classes você está criando um seletor com especificidade 0,2,0, correndo o risco de sobrescrever estilos com especificidade menor sem querer.

Se tu não sabe como mensurar especificidade, esse site me ajudou demais a aprender
https://specifishity.com/

Se a gente fosse estilizar o mesmo elemento usando uma lógica de CSS utilitário, poderíamos criar todo o estilo do card e separá-lo em diferentes classes que vão compor o estilo final. Uma classe pra border, border-radius, border-color.

O BO dessa abordagem é você vai sempre ter que escolher entre escrever utilities mais complexas e menos reutilizáveis OU escrever utilities mais atômicas só que ESCREVER CLASSE PRA CARALHO.
Eu aconselho sempre um equilíbrio entre componentes e utilities.

Pra finalizar esse tópico, pesquisem bibliotecas de componente ou utilitárias de CSS, elas buscam adotar padrões consistentes de nomenclatura. Ao criar um novo componente sempre vale consultar nas documentações da vida se já existe um parecido que vc pode roubar o nome (ou mais)

Lembra no componente de notificação que usamos uma classe modificadora pra alterar o CSS base da classe .notification?
Isso é uma estratégia de CSS adotada por alguns padrões de CSS pra evitar duplicação de código. O BEM CSS é literalmente Bloco, Elemento e Modificador

Padrões de escrita de CSS servem para mitigar problemas com especificidade, organização, arquitetura, conflitos de nome e etc APENAS padronizando a forma como você pensa e escreve as suas classes

Sobre isso, em português:
https://desenvolvimentoparaweb.com/css/bem/
https://desenvolvimentoparaweb.com/css/cube-css/


Pra evitar criar nomes de classe desnecessariamente, eu uso e abuso dessas 3 dicas:
- se existe uma pseudo-classe pro estado do seu elemento USE
- data-attributes são ótimos pra estados definidos via JS
- variáveis CSS podem ser usadas como "props" que o HTML envia pro CSS

Resumindo:
Se você sente que o nome das suas classes tá uma merda CALMA! Não é tão simples quanto parece fazer bem e ninguém nasce sabendo. Tem bastante coisa legal pra tu estudar que, com tempo, vai fazer com que essas decisões de nomenclatura sejam quase que automáticas.

Referências legais aqui

Um texdto bacana do Nicolas Gallagher sobre semântica
https://nicolasgallagher.com/about-html-semantics-front-end-architecture/

CSS Guidelines
https://cssguidelin.es/#naming-conventions

You can read the unrolled version of this thread here: https://typefully.com/lixeletto/lYqOG0m