Esqueça o atributo style. Estilos inline em doctype strict são resquícios do câncer de um passado sem padrões.

Por: Henrique Costa PereiraMonday 28 August 2006 às 13:28

Nesta altura do campeonato você deverá ser um expert para concordar facilmente comigo sem se sentir ofendido. Não se ofenda, não é pessoal, mas utilizar estilos inline é tão racional quanto utilizar a tag <font>. Este é um hábito tão duvidoso quanto substituir <table> por <div>. Este texto é uma reflexão conceitual do significado do atributo style e não um tratado de condenação.

Para entender o que eu quero dizer você deve ter que percorrer determinado caminho se ainda não o fez. Você precisa entender o âmago dos padrões web e saber muito bem o que é desenvolvimento em camadas, onde conteúdo, apresentação e comportamento ficam separados um do outro. Um doctype strict diz sobre uma página de que a sintaxe que ali se encontra deve ser 100% estrita (strict) da própria linguagem. É o que um doctype strict diz. E isso supõe também nas entrelinhas de que todo o conteúdo deve ser separado da apresentação. Certo?

Atributo style em doctype Strict é pérola em focinho de porco

Você precisa saber as diferenças conceituais entre um doctype strict e um transitional. O doctype transitional foi feito para ser "flexível" a aceitação de markup obsoleta e o strict não. Na história dos padrões, uma sintaxe estrita deve utilizar um doctype strict e deve separar completamente o conteúdo da apresentação. Um doctype transitional nem tanto, ele é mais libertino. Com um doctype transitional você está dizendo para qualquer user agent que você não utiliza uma markup estrita e que algumas regras poderão ser quebradas quando você achar necessário. Saber quando fazer essas diferenças na prática é o básico do desenvolvimento seguindo os padrões. Este é o ideal dos padrões, é como as coisas "devem ser" e não necessariamente como são.

A existência do atributo style na especificação do XHTML Modularization mesmo que indicado como deprecated é tão contraditória quanto a permissão de tags com propósitos apresentacionais. Não fazem nenhum sentido.

Vale lembrar que um elemento ou atributo indicado como “deprecated” (desaprovado) é diferente de um elemento “obsolete” (obsoleto), ou seja, um elemento deprecated ainda faz parte da linguagem mas provavelmente não terá nenhum suporte em versões futuras da linguagem, onde se tornará obsoleto. O que a especificação da W3C diz sobre o atributo style no XHTML, mesmo com doctype strict, é que ele ainda faz parte da sintaxe estrita da linguagem.

Como eu já escrevi antes, um doctype transitional só deve ser utilizado quando for necessário dar suporte a elementos e atributos com propósitos apresentacionais. A W3C diz isso:

This is HTML 4.01 Strict DTD, which excludes the presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

Mas meu conselho é: Não use o atributo style em um doctype strict mesmo que a documentação permita isso como parte da linguagem estrita. Bom, então talvez você esteja se perguntando o seguinte: "Você está se opondo a utilização do atributo style em elementos de uma página que possui um doctype de XHTML strict mesmo que a documentação da W3C diz que ele é sim permitido?" A resposta é "sim", eu estou me opondo a isso.

Retro-compatibilidade?

Para ser sincero eu não sei a razão exata do porque isso foi permitido nesta versão do XHTML mas eu tenho uma suposição. Chama-se retro-compatibilidade com versões passadas das linguagens de marcação. Lembre-se que neste ponto estou dando a minha opinião e o que eu suponho ser. Talvez o pessoal da W3C acredita que a web não estivesse preparada (o XHTML é datado por volta do ano 2000) o suficiente para separar a apresentação do conteúdo de forma completa, e para minimizar a utilização de markup com propósitos apresentacionais, eles pelo menos permitem que você utilize atributos com estes propósitos em um doctype que supõe ser strict. Bem controverso isso não?

Retro-compatibilidade tem lá suas facetas. Só quem nunca trabalhou em migração de grandes sistemas com linguagem obsoleta e antiga para uma mais moderna não sabe o quanto é difícil e penoso, e que algumas decisões podem até comprometer um projeto. De qualquer modo não quero lançar meus julgamentos pessoais sobre as razões que a W3C encontrou para manter o atributo style como parte da sintaxe estrita do XHTML. A única coisa que sei é que o atributo style tem objetivos apresentacionais e não deve ser utilizado em uma linguagem estrita.

