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

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.

  • Tárcio Zemel

    É… 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.

  • http://www.techzine.com.br Rael B. Riolino

    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 ?

  • Carlos A. Ferrari

    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

  • http://project47.viscountbox.com Carlos Eduardo

    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…

  • Lucas Ces

    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".

  • Douglas d'Aquin

    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

  • Rogério Brum

    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.

  • http://jaderubini.wordpress.com/ Jader Rubini

    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…

  • http://www.thalisvalle.com Thalis Valle

    Espero que o pessoal já esteja careca, disso…

  • http://www.zhp.com.br Henrique Pimentel

    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.

  • João Vagner

    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.

    :)

  • http://www.eugeniogrigolon.com/ Eugenio Grigolon

    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.

  • Igor Escobar

    E ponto final =)

  • Douglas d'Aquin

    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

  • http://www.agenciaclickisobar.com.br/ Matheus Henrique

    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

  • Gustavo Straube

    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.

  • Flávio Ara&ua

    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

  • http://tcelestino.blogspot.com Tiago Celestino

    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.

  • Pingback: Qual o papel dos web standards na arquitetura da informação? » Revolução Etc - Web Standards em uma casca de noz!

  • Pingback: Quem deve se preocupar com os padrões web? » Revolução Etc - Web Standards em uma casca de noz!

  • Pingback: Desenvolvimento em camadas « Blog do Jader

  • Pingback: Boas práticas não é xiitismo » Revolução Etc - Web Standards em uma casca de noz!

  • Pingback: Princípio de pareto: A teoria 80/20 aplicada ao desenvolvimento de web » Revolução Etc - Web Standards em uma casca de noz!

  • Pingback: » A Arte do SEO / Tecnocracia : Estado Tecnológico

  • Pingback: Nagüeva » Blog Archive » Definindo a linguagem padrão da folha de estilos de um site

  • Pingback: Nagüeva » Blog Archive » Definindo a linguagem padrão do estilo aplicado no HTML

  • Pingback: CSS Hacks ou comentários condicionais? « O Webmaster

  • Leon Santiago

    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.

  • Pablo Demier

    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

  • Pingback: Diego M. Quinteiro – Webmaster » CSS Hacks ou comentários condicionais?

  • Gabriel

    Concordo com o Pablo, em email marketing é a única opção. E eu acho nada a ver declarar tudo num arquivo externo CSS. Ai vc tem que ficar dando ID ou CLASS pra tudo…. pra fazer algo simples.
    ou vamos supor que tenho 3 div da classe NEWS e eu quero que cada uma tenha uma largura diferente, ai eu uso o style="" pra mudar o width de cada um = mt mais fácil