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.