Qual a diferença?

Seguindo o exemplo de Emil Stenström qual a diferença entre os dois exemplos abaixo na sua opinião?


<body bgcolor="#1B486F">
<center>

<body style="background:#1B486F">
<div style="text-align: center">

Se sua resposta for “nenhuma, não há nenhum diferença entre os exemplos acima”, você está certo. Ambos os exemplos não prezam pela separação entre conteúdo e apresentação.

Desenvolvimento em camadas é separação

Seguir os padrões web é separar conteúdo da apresentação. Os dois exemplos acima não diferem em exatamente nada conceitualmente, somente em sintaxe, ao deixar style inline na markup. Mesmo que seja dentro de um include processado no servidor e que basta você alterar em um único lugar que esta alteração irá valer para o site inteiro. Não interessa, estilos inline trata-se de apresentação e não de conteúdo.

Lembre-se que estou tratando neste texto do ideal do que deve ser seguir os padrões web à risca. Você faz suas escolhas diariamente ao desenvolver para web baseado em cada contexto, por isso a avaliação de que você segue ou não é sua. Você escolhe se quer ou não seguir os padrões e o quanto deles você quer seguir. O próprio Roger Johansson admite utilizar estilos inline em determinado contexto ao mesmo tempo em que ele concorda que não se deve utilizá-lo. Leia você o texto dele sobre este mesmo assunto tratado aqui.

Se você precisa utilizar estilos inline (não estou te julgando, você sabe o que é melhor), utilize um doctype transitional. Enquanto a palavra “padrão” significar “padrão”, isso é o que eu acredito ser o certo e o que deve ser feito. Mesmo que o validador não acuse o erro. Se não tem certeza de que a sintaxe será sempre estrita, não utilize um doctype strict. Estas são as regras do jogo.

Este texto não pode ser copiado ou reproduzido em nenhum outro site na íntegra sem autorização do autor!. Mais detalhes sobre licença de uso aqui!

Tags: HTML Semântica Web W3C Web Standards XHTML doctype markup padrões web

29 Comentários para “Esqueça o atributo style. Estilos inline em doctype strict são resquícios do câncer de um passado sem padrões.”

# 1° Tárcio Zemel Monday 28 August 2006 às 01:28 PM GMT

É… Realmente faz sentido!

Eu não estava me convencendo até o momento o subtítulo “Qual a diferença?”, mas depois percebi que é certo seguir o abandono do atributo STYLE quando se usa DTD Strict.

# 2° Rael B. Riolino Monday 28 August 2006 às 02:28 PM GMT

Não vejo lógica para usar qualquer um dos 2 exemplos citados na matéria, se você pode deixar programado o estilo dentro do CSS.

Existe gente que usa ?

# 3° Carlos A. Ferrari Monday 28 August 2006 às 03:28 PM GMT

Concordo plenamente com você, se tem o padrão, é para ser seguido!. por isso procuro fazer meus sites todos sem sequer usar hacks! sim, depois de penar um pouco eu até consigo, se não dá, eu uso um estilo dentro de um comentário condicional (um codigo porco feito para rodar somente em um navegador porco). E a marcação, o mais limpa e semântica possivel, atributo “style” não dá, pra mim é a coisa mais porca que existe em um XHTML strict.

[]’s

# 4° Carlos Eduardo Monday 28 August 2006 às 04:28 PM GMT

Também não vejo sentido em utilizar estilos inline, já que podemos utilizar no CSS, separado, facilmente.

Depende, só se estiver lidando com algum projeto gigantesco que exija muito tempo e isso signifique perda de dinheiro, de repente…

# 5° Lucas Ces Monday 28 August 2006 às 05:28 PM GMT

Só para criar um pouco de polêmica:

O atributo style pode ser algo bem útil (um atalho eu diria) na hora de mexer nos estilos de um único elemento através de ECMASCRIPT.

