Texto original de Roger Johansson, 456 Berea Street Última atualização em 2006/03/12.
Traduzido para Português-BR em 03 de setembro de 2006 por Ricardo Augusto.
Traduções deste artigo estão disponíveis no site do autor original.
Este documento, que explica como usar web standards, fará você construir sites de uma maneira que economizará tempo e dinheiro para os desenvolvedores e promoverá uma melhor experiência para o visitante. Também são discutidos outros métodos, guias e melhores práticas que irão ajudar a produzir sites de alta qualidade que são acessíveis ao maior público possível.
Quando a Internet e a web se popularizaram, a partir da metade dos anos 90, os fabricantes de navegadores web ( browsers ) ainda não tinham implementado o CSS, Folhas de Estilo em Castata ( Cascading Style Sheets). Não havia suporte ao CSS suficientemente bom para desenvolvedores serem capazes de usá-lo. A falta de implementação era parcialmente compreensível, considerando que a especificação para o CSS Nível 1 foi publicado em 1996, e as especificações do CSS Nível 2 foram publicadas em 1998.
A falta de suporte ao CSS nos browsers, combinada com as demandas para os designers gráficos – acostumados com o nível de controle possível ao trabalhar com material impresso, levou ao uso abusivo do HTML como uma forma de se controlar esta camada visual da apresentação de uma página.
Um exemplo é a grande mudança causada pelo uso do atributo border="0". Os designers descobriram que ao usar esse atributo, era possível esconder as bordas de uma tabela e isso poderia ser usado para controlar o layout que era criado. Outro exemplo é o uso de um espaçador GIF transparente e invisível para controlar o layout.
Considerando que o HTML nunca foi planejado para ser usado para controlar a apresentação de um documento, os hacks, o código inválido, elementos (tags) e atributos específicos de cada fabricante de browser surgiram e foram amplamente utilizados. Validação de código era algo que pouquíssimos conheciam ou sequer tinham utilizado. Esse tipo de código recebeu o nome de Tag soup ( sopa de tags ) devido a essas características.
Na medida em que novas versões de browsers eram lançadas, o suporte ao CSS era melhorado e extendido, mas não na velocidade e amplitude que deveria ser. Apesar dos fabricantes de browser serem lentos ao implementar o suporte ao CSS, nós atingimos hoje um ponto onde os browsers que têm um suporte razoável ao CSS. Dessa forma, não há mais motivos para usar HTML que não seja para descrever a estrutura de um documento, e não a sua apresentação. Por essa razão, nós podemos usar CSS, que foi especificamente desenhado para esse propósito.
Web standards são tecnologias, estabelecidas pelo W3C ( World Wide Web Consortium ) e outros órgãos regulamentadores, usadas para criar e interpretar conteúdo baseado em web. Essas tecnologias são desenhadas para publicação de documentos na web o mais acessíveis possível e orientados às tecnologias do futuro.
Este documento é focado no XHTML 1.0 Strict para estrutura, CSS Níveis 1 e 2 para apresentação e ECMAScript 262 para scripts.
Quando é dito que uma página é compatível com os web standards, significa dizer que o documento, além de usar as tecnologias acima:
Observe que “funciona em qualquer browser” não significa “apresenta-se exatamente igual em todos os browsers”. Fazer que uma página apresente-se igualmente em toda uma variedade de browsers e plataformas é praticamente impossível. Nem mesmo usar apenas imagens fará um site parecer exatamente igual, em todo e qualquer lugar.
Documentos que são publicados na web serão acessados por uma ampla variedade de dispositivos de navegação, em diversos sistemas operacionais, com diferentes qualidades, tamanhos e resoluções de monitor ( até mesmo sem monitor ), por usuários que modificaram em seus browsers os padrões de tamanho de fonte e outras configurações. Aceitar isso fará sua vida muito menos frustrante.
Todos que criam sites precisam entender que há pré-requisitos técnicos a considerar, da mesma forma que publicar no papel ou fazer filmes ou televisão.
Desenvolvedores e designers web certamente têm resistência ao uso dos web standards. Respostas comuns são “É muito difícil”, “Tabelas funcionam do mesmo jeito” e “Os programas que eu uso geram código inválido”.
É fácil criar uma reação emocional e construir uma resistência ao aprendizado de algo novo a abandonar técnicas velhas que você já conhece e lhes são confortáveis. No entanto, se você olhar para a situação com lógica, você verá que há muitos benefícios em aprender e usar os web standards. Alguns exemplos:
Usar Web standards pode poupar tempo e dinheiro para os criadores de um site, além de promover uma melhor experiência aos visitantes. Além disso, web standards são o futuro. Se você não está usando os web standards ainda, agora é hora de começar, ou há um risco de você ser deixado pra trás.
Validação é o processo de controlar que um documento obedece as regras de linguagens deste documento. Você pode comparar esse processo a checar em um texto os erros de gramática.
Validação é uma parte importante do desenvolvimento web.
Muitos erros, que seriam difíceis de achar, são descobertos durante a validação. Um erro pode ser trivial como um erro de digitação, ou pode ser sério como um elemento ou atributo sendo usado de uma maneira incorreta.
Infelizmente, muitas pessoas não validam seus documentos. Alguns podem não conhecer sobre validação, outros esquecem completamente de validar, e ainda há aqueles que intencionalmente evitam a validação.
Os fabricantes de browsers podem ser acusados de causarem essa situação. Muitos browsers tentam interpretar HTML inválido da melhor forma que consequem, e tentam adivinhar qual era a intenção do autor, ao invés de exibir uma mensagem de erro. Esse comportamento levou ao código sujo, que é muito comum hoje em dia. O problema de usar esse tipo de código é que ele dá resultados imprevisíveis e se apóia em erros de interpretação dos browsers.
Não há motivos para não validar seu HTML e CSS. Pelo contrário, só há benefícios.
Why we won’t help you é uma excelente explicação de Mark Pilgrim sobre as vantagens da validação. Este artigo também explica como pode ser difícil ajudar pessoas em fóruns e listas de discussão se eles nem tentaram validar seus documentos antes de pedir ajuda.
Vários editores HTML, como por exemplo BBEdit e Dreamweaver, têm ferramentas internas de validação. Se o seu programa de desenvolvimento não as tem, você pode usar as que o W3C disponibiliza online:
Entender as mensagens de erro geradas pelos validadores pode ser um tanto difícil. Um erro no início do documento pode causar diversos erros adicionais. Fixar o primeiro erro do documento e revalidá-lo novamente pode, eventualmente, reduzir grande parte dos erros consequentes. Algumas mensagens de erro comuns são explicadas no artigo do Black Widow Web Design – Common XHTML Validation Errors.
É sempre uma boa idéia ter certeza que seu código é totalmente válido, mas há algumas poucas ocasiões em que alguns erros de validação são difíceis de serem evitados. O mais comum, por exemplo, é embeber Flash, ou outro conteúdo que requer um plugin no documento. Leia mais sobre os problemas com Flash em Flash Satay: Embedding Flash While Supporting Standards e Embedding flash without <embed>.
Quando é discutido web standards, algo que é muito mencionado é a importância da separação entre estrutura e apresentação. Entender a diferença entre os dois pode ser difícil no começo, especialmente se você está acostumado a não pensar em estruturação semântica de um documento. No entanto, é muito importante entender que controlar a apresentação de um documento com CSS é muito mais fácil quando estrutura e apresentação estão separados.
Estruturaconsiste nas partes principais do documento, na semântica e nas tags ( markup ) que ele contém.
Apresentaçãoé o estilo que você dá ao conteúdo. Em muitos casos, apresentação é sobre como o documento parece, mas pode afetar também como um documento é ouvido – nem todos usam um browser e um monitor para exibir imagens e gráficos.
Separe estrutura da apresentação o quanto puder. O ideal é que você tenha um HTML que contenha apenas a estrutura e conteúdo, e controle sua apresentação inteiramente pelo CSS. Separação de estrutura da apresentação não é muito comum na web de hoje. Em muitos sites, o código HTML não tem estrutura e semântica adequadas.
De modo a separar estrutura da apresentação, você precisa usar CSS ao invés de tabelas para controlar a apresentação de um documento. Quando você está acostumado a usar tabelas para layout, pode soar inconfortável e estranho, mas não é tão difícil como parece ser à primeira vista.
Há muita ajuda disponível na web, e as vantagens são tantas que, definitivamente, vale a pena tomar algum tempo para aprender um jeito diferente e necessário de pensar.
Outra parte importante de separar estrutura da apresentação é usar código semântico para estruturar o conteúdo do documento. Em um elemento HTML, o significado estrutural é adequado ao tipo de conteúdo. Logo, não há motivos para usar qualquer outra coisa. Em outras palavras, use CSS corretamente para fazer um elemento HTML parecer diferente de outro elemento. Exemplo: usar <span>ao invés de <h1>para um título.
Ao usar HTML semântico, você deixará as diferenças de significado evidentes a qualquer browser, seja este o mais moderno browser gráfico, ou um browser antigo que não suporta CSS, ou ainda, um browser baseado em texto em um console Unix.
Para marcar os títulos, use <h1>, <h2>, <h3>, <h4>, <h5>ou <h6>, dependendo do nível deste título. <h1>é o nível mais alto.
<h1>Título do documento </h1>
<h2>Subtítulo</h2>
<p>Parágrafos</p>
Parágrafos
Use o elemento <p>para marcar os parágrafos. Não use o elemento <br /> para criar espaços entre os parágrafos. Margens e espaços entre parágrafos são suportadas pelo CSS, e devem ser marcadas corretamente.
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.</p>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.
Uma lista de coisas deve ser marcada como uma lista. Há três tipos diferentes de listas em HTML: listas sem ordenação, listas com numeração, e listas de definições.
Listas sem ordenação ( unordered lists ), também conhecidas como listas de bullets ( marcadores, em inglês ), começam com <ul> e finalizam <ul>. Cada item da lista é contido em um elemento <li>.
Listas ordenadas ( ordered lists ) começam com <ol> e terminam com </ol>.
Listas de definição <dl> ( definition lists ) são um pouco diferentes, e podem ser usadas para marcar uma lista de termos e descrições. Listas de definição começam com <dl> e terminam com </dl>. Cada termo de definição ( definition term ) é descrito em um <dt>e a respectiva descrição da definição ( definition description ) é contida em um ou mais elementos <dd>.
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>
Resultado:
<ol>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ol>
Resultado:
<dl>
<dt>website</dt>
<dd>A collection of linked web pages that represent a company
or an individual.</dd>
<dt>web page</dt>
<dd>The basic unit of information on the Web, containing text,
graphics and other media.</dd>
</dl>
Resultado:
CSS torna possível usar listas mesmo quando você não quer que o conteúdo seja apresentado visualmente como uma lista tradicional. Uma barra de navegação, que é uma lista de links, é um bom exemplo disso. A vantagem de usar uma lista para menu é que o sentido será preservado para browsers que não suportam o CSS.
O elemento <q> deveria ser usado para citações ( quotations ) rápidas e inseridas diretamente ( in-line ) em parágrafos. Browsers deveriam renderizar automaticamente as marcas de citação ( quotation marks, “ “ ) antes e após o conteúdo do elemento <q>. Infelizmente, o Internet Explorer não entende isso e, em alguns casos, a tag <q>pode até mesmo causar problemas de acessibilidade. Por causa disso, alguns recomendam que você evite <q> e insira as marcas de citação manualmente. Citações em parágrafos ficariam, então, dentro de tags <span>, como uma maneira fácil de estilizar o conteúdo, mas totalmente sem significado semântico. Leia o artigo do Mark Pilgrim, chamado The Q tag, para um detalhamento maior nos problemas com a tag <q>.
Para citações maiores que um ou mais parágrafos, a tag <blockquote> ( blocos de citação ) deve ser usada. CSS pode ser usado para estilizar essa citação. Note que o texto deve ser marcado com tags de parágrafos <p>, e não diretamente dentro do <blockquote>.
O atributo cite pode ser usado para <q> ou <blockquote> se você quiser apontar a URL fonte da citação. Note que se você usar <span>, ao invés de <q>para citações inseridas ( inline ), você não pode usar o atributo cite.
<p>The W3C says that <q cite="http://www.w3.org/TR/REC-html40/struct/text.html#h-9.2.1">The presentation of phrase elements depends on the user agent.</q>.</p>
The W3C says that The presentation of phrase elements depends on the user agent..
<p>The W3C says that <span class="quote">“The presentation of
phrase elements depends on the user agent.”</span>.</p>
The W3C says that “The presentation of phrase elements depends on the user agent.”.
<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html">
<p>“The following sections discuss issues surrounding
the structuring of text. Elements that present text (alignment
elements, font elements, style sheets, etc.) are discussed
elsewhere in the specification. For information about characters,
please consult the section on the document character set.”</p>
</blockquote>
“The following sections discuss issues surrounding the structuring of text. Elements that present text (alignment elements, font elements, style sheets, etc.) are discussed elsewhere in the specification. For information about characters, please consult the section on the document character set.”
Use <em>para ênfase ( emphasis ) e <strong>para ênfase reforçada ( strong emphasis ). A maioria dos browsers modernos exibe o texto enfatizadoem itálico, e reforçadamente enfatizado em negrito. No entanto, isso não é um requisito, então para ter certeza de quão enfatizado um texto deve ser exibido, o melhor é usar CSS para controlar sua apresentação. Evite usar <em>quando tudo que você quer é, na verdade, um efeito visual.
<p><em>Texto enfático</em>é geralmente exibido em itálico, enquanto <strong>texto fortemente enfáático</strong>é exibido em negrito.</p>
Texto enfáticoé geralmente exibido em itálico, enquanto texto fortemente enfático é exibido em negrito.
Tabelas HTML não devem ser usadas para layout. Para dados tabulares, no entanto, as tabelas devem ser usadas. Para fazer dados tabulares mais acessíveis possível é importante saber sobre e como usar os vários componentes de uma tabela. Alguns exemplos são: cabeçalhos da tabela <th> ( table headings ), sumários ( atributo summary ) e legendas <caption> ( captions ).
<table class="exemplo" summary="This table shows the annual population increase in Sweden during the years 1999 to 2003.">
<caption>Aumento populacional da Suíça, 1999-2003</caption>
<thead>
<tr>
<td> </td>
<th scope="col">1999</th>
<th scope="col">2000</th>
<th scope="col">2001</th>
<th scope="col">2002</th>
<th scope="col">2003</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">População</th>
<td>8 861 426</td>
<td>8 882 792</td>
<td>8 909 128</td>
<td>8 940 788</td>
<td>8 975 670</td>
</tr>
<tr>
<th scope="row">Aumento</th>
<td>7 104</td>
<td>21 366</td>
<td>26 368</td>
<td>31 884</td>
<td>34 882</td>
</tr>
</tbody>
</table>
| Aumento populacional da Suíça, 1999–2003 | |||||
|
1999 |
2000 |
2001 |
2002 |
2003 |
População |
8 861 426 |
8 882 792 |
8 909 128 |
8 940 788 |
8 975 670 |
Aumento |
7 104 |
21 366 |
26 368 |
31 884 |
34 882 |
Mais descrições e detalhes das tabelas e uso, veja Bring on the tables, Tables in HTML documents e HTML Techniques for Web Content Accessibility Guidelines 1.0.
XHTML 1.0 é a reformulação do HTML 4 em XML 1.0, e foi desenvolvido para tomar o lugar do HTML. Observe que não há nada impedindo você usar HTML 4.01 para construir sites modernos, bem-estruturados e de acordo com os web standards.
No entanto, para fazer a transição para um código limpo e semântico, e bem preparado para uma possível transição para o XML em futuras linguagens de marcação, você deve considerar o XHTML 1.0 Strict. A escolha é sua.
O que importa mais, em HTML ou XHTML, é que você use um Doctype Strict e separe adequadamente a estrutura da apresentação. Os doctypes Strict não permitem que você insira código de apresentação em um conteúdo, e reforçam a separação entre estrutura e apresentação. XHTML 1.0 Strict é o que é usado nos exemplos deste documento.
XHTML 1.1, a versão mais recente do XHTML, é, tecnicamente, um pouco mais complicada de usar, sendo que a especificação diz que documentos XHTML 1.1 devem ter um MIME type como application/xhtml+xml, e não devem ser servidas como text/html. Não é estritamente proibido usar text/html, mas não é recomendado. XHTML 1.0, por outro lado, que deve usar application/xhtml+xml, pode também usar o MIME Type text/html, se for compatível com HTML.
O artigo do W3C, XHTML Media Types, contém uma visão geral dos MIME Types recomendados.
Infelizmente, alguns browsers mais antigos e o Internet Explorer, não reconhecem o MIME Type application/xhtml+xml, e podem acabar por exibir o código fonte ou até mesmo se recusar a exibir o documento.
Se você quer usar application/xhtml+xml, você deve deixar o servidor checar se o browser que está pedindo pelo documento pode suportar aquele MIME Type e, caso contrário, usar text/html para outros browsers.
Se você está usando PHP para script de servidor, o código a seguir contém o comportamento necessário para servir documentos com diferentes MIME Types, para diferentes browsers:
<?php
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
}
else {
header("Content-Type: text/html; charset=iso-8859-1");
header("Vary: Accept");
}
?>
O script checa se o agente ( user agent ) envia um cabeçalho Accept HTTP que contém o valor “application/xhtml+xml”, ou se o user agent é o Validador W3C HTML, que não envia um cabeçalho Accept HTTP propriamente dito, mas aceita application/xhtml+xml. Se algum dos dois é verdadeiro, então o documento é servido como application/xhtml+xml. A esses browsers é enviada também uma declaração de XML. Para os outros browsers, incluindo todas as versões do Internet Explorer, o documento é servido como text/html. Declarações XML, nesse caso, não são adicionadas ao documento, sendo que isso colocaria o IE/Windows no Quirks mode, algo que não queremos.
Após o cabeçalho de tipo de conteúdo ( Content-type header ), um cabeçalho variável ( Vary header ) é enviado para dizer aos caches intermediários, como proxy servers, que o tipo de conteúdo varia, dependendo das capacidades do cliente que está requisitando pelo documento.
Para scripts de negociação mais avançados, visite Serving up XHTML with the correct MIME type. Esse script toma a requisição do user agent e a converte de XHTML para HTML 4, antes de enviar o documento como text/html para user agents que não suportam o application/xhtml+xml.
Veja um script similar para quem usa APS e VBScript:
<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
Response.ContentType = "application/xhtml+xml"
Response.Write(" <?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>
Observe que, quando o MIME Type é application/xhtml+xml, alguns browsers, por exemplo o Mozilla, não exibirão documentos que contiverem erros. Isso pode ser bom durante a fase de desenvolvimento, mas pode causar problemas em um site dinâmico que é atualizado por pessoas que não são experts em XHTML, a menos que você assegure que todo o código permaneça válido. Se for esse o seu caso, você pode considerar a usar HTML 4.01 Strict então.
Aqui está uma lista das coisas que são mais importantes a considerar quando estiver usando XHTML 1.0 Strict, ao invés de HTML 4.01 Transitional ( ou sem nome, sujo e velho inválido HTML ):
<A HREF="index.html" CLASS=internal> <a href="index.html" class="internal"><img>.
< li>Item 1 <li>Item 1</li><p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p> <br> <br /> <img src="image.jpg" alt=""><img src="image.jpg" alt="" /> <input type="checkbox" id="checkbox1" name="checkbox1" checked><input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" /><font>, <center>, alink, align, width, height (para alguns elementos), e background.Atualmente, pouquíssimos documentos HTML tem um doctype ( DTD, Document Type Declaration ) correto e completo. Costumava ser mais decorativo do que funcional, mas há alguns anos, a presença de um doctype pode afetar seriamente a renderização de um documento no browser.
Todos documentos HTML e XHTML devem ter uma declaração de tipo de documento ( DTD, doctype ) para serem válidos. O doctype diz qual é a versão de HTML ou XHTML que está sendo usada pelo documento, e é usada pelo validador quando validar e para os browsers determinarem de que forma o conteúdo será renderizado.
Se um doctype correto e completo estiver presente no documento, vários browsers adotarão o modo de standards ( standards mode ), o que significa que eles seguirão o CSS o mais fiel possível. O documento também será renderizado mais rapidamente, pois o browser não terá de interpretar e tentar compensar o HTML inválido. Isso também reduz a diferença de renderização entre os browsers.
O doctype a seguir declara que o document é um XHTML 1.0 Strict, e fará os browsers trocarem o modo de interpretação de doctype ( doctype switching ) para o standards mode.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Todos os documentos XHTML deveriam especificar a codificação de caracteres.
A melhor maneira de especificar a codificação de caracteres ( character encoding ) é configurar o servidor web para enviar um cabeçalho de HTTP content-type com o código de character encoding. Para informações detalhadas sobre como fazer isso, cheque a documentação do software do seu servidor web que está em uso.
Se você está usando Apache Server, você pode especificar character encoding adicionando uma ou mais regras no seu arquivo .htaccess. Por exemplo, se todos os seus arquivos usam utf-8, adicione:
AddDefaultCharset utf-8
Para especificar um character encoding específico para uma determinada extensão de arquivo, use:
AddCharset utf-8 .html
Se o seu servidor web permite a execução de scripts PHP, você pode usar o seguinte trecho de character encoding:
<?php
header("Content-Type: application/xhtml+xml; charset=utf-8");
?>
Para servir suas págins como HTML, mude application/xhtml+xml para text/html. Se você, por qualquer razão, for incapaz de configurar seu servidor web e especificar o character encoding corretamente, use um elemento <meta>dentro do cabeçalho <head>do seu documento. É uma boa idéia especificar o character encoding desta maneira mesmo se o seu servidor estiver configurado corretamente.
Por exemplo, o seguinte elemento <meta>diz ao browser que o documento usa o character encoding de ISO-8859-1:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
Tendo sido costumeiramente usado mais para especificar propriedades e tamanhos de fontes, o CSS pode agora ser usado para controlar inteiramente o layout de um document. No entanto, para fazer isso eficientemente, uma abordagem diferente de tabelas para layout é necessária.
Semântica e boa estrutura do XHTML são necessárias para o CSS ser capaz de controlar o layout de uma maneira eficiente.
Como mencionado acima, o suporte dos browsers ao CSS tem sofrido um grande avanço recentemente. Infelizmente, todos os fabricantes de browsers não parecem estar interessados em implementar os padrões abertos do web standards, logo, o nível do suporte ao CSS varia de browser a browser. Há alguns bugs que fazer o browser agir de modos que não era previsto.
Atualmente ( 2004 ), os browsers que tem melhor suporte ao CSS são Mozilla ( e outros browsers baseados em Gecko: Firefox, Camino, Netscape6+), Opera e Safari ( e outros browsers baseados em WebCore ). O Internet Explorer 6/Win não possui o mesmo nível de suporte ao CSS, mas ainda assim é possível fazer muita coisa nele. Internet Explorer 5/Mac possui um suporte muito bom para CSS 1, mas não suporta muita coisa de CSS 2. As versões do IE 5.* suporta razoavelmente bem, mas há alguns problemas que você precisa estar atento. Versões mais antigas do Internet Explorar não possuem suporte que valha a menção. O mesmo vale para Netscape, nas versões anteriores à 6.
Como a maioria das pessoas usa o Internet Explorer para Windows, você terá de adotá-lo como o denominador comum mais básico. Isso não significa que você deve abandonar todas as habilidades que os browsers com melhor suporte ao CSS têm e deve sim aperfeiçoar o design para eles.
Nem todos browsers atualmente em uso tem o nível de CSS suportado necessário para renderizar um site que faz uso de todos os recursos do CSS. Afortunadamente, na maioria dos sites, apenas um pequeno percentual de visitantes está usando um browser muito antigo, incapaz de renderizar o layout de CSS corretamente.
É importante observer que essas pessoas não serão excluídas por completo. Nos anos 90, os scripts de checagem de versão de browser ( browser check scripts ) era um modo muito popular de redirecionar qualquer um que usava o browser “errado” ( naqueles tempos, geralmente qualquer coisa senão o Internet Explorer para Windows ) para uma página onde era dito que era necessário atualizar o browser para ganhar acesso ao site.
Hoje em dia você pode lidar com os browsers “errados” de uma maneira melhor. Uma grande vantagem de usar um código XHTML lógico, semantico e bem-estruturado é que seu documento será acessível e usável, mesmo sem o CSS. A apresentação – o jeito que o documento se parece, o estilo, não será a mesma da que em um browser com suporte ao CSS, mas o conteúdo estará lá, acessível. Na maioria dos casos, para vários visitantes, o conteúdo é, na verdade, mais importante do que o jeito que ele é apresentado. Por causa disso que é melhor enviar uma página sem estilos para browsers sem suporte, do que trancar o layout e conteúdo juntos no site.
Há várias maneiras de se fazer isso. Um jeito muito comum é usar o @import para vincular o documento a um arquivo CSS. Netscape 4 e browsers mais antigos não interpretam o @import, logo, não importará o arquivo CSS.
Há outros modos de esconder o CSS dos browsers. O ponto em comum a esses métodos é que eles são baseados nos bugs que os browsers têm ao interpretar o CSS. Isso significa que sempre existirá um risco de uma atualização de browser corrigir esses bugs que eram utilizados para esconder um CSS, mas não corrigir o problema do CSS. Então, quando menos você se apoiar em hacks de CSS, melhor.
Obviamente, você pode usar tecnologia no servidor para fazer uma checagem de browser e enviar-lhe o arquivo CSS ( ou nenhum ). Se você usar isso, tenha certeza de que a detecção está atualizada, para evitar de enviar o arquivo CSS errado quando um browser for atualizado, ou um browser completamente novo for lançado.
Há diversas maneiras de aplicar elementos CSS em um documento HTML.
Várias são as vantagens de deixar todas as regras em um ou mais arquivos CSS externos. Os documentos HTML serão menores, os arquivos CSS serão armazenados no cache do browser e serão baixados apenas uma vez, e você só atualizará um único arquivo para mudar a apresentação no seu site inteiro. Um arquivo CSS externo pode se parecer com:
h1 {
font-weight:bold;
}
Nota: não há o elemento <style>em um arquivo CSS externo.
Você pode vincular seu documento HTML a um arquivo CSS usando o elemento <link>:
<link rel="stylesheet" type="text/css" href="styles.css" />
ou usando uma regra @import em um elemento <style>:
<style type="text/css">
@import url("styles.css");
</style>
Usando o atributo style, você pode aplicar CSS diretamente em um elemento HTML:
<h1 style="font-weight:bold;">Rubrik</h1>
Isso deve ser evitado pois mistura estrutura e apresentação.
CSS Interno é contido em um elemento <style>, o qual pertence ao elemento <head>do documento:
<style type="text/css">
h1 {
font-weight:bold;
}
</style>
Isso também deve ser evitado, uma vez que é melhor deixar HTML e CSS em arquivos separados.
Uma regra de CSS consiste em um seletor e uma ou mais declarações. O seletor determina qual ou quais elementos HTML a regra afeta. Cada declaração consiste de uma propriedade e um valor. O bloco de declaração é cercado por { }, e cada declaração deve, terminar em ; ( ponto-vírgula ).
Uma regra simples de CSS é parecida com o trecho a seguir:
p {
color:#0f0;
font-weight:bold;
}
Nesse caso, o seletor é p, o que significa que esta regra afeta todos os elementos <p>no document. A regra tem duas declarações que, juntas, farão todos os textos contidos em elementos <p>serem verde e negrito, visualmente.
Para uma descrição mais detalhada das regras do CSS, veja CSS Beginner’s Guide, CSS from the Ground Upou um livro completo de CSS.
Quando se é iniciante do CSS, é comum cometer o erro de usar elementos XHTML desnecessários, classes supérfluas e <div> extras. Isso não significa necessariamente que o código está inválido, mas é uma contradição a uma das razões de separar estrutura da apresentação: código mais simples, enxuto e limpo.
Um exemplo de uso desnecessário de elementos XHTML:
<h3><em>Headline</em></h3>
Se era a sua intenção deixar o texto em itálico, use o CSS para estilizar os <h3>:
h3 {
font-style:italic;
}
Uso supérfluo de classes pode se parecer com isso:
<div id="main">
<div class="maincontent">
<p class="maincontenttext">
Lorem ipsum dolor
</p>
</div>
</div>
O trecho a seguir faz melhor uso:
<div id="main">
<div>
<p>
Lorem ipsum dolor
</p>
</div>
</div>
Para controlar elementos dentro do div#main, você pode usar seletores contextuais no código do CSS. Nesse caso seria assim:
div#main p {
/* regras */
}
Na maioria dos casos, o CSS pode ser usado para estilizar logicamente o XHTML de uma maneira que você não precisará adicionar nenhuma tag extra. No entanto, há casos que adicionar um código extra é a única solução.
Obviamente, quando você comecar a usar o CSS seriamente, você terá alguns problemas. Eles podem ser causados por mau uso, outros por especificações incorretas ou ainda, por browsers problemáticos (buggy ). A seção do Mezzoblue, CSS Crib Sheet é uma coleção de boas dicas, compiladas pelo Dave Shea. Aqui vão algumas das dicas mais importantes e, adicionalmente, algumas dicas que não estão no CSS Crib Sheet.
Suponha o seguinte trecho de CSS:
div.box {
width:300px;
padding:20px;
border:10px solid;
}
A largura total deste div é de 360px.
10px + 20px + 300px + 20px + 10px = 360px
No Internet Explorer 5.*/Win, a largura total é 300px, e a largura do documento é 240px.
300px - 10px - 20px - 20px - 10px = 240px
Para contornar esse problema, você pode tanto adicionar um hack de CSS para fornecer valores diferentes aos browsers e corrigir isso, ou você pode evitar especificar tanto width epadding ou border for para um mesmo elemento.
Para mais explicações no CSS Box Model, veja o documento Box model.
Os nomes dos elementos são sensíveis à variação de maiúsculas/minúsculas quando usados com XHTML servido com application/xhtml-xml, mas não em HTML ou XHTML servido como text/html.
Há muitos exemplos e tutoriais passo-a-passo sobre como usar CSS para layout. Um bom conselho é começar com um layout simples, aprender como funciona, daí partir para layouts mais avançados.
Acessibilidade não é apenas oferecer suporte adequado a deficientes, mesmo se esta for uma das mais importantes razões para fazê-lo. Um site acessível funciona melhor para todo mundo, deficiente ou não, e pode ser acessado por mais pessoas e por mais tipos de browsers e outros dispositivos de acesso à internet.
Um mal-entendido muito comum ao fazer um site acessível é que este parecerá bem menos atrativo, ou diferente de um site que não é acessível. Este não é o caso. Acessibilidade não afeta, necessariamente, a camada de apresentação, de modo algum.
Um exemplo de como a acessibilidade pode ajudar a todos: um site possui um formulário que pode ser usado para os visitantes registrarem-se para um seminário. No formulário, você pode escolher entre 3 cidades para ir ao seminário. Cada nome de cidade aparece ao lado de um radio button ( <radio> ). Se o criador do formulário não se preocupou com acessibilidade, qualquer um que usar um browser gráfico terá que posicionar o cursor do mouse acima do pequeno ( minúsculo ) radio button e clicá-lo para escolher a cidade. Se o desenvolvedor conhecer algo sobre acessibilidade, e tiver marcado o código com etiquetas ( <label> ) para cada item, você será capaz de clicar diretamente no nome da cidade para escolher a localidade. Qual dos modos é mais simples para se interagir com o formulário?
Usar um XHTML bem estruturado e semântico colocará você bem à frente no caminho de tornar seu site acessível. Para ter uma idéia de como um documento acessível é, tente vê-lo em um browser textual como o Lynx, para ver como o conteúdo ainda faz sentido. Isso ainda é apenas um checklist de acessibilidade a fazer, mas é um bom começo.
Muitos web designers gostam de usar frames para dividir a janela do browser em várias partes independentes, cada uma consistindo de um documento HTML separado. Isso pode ser útil para algo como uma aplicação de Intranet. Em um site público, no entanto, há vários pontos contra usar frames:
Além disso, você está fazendo as coisas mais difíceis pra você mesmo. Frames fazem um site tecnicamente mais complexo.
É muito comum as pessoas interpretarem o dito “não use tabelas para layout” erroneamente em “jamais use tabelas”. Isso é um erro. Se você está marcando código que é um dado tabular, que pertence a uma tabela, então a tabela deve ser usada. No entanto, é importante saber que, ao construir tabelas de dados, há muitas maneiras de fazê-la mais lógica e acessível.
Formulários são, as vezes, desnecessariamente difíceis de usar, em parte porque eles são construídos de maneiras ilógicas, em outras, porque o código HTML não faz uso de elementos que existem para fazer os formulários mais acessíveis e fáceis de usar. Os elementos <label>, <fieldset> e <legend> existem e foram planejados para isso.
Uma questão comum é o que usar para criar o layout de um formulário. Alguns dizem que o formulário pode ser considerado dados tabulares, e deve ser marcado com tabelas, enquanto outros dizem que apenas CSS deve ser usado. Use qualquer modo, mas se você usar tabela, tenha certeza de que o formulário faz sentido se o seu conteúdo for posto em uma linha contínua, linearizado.
JavaScript e Cookies
Evite depender exclusivamente do JavaScript. Muitas pessoas que você pensa que possuem suporte ao Javascript, o desabilitaram de algum modo em seus browsers – seja por motivo de segurança ou para evitar as janelas pop-up. Eles podem estar usando um browser que não suporta JavaScript completamente. De acordo com o TheCounter.com, 6% dos usuários de web não tem suporte ao JavaScript. W3Schools.com diz que estes representam 8%.
Em muitos casos onde o JavaScript é utilizado, ele não beneficia realmente o visitante. Claro que há casos onde o JavaScript pode ser usado para promover uma melhor experiência ao usuário. Um exemplo é a validação de uma entrada de formulário.
Observe que isso não significa que você deve evitar usar completamente JavaScript. Significa que você deve evitar fazer um site que dependa exclusivamente de JavaScript para funcionar.
O mesmo vale para cookies. Não faça sites que dependam de cookies e que param de funcionar se o visitante não aceitá-los.
Esta sessão não é de fato sobre web standards ou acessibilidade, mas está aqui pois o jeito que uma URL é construída pode ter um grande efeito em como um site é bem ou mal indexado por robôs de busca, e como é usável a seus visitantes.
Alguns robôs de busca não seguem links de URLs que terminam em strings de consulta a um banco de dados. Esse tipo de URL é muito comum em sites que buscam conteúdo dinamicamente de um banco de dados e se parecem com isso:
http://exemplo.com/products.asp?item=34627393474632&id=4344
O jeito mais simples de construir uma URL que é melhor para ambos robôs de busca e seres humanos, é mudar a maneira como ela aparece e apontá-la para um diretório. O exemplo acima foi transformado em:
http://exemplo.com/products/item/34627393474632/id/4344/
O servidor web interpreta a URL e, internamente, a converte para a URL original, completa, com a string de consulta ao banco de dados. No final dessa sessão há alguns links para sites onde é possível encontrar informação sobre como isso é feito.
Um jeito melhor ainda, mas tecnicamente mais complicado de ser implementado, é mudar completamente a URL para algo que nós conseguimos entender:
http://exemplo.com/products/flowers/tulips/
As vantagens de usar essa terminologia na URL é que os robôs de busca irão indexar o conteúdo melhor, e será mais fácil para nós lembrarmos da URL, além de você evitar de exibir que tecnologia de servidor você está usando. Uma vez que as URLs não contêm extensões específicas de arquivo, como .asp, .cf, .cgi ou .jsp, será mais fácil mudar de tecnologia no servidor, caso seja necessário.
Se você optar por usar strings de consulta na URLs, é importante codificar todos os & para a entidade HTML correspondente: &. Caso contrário, alguns browsers irão, como deveriam, ver o & e iniciar uma entidade HTML, e se o texto a seguir for exatamente uma dessas entidades, o browser a converterá para o caracter, em muitos casos quebrando a URL e a string de consulta.
Outra coisa que vale mencionar é que para a maioria dos sites, usar um subdomínio www é desnecessário, e que http:// examplo.com/ deveria ser usado ao invés de http://www.examplo.com/. Mais informação sobre isso pode ser achada em . Seja com subdomínios www ou sem, é uma boa idéia configurar seu servidor web para redirecionar todo o tráfego de http://examplo.com ou http://www.examplo.com/ para a mesma URI.
Uma seleção de livros recomendados, sites e listas de discussão.
© Copyright 2004–2006 Roger Johansson