DEV Community

Cover image for User Agent Style Sheet: o porquê de um CSS que só serve para ser sobrescrito
Ricardo Gouveia
Ricardo Gouveia

Posted on • Edited on

User Agent Style Sheet: o porquê de um CSS que só serve para ser sobrescrito

Numa manhã onde eu estava no meu horário mais reflexivo — quando é muito tarde para voltar a dormir, e muito cedo para começar a se arrumar para o trabalho — eu vi o tweet da Ire Aderinokun com uma enquete sobre o método que utilizávamos para resetar CSS.

Me veio na cabeça a pergunta: pra quê serve aquele CSS que o browser por padrão aplica em certos elementos HTML quando não se utiliza um CSS Reset e nem um estilo próprio que o sobrescreva?

User Agent Style Sheet: uma história

Photo by [Marcus Loke](https://unsplash.com/photos/MFSAETSrcLY?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)Photo by Marcus Loke on Unsplash

Resumidamente, o UA (abreviação para User Agent) é descrito, na especificação do CSS1, explicando que cada navegador deve em cada browser conter um estilo mínimo a ser aplicado a cada elemento HTML. Já as espeficicações CSS2 e CSS3 acrescentam que a aparência dos elementos quando estilizados pelo UA do navegador devem ser genéricas e "satisfazer expectativas da apresentação documento". A explicação do Jens Oliver Meiert é mais detalhada a respeito da evolução do UA.

Se pensarmos no inicio da Web, com seu intuito único de transferência de conhecimento acadêmico, então faz todo sentido a existência de um UA, já que certamente todo o poder do CSS3 seria desnecessário só para esta tarefa. Naquela época, a Web era como se fosse um LaTeX com opções de compartilhamento.

Ainda hoje, essa utilidade de manter um estilo básico para cada elemento não é totalmente inútil. Se o arquivo CSS não carregar, é bom que o browser saiba mais ou menos onde "jogar" cada coisa. Se ele não soubesse que o H1 deva ser um bloco com margem superior e inferior, título e parágrafo iriam parecer um código minificado.

Resumindo: a utilidade desse estilo é se manter como a ultima tentativa do browser para manter a legibilidade do conteúdo.

Tempos modernos

Photo by [Agnieszka Boeske](https://unsplash.com/photos/ky0ljKGar78?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/browser?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)Photo by Agnieszka Boeske on Unsplash

Eu me lembro que no meu primeiro curso de HTML, em 2010, o professor explicou que o browser já aplicava um certo "estilo" no HTML. Mas a explicação se limitou a isso, e ao fato de que deveríamos nos livrar desse estilo para prosseguir, e como fazer isso com um reset.

No início da curva de aprendizado, não parece uma coisa sensata questionar o professor sobre isso. O arquivo de reset é pequeno (do ponto de vista do aluno que ainda não saber que cada KB conta, e muito!) e se você não tiver muito conhecimento em CSS e quiser tentar fazer algo sem ele, nada — literalmente NADA — parece funcionar direito.

Outro ponto para chamar atenção é que o estilo aplicado pelo UA não é padronizado. Existe uma sugestão de como deve ser esse código pela W3C (e parte do estilo aplicado é simplesmente os valores padrões das propriedades CSS) mas a não ser por isso, a descrição do seu papel é aberta o suficiente para que cada browser implemente sua maneira de manter ordem no caos (e nessa parte, eu tenho que dizer que estaria um pouco interessado em um browser estilizar uma página automaticamente com flexbox ou grid, mesmo sabendo das consequências).

A diversidade de browsers—diretamente ligada a das empresas que os desenvolvem e ainda consequentemente a todo ecossistema das empresas de TI — é importante. A minha sugestão de padronização se limita ao UA, e não aos browsers e suas engines.

Em meio a benefícios e malefícios, a guerra dos browsers está com cada vez menos competidores (do ponto de vista de engines). Ninguém mais quer escrever uma engine do zero. E talvez nem deva, já que as que temos hoje são resultados de anos de evoluções.

O problema é quando o browser traz, sem direito de escolha, algo com potencial de destruir a tão cuidadosamente planejada experiência do usuário, e ainda esse algo tem um comportamento de certa forma imprevisível.

O que o futuro poderia nos trazer

Photo by [Lucrezia Carnelos](https://unsplash.com/photos/IMUwe-p1yqs?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/future?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)Photo by Lucrezia Carnelos on Unsplash

Você compra um apartamento muito caro, na beira mar, no melhor bairro de uma cidade muito boa. Ele tem piscina, academia, porteiro e vários elevadores. Ele também tem uma suíte com a melhor vista do prédio.

Só que nessa suíte tem uma lâmpada incandescente que não tem interruptor, e já vem ligada. A vantagem é que ela não desliga quando falta energia. E você pode, se quiser, quebrar a parede e colocar um interruptor.

Eu realmente não entendo porque browsers, ou o próprio HTML, não trazem ferramentas que resetam o CSS padrão. Antes, me fazia sentido quando os esforços da W3C eram em tags genéricas. Mas hoje, temos equipes analisando a demanda da web e sugerindo tags com base nisso. A recente adição da tag *dialog* é prova disso.

A existência de muitos métodos de sobrescrever o UA pode ser um empecilho a inserção de algo com essa função nos browsers. Mas como a antiga forma de trabalhar mandava, eu sempre imagino que um atributo initial-state="reset" na tag link poderia ativar um reset básico, e quem quisesse algo mais como um normalize, que inserisse um arquivo como fazemos hoje.

Top comments (0)