Imagine por exemplo um DIV, que por algum motivo deve aparecer e desaparecer da tela ao clique de um botão ou algo parecido. Para ser sintaticamente correto eu poderia criar uma classe css que ajuste a propriedade DISPLAY:NONE e fazer malabarismos com o atributo CLASS no script ou eu apenas poderia ajustar o atributo STYLE=DISPLAY:NONE. Mas esse problema só aconteceria em páginas renderizadas no modo “Standards compliance mode”.

# 6° Douglas d'Aquino Monday 28 August 2006 às 05:28 PM GMT

Alguns dispositivos móveis não suportam a importação da folha de estilo. Lembrando que a tag nem sempre é uma atribuição inline do css, ele pode ser o substituto de uma folha de estilo no header da página, para um site específico para mobile.

Tem também uma outra função importante da tag style: exceções…. digamos que em uma e apenas uma página do seu site de 1459 páginas precise ter uma cor diferente… pra que fazer uma regra específica, criar classes ou id’s em seu documento existente ou mesmo pra que criar uma folha de estilos nova, se você pode escrever as regras específicas naquela página exclusivamente, sem colocar atributos inline?

tem que pensar por esse lado…

o que você deve repreender na hora de dizer para não utilizar a tag é para não utilizá-la no meio da diagramação. Evitar usá-la sim, é um conselho justo… mas ainda é necessária no mundo da convergência, onde nos deparamos com os mais variados dispositivos.

mas é excelente levantar este tópico, parabéns

[]’s

# 7° Rogério Brum Monday 28 August 2006 às 06:28 PM GMT

Uma vez eu li o artigo nao sei de quem que falava que os estilos in-line tinham sido mantidos só para o javascript (como citou nosso amigo ai de cima). Isto era só um achismo do cara mas tem fundamento.
Me lembro que la pelas tantas o cara deu um exemplo de que se fosse preciso fazer uma função para mover algum elemento de 0 até 300px e que esse mesmo elemento andasse 1px/milissegundo teriamos que criar 300 classes em um arquivo css. Pode ter sido por isso. Mas se não foi futuramente será pq criar 300 classes pra fazer um movimento em js nao da, né?
Ou então que deixem o style só pro js mesmo.

# 8° Jader Rubini Monday 28 August 2006 às 10:28 PM GMT

Realmente usar o atributo style não faz sentido algum, e até já tinha dito um pouco sobre isso em um post no meu blog.
Se o objetivo das CSS é separar formatação do conteúdo, porque incluir os estilos na marcação? Não consigo entender…

# 9° Thalis Valle Tuesday 29 August 2006 às 12:29 AM GMT

Espero que o pessoal já esteja careca, disso…

# 10° Henrique Pimentel Tuesday 29 August 2006 às 02:29 AM GMT

Eu não sei, acho que sou um pouco radical.
Acho que em algum momento tudo deveria perder acompatibilidade e forçar uma mudança.
Parece loucura, mas acredito que toda exceção, toda regra que é mantida nas versões novas, mesmo tendo uma regra nova, mais eficiente, não força a mudança.
Infelizmente precisamos de pontos de virada, momentos em que temos que mudar, porem se essa mudança não for algo forçado, pode demorar muito tempo para que todos a adotem, tanto tempo que quando forem adotadas, ja estarao obsoletas e terao novas versoes.
Essa é uma visao minha e reflito muito sobre isso quando eu leio as novas especificacoes do CSS, que podem demorar tanto tempo para serem implementadas que ja ‘nascerao’ velhas.
Por outro lado, toda mudança tem um custo, e se esse custo for alto demais, tão alto que possa inviabilizar a web como a conhecemos. Se a ideia da web ser essa massa anarquista e sem padroes definidos, focada no conteudo e nas pessoas e nao nos softwares.
Dá para filosofar um bocado sobre esse assunto, afinal as pessoas não percebem se a pagina foi escrita em xhtml ou html 3.0, para os olhos o resultado renderizado é o que importa.

# 11° João Vagner Tuesday 29 August 2006 às 09:29 AM GMT

Como ja foi citado, style=”" pode ser uma substituição de uma class ou id definido, Utilizando javascript e afins. Solução? deixe de usar Strict.

:)

# 12° Eugenio Grigolon Tuesday 29 August 2006 às 09:29 AM GMT

