Você consegue escrever CSS “errado”?

Você regularmente encontra alguém que argumenta que sim, dizendo o que você precisa fazer ou dizendo o que você não deve fazer.

Por exemplo, os pares argumentaram usar redefinições, não usar !importante, não usar taquigrafias, não usar certos seletores, apenas para usar propriedades lógicasetc.

Outros sugeriram que você não pode escrever “CSS errado”. Pessoalmente, para o exemplos dado, Eu tenho.

Por que você não consegue escrever CSS errado?

Apresento quatro razões. (Comente nas redes sociais se você acredita que há mais – ou que estou errado!)

1. Se funcionar, funciona

Se não houver nenhuma desvantagem prática concreta nisso – como UX significativamente pior ou DX concretamente pior -, não há razão para mudar algo que está funcionando. CSS não é terapia ocupacional.

Além disso, a plataforma web raramente ou nunca deprecia alguma coisa e, em vez disso, enfatiza a compatibilidade com versões anteriores. Isso significa que o código é seguro. Como Marco Peregrino uma vez disse:

“Os padrões são como o sexo; um erro e você fica preso a apoiá-los para sempre!”

Não há CSS errado aqui.

2. Quem sofre é você

Vamos supor que haja algo extraordinariamente ruim no CSS. Por exemplo, a sua organização está a abrir-se ao mundo árabe e todos os websites precisam de apoiar RTL roteiros.

Aquilo é seu problema, e não de ninguém que promova o uso de propriedades lógicas.

O problema é seu, seu incentivo para resolvê-lo e sua decisão de quando fazer o que em seu CSS. Portanto, também não há CSS errado aqui.

3. É fácil mudar

Agora seu site usa uma técnica de layout antiga – digamos, baseado em float—, e eventualmente você não gosta dessa forma de fazer layout.

Mas já que estamos falando de CSS – não HTML de apresentação—, você pode mudar isso facilmente. “Facilmente” como fazer as alterações necessárias (dependendo do projeto, os testes podem não ser executados e atualizados tão rapidamente, mas este é um assunto diferente).

Portanto, se houver uma necessidade real de mudança, quando uma solução for visivelmente melhor que outra, a mudança sempre poderá ser feita.

É difícil argumentar que há algo errado no CSS se o CSS permitir dinamizar e alterar rapidamente a solução, no sentido de que não pode ser um erro grave, difícil de corrigir. Já sabemos que é o mais importante para acertar o HTML.

4. Barreiras para usuários são responsabilidade da plataforma web

Cuidado: ainda não chegamos lá. Pense nisso como uma perspectiva na qual poderíamos nos esforçar muito mais.

Supondo que haja algo totalmente errado e que o CSS que você está usando esteja criando problemas para seus usuários.

Embora isso possa levar à ação – nada aqui diz que você não pode agir –, é aqui que podemos voltar a um ponto que nem sempre é apreciado:

A plataforma deve dificultar a criação de barreiras e facilitar a sua remoção.

Este não é um princípio de design oficial em nossos padrões e em sua implementação, mas certamente é um que poderíamos adotar.

Mas o que isso está dizendo?

É dizer em termos gerais o que Joe Clark, por exemplo, disse em termos mais específicos (“se um navegador ou tecnologia adaptativa pode ou deve resolver um problema de acessibilidade, eu não o farei”):

O desenvolvedor fornece a intenção; a plataforma oferece a garantia de acesso.

Isso significa que quando há um problema de CSS tão grande que alguém diria que seu CSS está errado, pode ser algo que deve ser resolvido no nível da plataforma.

Fique comigo aqui: como a citação de Joe pode indicar, já estivemos aqui antes, quando problemas foram resolvidos por desenvolvedores que realmente deveriam ter sido tratados em outro lugar. Só mais um exemplo? O “entalhe”, onde soluções foram propostos para resolver um problema que nós, como desenvolvedores, provavelmente não deveríamos precisar resolver (ainda que cuja não solução poderia facilmente ser apelidada de código “errado”).

Mais interessante pode ser um caso extremo simplificado: imagine alguém usando texto preto sobre fundo preto. Inacessível (e absurdo). O que este ponto sugere é que mesmo isso não seria CSS errado – mas que a capacidade de remover tais barreiras é uma responsabilidade da plataforma. Isso pode acontecer de várias formas: Por estilos de usuário como já os temos, por correção automática de cores ou por algum modo que um usuário possa alternar para acessar o conteúdo.

Avise se isso puder ser útil para dissecar mais detalhadamente, tentarei abordar esse tópico em um artigo separado.

Mas e se alguém ainda disser que seu CSS está errado?

Então, primeiro, verifique o contexto e se ele se aplica a você. Por exemplo, se você estiver ingressando em uma equipe que trabalha em um site internacional que oferece suporte a vários scripts, poderá ser solicitado que você use propriedades lógicas. Isso é bom. Tudo bem.

Portanto, se o contexto se aplica a você, considere o conselho.

Se isso não acontecer, então você ainda está livre para aceitá-lo, mas isso é sua escolha.

O contexto lhe dirá se você está lidando com conselhos — ou com dogmas.

(Da mesma forma, você pode usar tudo isso para moderar suas próprias críticas ao CSS de outras pessoas: é realmente “errado” – como se não funcionasse e eles nem mesmo arcariam com as consequências?)

No final, CSS permite resolver uma infinidade de problemas de design e interação de inúmeras maneiras diferentes. A plataforma controla como essas formas são aplicadas, expostas e gerenciadas. Por causa de ambos, não há realmente “errado” em CSS.

Muito obrigado a Ahmed Sombreado por revisar esta postagem.