Esta é minha lista de artigos com a tag "doctype"

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.

Comentários: 30

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

Doctype – DTD – Document Type Definition

Por: Henrique Costa PereiraWednesday 17 May 2006 às 13:17

Introdução

Um documento de (X)HTML seguindo os padrões à risca nunca é completo sem utilizar uma declaração de tipo de documento corretamente. O Doctype de um documento deve ser o primeiro passo a se considerar antes mesmo de aprender qualquer tipo de sintaxe das linguagens de marcação como XML e XHTML. Porque é a escolha do doctype que vai influenciar no tipo de marcação que você deverá ou não utilizar. Se você quer aprender HTML 4 de forma a seguir corretamente todos os padrões você tem que trilhar um determinado caminho, e se quiser aprender XHTML também seguindo à risca os padrões, você deve seguir outro caminho com algumas diferenças.

Basicamente, tanto para o HTML quanto para o XHTML, você pode trabalhar com 2 tipos de doctypes, o transitional e o strict. Eu vou desconsiderar o frameset intencionalmente. A razão disso é que se alguém nos dias de hoje ainda trabalha com frames, usar um doctype mais ou menos apropriado não vai fazer diferença nenhuma no resultado final do trabalho na minha opinião. Se os frames não estão presentes nas recomendações para um documento strict, o que teoricamente deve apenas ter a sintaxe estrita (strict) de determinada linguagem, não vou considera-lo aqui.

Definição

“Doctype” é o acrônimo de “Document Type”, também conhecido como DTD (Document Type Definition). É o doctype que diz para os user agents qual o tipo de documento que ele tem que interpretar (parsing) e como ele deve renderizar esse documento. A definição de um tipo de documento (doctype) informa quais as regras que os user agents devem utilizar do que é e o que não é permitido em uma determinada versão de um XML e de um (X)HTML. É uma forma de dizer a eles quais são as regras que aquele documento pretende seguir e quais as regras que o browser deve utilizar ao analisar (parsing) o documento.

Diferenças CONCEITUAIS entre doctypes transitional e strict

O nome dos doctypes revelam o que são e para o que servem. O transitional é utilizado para quem está fazendo uma “transição” entre uma forma antiga de marcação para uma mais moderna e mais apropriada. Então se seu site não está livre dos velhos hábitos do passado, se a migração para strict seria muito trabalhosa, se seus documentos não seguem as regras á risca, você pode usar um doctype transitional. Você pode utilizar o doctype transitional enquanto você ainda utiliza muitas tags e marcações de forma inapropriada. Mas seu alvo final com o tempo deve ser escrever um documento que siga 100% os padrões de forma precisa com um doctype strict. Este é o alvo a ser seguido tanto para HTML 4 quanto para o XHTML 1, utilizar um doctype strict.

Para entender isso melhor vamos ver o que está escrito no Document Type Definition do HTML 4:

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.

Traduzido fica: “Este é o DTD do HTML 4.01 Strict, que exclui atributos apresentacionais e elementos que a W3C presume remover em estágios a medida que o suporte a folhas de estilos amadurece. Os autores devem usar um DTD Strict quando possível, mas utilize o DTD transitional quando precisar manter atributos e elementos apresentacionais.”

A principal razão de ainda existir outros doctypes que não sejam o strict, é porque velhos hábitos ainda persistem no desenvolvimento para web ao colocar sintaxe de apresentação no documento (X)HTML. A recomendação da W3C é que tudo que seja relativo a apresentação seja feito através de uma (ou mais de uma) folha de estilos externa. Se pensarmos em uma linguagem de marcação como o XHTML de forma estrita a seguir os padrões, um doctype transitional não deve nem ser considerado como uma “recomendação” e sim apenas como uma “aceitação” temporária por razões de retro-compatibilidade até o completo amadurecimento do desenvolvedor e da própria web.

Diferenças PRÁTICAS entre doctypes transitional e strict