Rael B. Riolino:

Depende muito isso. Você por exemplo pode querer fazer um menu, e colocar dentro de um “p”, sem problemas, mas não é o certo, e sim usar “li”. Algumas tags são necessárias, mesmo que não se parecem.

# 13° Igor Escobar Tuesday 29 August 2006 às 10:29 AM GMT

E ponto final =)

# 14° Douglas d'Aquino Tuesday 29 August 2006 às 11:29 AM GMT

Eu troquei as bolas no meu comentário… comentei sobre a tag e não sobre o atributo style… revendo o post e o comentário, realmente concordo… o atributo style deve ser esquecido de vez… estilo in-line já é bem demodé e já tá na hora de pararem de utilizar

mas só reforçando a idéia, para dispositivos que não permitem a importação ou a linkagem de folhas de estilo, tag style ainda está viva

# 15° Matheus Henrique Tuesday 29 August 2006 às 12:29 PM GMT

Eu acho que vocês estão viajando na batatinha, vão caça algo pra fazer.. perca de tempo fica escrevendo besteira ao invés de trampa

# 16° Gustavo Straube Wednesday 30 August 2006 às 01:30 PM GMT

Assim como foi citado em alguns comentários anteriores, também acredito em que o atributo style tenha sido mantido por causa do JavaScript. Mas acho que ele poderia deixar de existir na especificação do XHTML, mas continuar acessível por meio de script. Da seguinte forma: a tag poderia ser inválida, mas algo como document.getElementById(’minhaDiv’).style ser possível de manipular.

# 17° Flávio Araújo Wednesday 30 August 2006 às 07:30 PM GMT

Concordo plenamente com o texto, mas enfim:

Se formos criar uma pagina para rodar em um aplicativo onde nao faça importação de um arquivo.css, axo melhor escrever ele no header do documento ao inves de utiliza-los totalmente in line.

ja quanto aos java scripts, eles tambem nao precisam ser in line, podem ser importados tambem, assim como os .css

Quanto ao comentário do Douglas, axo valido sim criar uma classe ou estilos numa folha externa sim, afinal, a mesma quantidade de caracteres que será utilizada pra escrever ela in line, será a mesma para inclui-la numa folha externa que ja esta atrelada a todos os dodumentos do site.

E alem de que, se um dia nao precisar mais dessa
classe ou estilo, e so deletar ela dentro do arquivo .css, mais facil que ficar catando pedaços do style dentro do documento.

Sei la, aqui talvez seja so uma questao de gosto pessoal.

Abraços

Flávio

# 18° Tiago Celestino Wednesday 30 August 2006 às 09:30 PM GMT

Putz… uso estilo inline em DTD Strict, mas apartir da leitura desse artigo, estarei acabando tirando a ideia de utilizar style=”atributo” em meus projetos.

# 19° Qual o papel dos web standards na arquitetura da informação? » Revolução Etc - Web Standards em uma casca de noz! Saturday 9 September 2006 às 03:9 PM GMT

[...] Com o código de um site escrito semanticamente correto, completa separação entre conteúdo e apresentação técnicas de acessibilidade implementadas racionalmente, pode não influenciar diretamente na experiência que um usuário pode ter no seu site. Isso é verdade. Um site com código mal desenvolvido não é visível ao usuário final e não influencia na “experiência” que ele pode ter ao navegar pelo seu site. Não tem como você saber ao olhar para um site se ele usa tabelas ou CSS para estruturar o conteúdo ou se o código é limpo ou sujo. Ou seja, isso não influencia em nada na experiência final do usuário certo? [...]

# 20° Quem deve se preocupar com os padrões web? » Revolução Etc - Web Standards em uma casca de noz! Sunday 17 September 2006 às 02:17 PM GMT

[...] Cada um destes envolvidos terá uma relação de amor e ódio com o seu trabalho de forma diferente. E isso é natural. Imagine o meu texto sobre o atributo style nas mãos de cada um destes profissionais. Qual a reação que cada um deles poderia ter? Você consegue imaginar? Em um site como o Revolução Etc, o discurso tende a ser direcionado na maioria das vezes para aquele público que já está convencido da real utilização dos padrões e quer refletir sobre os diferentes aspectos que fazem parte disso como atributos, tags, browsers, usabilidade, acessibilidade, nomeclaturas, CSS e por ai vai. Um texto dizendo que o atributo style não deve ser utilizado de forma alguma com um doctype strict tem um foco e um público muito restrito, pode ser extremamente esclarecedor para alguns e soar completamente como apocalíptico para outros, e tudo vai depender do público. [...]

# 21° Desenvolvimento em camadas « Blog do Jader Saturday 23 September 2006 às 12:23 AM GMT

[...] É aqui onde fica toda a informação do site, é a “markup” do site, o XHTML. No XHTML devem ser evitadas ao máximo as imagens que não exercem papel importante na disposição da informação no site, ou seja, as imagens meramente decorativas não devem, em hipótese alguma, ser inseridas aqui. Atributos de estilização “inline” também devem ser evitados a todo custo, para que funcione o conceito de “desenvolvimento em camadas”. Além disso, deve haver um zelo extremo pela semântica do documento, para que ele seja acessível ao máximo a mecanismos de busca e principalmente a portadores de deficiências visuais ou outros tipos de deficiência. Um código limpo, bem estruturado e semanticamente correto é um excelente ponto de partida para o desenvolvimento em conformidade com os web standards, e também para a implementação das duas próximas camadas do desenvolvimento. [...]

# 22° Boas práticas não é xiitismo » Revolução Etc - Web Standards em uma casca de noz! Tuesday 3 October 2006 às 07:3 AM GMT

[...] No final, um excelente profisisonal é aquele que procura o bom senso em tudo. Não é ser xiita e não é ser amador. Demonstrar a eficiência de um método é mais convincente do que muitas palavras de ordem ácidas emitidas por um geek. Encare aquelas dicas de não utilizar estilos inline ou utilizar sempre um doctype strict como hábitos de boas práticas e não uma religião. Se você ainda não entende muito bem do que trata essas “boas práticas”, o tempo vai te mostrar. Se você quiser. [...]

# 23° Princípio de pareto: A teoria 80/20 aplicada ao desenvolvimento de web » Revolução Etc - Web Standards em uma casca de noz! Tuesday 12 December 2006 às 06:12 AM GMT

[...] Para muitos isso é muito muito óbvio, mas eu só escrevi este texto porque eu acredito que é uma grande defesa aos padrões web se bem explicada e um grande argumento de venda. Quando você desenvolve em camadas separando o conteúdo da apresentação, você tem menos código a ser baixado e parte dele será cacheado. Principalmente os e-commerce que possuem um fluxo de navegação interno maior, e várias páginas são requisitadas ao servidor neste fluxo, boa parte do que for requisitado já foi cacheado como estilos e scripts. Mas muitos ainda são fãs de utilizar scripts dentro da propria página e estilos inline. [...]

# 24° » A Arte do SEO / Tecnocracia : Estado Tecnológico Friday 16 March 2007 às 01:16 AM GMT

[...] o mínimo de formatações inline (dentro do código) possível, de preferência nenhuma. Da mesma forma, prefira adicionar imagens [...]

# 25° Nagüeva » Blog Archive » Definindo a linguagem padrão da folha de estilos de um site Thursday 27 September 2007 às 01:27 PM GMT

[...] se você está utilizando o atributo style em estilos inline, o user agent pode não saber qual a linguagem utilizada no estilo aplicado. Ou se uma empresa [...]

# 26° Nagüeva » Blog Archive » Definindo a linguagem padrão do estilo aplicado no HTML Friday 14 December 2007 às 12:14 PM GMT

[...] qual a linguagem utilizada no estilo, através do type=”text/css”. Agora se você está utilizando o atributo style para estilos inline, o user agent pode não saber qual a linguagem utilizada no estilo aplicado. Ou se uma empresa [...]

# 27° CSS Hacks ou comentários condicionais? « O Webmaster Sunday 29 June 2008 às 08:29 AM GMT

[...] Não utilize o atributo style. Se precisar alterar o estilo por javascript, utilize classes. [...]

# 28° Leon Santiago Friday 11 July 2008 às 05:11 PM GMT