Na prática, em um documento de HTML 4 com doctype transitional por exemplo, você pode usar uma dezena de tags e atributos como target, bgcolor, align, iframe, center etc mesmo que não sejam mais uma recomendação. Veja uma lista completa do que pode ou o que não pode organizado por doctype. A tag <center> por exemplo serve apenas para centralizar algum elemento. Ela não é uma recomendação da W3C por que trata-se de uma tag apenas para alterar a forma como um elemento deve ser exibido no browser, o que pode ser feito apenas por CSS, e não possui nenhum significado semântico. A tag <strong>, ao contrário do que muitas pessoas pensam, não serve para colocar texto em negrito, o que a caracterizaria como apenas uma tag de apresentação. A tag para negrito era <b> e caiu em desuso. A tag <strong> tem o significado semântico de “grande ênfase” e <em> tem o significado de “ênfase” apenas.

Documentos que utilizam doctypes strict na prática excluem qualquer tipo de tags e atributos com propósitos de apresentação, e doctypes transitional são mais permissivos e tolerantes a utilização de elementos e atributos que não são mais aceitos e recomendados na versão strict da linguagem.

A validação e os doctypes

Se seu documento possuiu algum tipo de sintaxe contrária as regras permitidas para o tipo de doctype que você está utilizando, isso é o que chamamos de “erro de sintaxe”. Óbvio não? Você não esperava outro nome não é mesmo? Ou seja, se você escolheu um doctype strict para seu XHTML, certas coisas que você estava acostumado a aplicar no seu HTML, seja ele strict ou transitional, não poderão ser mais feitas. O critério do validador de HTML da W3C para avaliar um documento é o doctype utilizado. A sintaxe é verificada de acordo com as normas permitidas para cada DTD escolhido. Se você escreveu determinado documento com uma sintaxe correta para XHTML mas utiliza um doctype de HTML 4 Strict, o validador vai acusar erros de sintaxe, mesmo que seu documento esteja 100% exato conforme a versão superior do HTML.

Se seus documentos possuem erros de sintaxe, os browsers vão ignorá-los e tentar renderizar seus documentos da forma em que cada um deles achar mais apropriado. Essa é a única importancia em manter um código válido e sem erros de sintaxe para não deixar nas mãos do browsers a escolha de como ele deve renderizar seu documento. E lembre-se que semântica nada tem haver com validação.

Na década de 90, devidos as implementações que cada nova versão dos browsers recebiam, e por causa da retro-compatibilidade, principalmente do Internet Explorer com as versões anteriores, os browsers foram treinados a renderizar os documentos que encontravam sem doctype a sua própria maneira. Se você não declarar nenhum tipo de doctype no seu documento, cada browser vai renderizá-lo de um forma diferente. Isso permitiu a expansão do HTML como uma tag soup. Isso ainda acontece com o HTML e o XHTML enviados com o mime-type de text/html. Para mais informações sobre mime-types, leia meu texto sobre “XHTML Media Types“. As diferentes formas de renderização são chamadas de “browsers modes”. Leia meu texto “O que é Quirks Mode?” para mais informações.

No caso do XML e do XHTML (enviado com o mime-type de application/xhtml+xml) essas variações de browsers modes não existem. Os browsers que suportam este tipo de mime-type possuem apenas a forma strict de renderização. Apenas duas coisas podem acontecer em documentos enviados como application/xhtml+xml. Ou o documento é exibido corretamente, se estiver tudo certo, ou nada dele é exibido. Se o browser não encontrar nenhum doctype, ele simplesmente não exibe nada. Apenas mostra uma mensagem de parser error na tela. Ele não tenta interpretar o documento a sua própria maneira como acontece com documentos com mime-type de text/html. Em linguagens baseadas no XML você realmente tem que saber o que você está fazendo caso contrário pode ser um completo desastre.

Para finalisar, veja abaixo os doctypes listados que podem ser encontrados nas referências normativas do HTML 4 e do XHTML 1.

Doctypes do HTML 4 :

A referência normativa (http://www.w3.org/TR/html4/sgml/dtd.html) do HTML 4 diz que você pode utilizar 3 tipos de doctype:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
  "http://www.w3.org/TR/html4/frameset.dtd">
 

Doctypes do XHTML 1:

A referência normativa do XHTML diz que você pode utilizar 3 tipos de doctype:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

Referências:

Comentários: 19

Tags: Browser HTML Semântica Web Validação W3C Web Standards XHTML XML doctype markup media-types mime-type padrões web quirks-mode text-html xhtml+xml



Paginação:



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