Eu acredito que o style é importante para diversos casos, js e exceções principalmente. E acredito que tenham sido permitidos por serem uma forma organizada e facilmente identificável de separar o conteúdo da marcação NA marcação. Ás vezes a gente fala como se separar “fisicamente” os códigos de estilização fosse mais eficiente do que um programa consegue fazer simplesmente ignorando tags “style”. Não há necessidade de banir essa tag apenas pra alimentar um desejo infundado de padronização. Com a tag “style”, que o nome indica claramente, É estilo, a marcação e o estilo continuam separados e não cria impecilhos absurdos como o que comentou alguém aí sobre as 300 classes.

Acho estranho apenas o “deprecated”, talvez quando ela for banida algo entre em seu lugar, de forma ainda mais modularizada.

# 29° Pablo Demier Thursday 2 July 2009 às 02:2 PM GMT

Em campanhas de e-mail marketing ainda é bastante considerável o uso de css inline assim como tabelas devido às limitações dos webmails. Muitas vezes a utilização de layouts tableless ou boxmodel ou com folhas de estilo separadas do html podem causar um estrago e tanto em uma campanha de e-mail marketing ou newsletters que podem até ser consideradas spans pelos usuários

Avisos
Os itens com asterisco ( * ) são campos de preenchimento obrigatório.
Todos os links inseridos nos comentários possuem o atributo rel="nofollow" para impedir com que user agents (como os mecanismos de busca) sigam os links inseridos para desestimular spammers.
Todos devem se identificar através de e-mail válido.
Os e-mails dos usuários não serão divulgados no site.
Comentários:


Assine por feed

assinantes Assine o feed do Revolução Etc

Sobre o Revolução Etc

Foto do autor Henrique Costa Pereira O Revolução Etc é o site pessoal do Henrique C. Pereira que trabalha com design de interfaces, planejamento, arquitetura da informação e desenvolvimento para web. Ele escreve aqui sobre várias coisas relacionadas com acessibilidade, web standards, tecnologia, desenvolvimento e o que mais der na telha, além de eventualmente escrever alguma coisa ou outra para o Webinsider. Leia mais.

Livros que vão colocar minhocas na sua cabeça:

  • SEO Otimização de Sites - Paulo Teixeira
  • Não me faça pensar! - Steve Krug
  • Google Adwords a Arte da Guerra - Ricardo Vaz Monteiro
  • Design para Internet: Projetando a Experiência Perfeita - Felipe Memoria
  • Sopro no Corpo: Vive-se de Sonhos - Marco Antônio de Queiroz (MAQ)
  • 250 Segredos para Web Designers - MOLLY E. HOLZSCHLAG
  • O design do dia a dia - DONALD A. NORMAN
  • Ser e o Nada - Jean-Paul Sartre
  • Apocalípticos e Integrados - Umberto Eco
  • Ergodesign e Arquitetura de Informação - LUIZ AGNER
  • The Art and Science of Web Design - Jeffrey Veen
  • Ansiedade de Informação 2 - RICHARD SAUL WURMAN
  • Criando Páginas Web com CSS - ANDY BUDD, CAMERON MOLL, SIMON COLLISON
  • Mobile Web Design - Cameron Moll
  • Sigam-me no Twitter

Me encontre

Lugares onde digitalmente eu costumo estar presente.

Anúncios

Blogroll:

Alguns sites interessantes e blogs de amigos que eu leio com frequência. Em ordem alfabética.

Pessoas que trabalham comigo:

Sites dos colegas de trabalho na Webroom.

Já trabalharam comigo:

Som que faz a minha cabeça!

Procurando inspiração? Esta é uma breve lista do que eu ouço!

  • Diana Krall - The Very Best Of
  • U2 - How to dismantle an atomic bom
  • U2 - 18 singles
  • The Essential - Bob Dylan
  • Bob Dylan - Modern Times
  • Miles Davis - Cool & Collected
  • Miles Davis - Prestige Profiles Vol 1
  • Pink Floyd - The Division Bell
  • Pink Floyd - The wall
  • Pink Floyd - Delicate Sound Of Thunder
  • John Coltrane - The Best of John Coltrane
  • The beatles - The Beatles 1