Atenção: Não estou falando da doença anorexia nervosa. Esse artigo faz apenas uma comparação humorística sobre uma linguagem tecnológica e não tem intuito ofensivo.

Uma prática muito comum no HTML é tornar os elementos anoréxicos, sendo os mais afetados as âncoras e imagens, embora outros elementos poderiam dar uma boa engordada.

Por padrão as âncoras (o elemento a que forma os links) no HTML não requerem nenhum atributo por padrão, embora seja comum usar o atributo href (por motivos óbvios).

Um exemplo de âncora anoréxica seria essa:

<a href="http://www.acordapraweb.com">site interessante</a>

Apenas a ligação em si é definida, e mais nenhuma informação sobre o destino dela é determinada. Uma pena.

Vamos ver agora uma âncora saudável, corada e em boa forma:

<a href="http://www.acordapraweb.com" title=”Acorda pra Web! - Web Semântica” hreflang=”pt-br”>site interessante</a>

Olhem! Dá até gosto de ver. Além da ligação essa âncora informa ao HTML qual a lingua da página de destino (usando o atributo hreflang) e atribui um título explicativo à mesma (atributo title). Uau!

Uma das âncoras mais bem comportadas, que come bem e fica gordinha, são âncoras de arquivos para download. Por exemplo, nessa:

<a href="http://www.acordapraweb.com/compatibilidade.html" title=”Acorda pra Web! - Tabela de Compatibilidade CSS” hreftype=”text/html” hreflang=”pt-br” rel=”enclosure”>Compatibilidade CSS em navegadores</a>

O atributo hreftype define o tipo de arquivo do link. Nesse caso foi text/html, mas você pode especificar application/zip para arquivos compactados em zip por exemplo.

Outro atributo interessante é o rel com valor enclosure. Esse é um dos microformatos essenciais, que define que o conteúdo daquele link deve ser tratado como um download.

*Imagem por Peter Werner

Recentemente rolou na Blogosfera uma discussão sobre links, se devem ou não e quando devem ser abertos em novas janelas.

As soluções apresentadas foram várias, mas nenhuma me satisfez. Eis aqui todas elas e no final a minha própria solução:

O bom e velho target=_blank

Essa solução é a mais simples, você escolhe os links que quer abrir em novas janelas adicionando o atributo target com valor _blank ao elemento do link.

É uma solução incorreta, porque o atributo target é depreciado por não ser semântico.

O novo rel=external

A solução mais correta é o atributo rel com valor external. Semanticamente ele mostra que seu link não é interno no site, ou seja, aponta para um domínio de fora.

Infelizmente os navegadores não lêem que isso deve ser aberto em uma nova janela, o que acaba tornando necessário um script para fazer a mágica:

function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i=0; i<anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute(”href”) &&
anchor.getAttribute(”rel”) == “external”)
anchor.target = “_blank”;
}
}
window.onload = externalLinks;

O Último Problema e a Última solução

Com as duas técnicas acima, qualquer usuário que entrar na sua página abrirá os links externos em uma nova janela, ele não terá opção de escolha.

O ato de abrir em uma nova janela é mais comum a pessoas que fazem pesquisa e não leitura, e geralmente usuários avançados não gostam que o site abra automaticamente em uma nova janela.

Pra evitar isso, o correto seria fazer com que links contento rel=external abrissem novas janelas somente quando o usuário viesse de algum sistema de busca.

O script em PHP à seguir identifica quando um usuário vem do Google ou Yahoo e somente ativa a abertura de novas janelas para esses visitantes:

<?php
if (stristr(getenv('HTTP_REFERER'),"google")||stristr(getenv('HTTP_REFERER'),"yahoo")) {
echo <<<extlinks
<script type="text/javascript"><!--
function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i=0; i<anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute(”href”) &&
anchor.getAttribute(”rel”) == “external”)
anchor.target = “_blank”;
}
}
window.onload = externalLinks;
</script>
extlinks;
}
?>

Se você tem WordPress, pra implantar essa solução, basta copiar o código acima e incluir no template Header, logo acima do fim da tag </head>. Se alguém souber fazer um plugin pra isso (eu não sei) eu gentilmente coloco o link e créditos aqui

Fácil né?

O título significa “um elegante (posh) beijo (kiss) seco (dry)” em um péssimo inglês, mas não se asssustem! Não vou falar sobre sentimentos.

POSH, DRY e KISS são três siglas, cada qual correspondente a uma metodologia de desenvolvimento web. Siglas são legais porque são uma boa maneira de divulgar a coisa toda.

A primeira que ouvi foi a KISS, (Keep it simple, stupid), que prega a metodologia de manter as coisas simples, não complicar demais. Isso vale tanto pra programação, interface, HTML, CSS e até pra vida (não, o Acorda pra Web não é um blog de auto-ajuda).

DRY (Don’t repeat yourself) é uma característica que vi pela primeira vez no framework Ruby on Rails. Faça as coisas focando não repetir o que já foi feito. Isso economiza tempo, facilita manutenção e evita erros na hora de programar.

E finalmente POSH (Plain old semantic HTML) é a mais recente delas, surgiu em uma discussão sobre Microformatos. Não é nada muito novo, apenas reforça algumas idéias na hora de desenvolver de acordo com os padrões:

• Valide a marcação, em primeiro lugar.
• Se livre das tags de apresentação, fique com conteúdo apenas.
• Se livre de tabelas e gifs espaçadores.
• Não construa links anoréxicos. (Coloque o atributo title, atributos rel, classes e enriqueça seu link :)).
• E tudo de bom que o HTML pode nos oferecer!

Nem vou me preocupar aqui em colocar links e definições sobre essas boas-práticas, eu só vim mostrar mesmo a sigla. Se alguém te encher com conversas de padrões versus tabelas, POSH nele.

Esse blog é minha primeira experiência com WordPress. À princípio eu odiei pela falta de semântica no HTML e dificuldade pra editar os templates.

Eu gosto muito de ter uma visão geral do template pra montar o CSS e o WordPress me entrega ele todo em pedacinhos. Pra construir pela primeira vez até que não dói tanto, mas a manutenção é um sofrimento só. Pelo menos já acostumei com isso.

Ele também não é muito rápido, o desenho do banco de dados em MySQL é meio estranho e confuso, não parece otimizado. Inclusive já pensei em adotar o LightPress (uma modificação do WordPress), só voltei atrás pela falta de suporte à plugins.

O que mais gosto no WordPress inclusive é a diversidade de plugins. É perfeitamente possível montar praticamente qualquer tipo de página com o WordPress, desde um fórum até uma loja virtual.

Ele até deixa você editar os templates, estilos e tudo mais, mas não incentiva que você o faça. As páginas ficam todas muito parecidas e mal-acabadas. Admiro quem consiga deixar um WordPress com visual bonito e livre do “padrão” de qualquer outro tema.

Customizar o WordPress é difícil. Eu gostaria até de algumas dicas, alguém tem?

Enquanto isso eu fico aqui, aproveitando a versatilidade dele, aguardando pelo CMS ideal (que talvez seja o SemSol).

Até o momento desse post 8.030 pessoas já linkaram para o CSS Zen Garden. Ele é mundialmente aclamado por todo mundo como uma excelente iniciativa. Alguém aqui lembra o objetivo do CSS Zen Garden? Eis alguns:

• Mostrar que o CSS é bonito e que designers devem usá-lo
• Promover os padrões Web, especialmente o CSS
• Mostrar que podemos ter infinitos CSS com um único HTML

O HTML do CSS Zen Garden, pela época em que foi criado, é monstruosamente lindo! Ele foi criado pensando justamente no objetivo de nunca mais ser tocado.

Se você abrir o HTML deles agora (e estou realmente sugerindo que o faça) verá que as classes e ids são (quase) todos semânticos: intro (Introdução), quickSummary (Sumário Rápido), explanation (explicação) e todos os demais. Ele não fala de cima, baixo, esquerda, direita ou barra lateral e justamente por isso ele é tão bom! Porque ele foi projetado sem nenhum layout em mente, somente conteúdo.

E qual é a grande lição que o CSS Zen Garden nos dá? Temos que marcar o HTML como se nunca mais pudessemos mudar, visando somente o conteúdo e não o layout.

A prova de que funciona ta aí.

É bem comum ver sites colocando a logomarca marca através do CSS no layout, só que a prática não é muito correta.

Não devemos confundir também a palavra logomarca com logotipo.

Devemos entender direito o que significam alguns elementos que compõe uma marca:

• Logomarca é uma imagem que identifica uma marca, no caso aqui do blog é aquele relógio em perspectiva no topo.
• Marca é a representação de uma entidade, seja pelo logotipo, símbolo, uma frase ou qualquer elemento de identificação
• Logotipo é um texto utilizado para compor o nome da empresa.
• Símbolo é um elemento que ajuda a identificar uma determinada Marca.

Geralmente a logomarca (o símbolo) carrega um significado consigo, como o relógio aqui do Acorda pra Web tem correlação com “despertar”, “acordar”. Um outro exemplo seria o símbolo do MeioBit que ilustra um meio bit (que eu acho excelente).

Uma prática muito comum é criar o HTML e colocar o nome do site usando a marcação <h1>Nome do Site</h1> e depois escondendo o texto e colocando uma imagem de fundo através do CSS, com a técnica de Image Replacement.

O fato é que quem desabilitar o CSS na página, não verá a sua logomarca (o seu símbolo), assim como ele pode não aparecer em alguns dispositivos portáteis.

Colocar a logomarca o símbolo através da tag <img src="logo.jpg" title="Nome do Site" alt="Nome do Site"> é uma maneira prática, correta e segura de sempre garantir que a logomarca (o símbolo) seja exibido e marcado corretamente.

Se você nem liga para quem habilita ou não o CSS em suas páginas ou não tem foco em usuários de portáteis, tanto faz, mas deixo aqui minha pequena dica, que é só um complemento dessa dica aqui dada pelo Elcio.

Atualização: Fui corrigido por diversos blogueiros sobre o uso da palavra “logomarca”, tentei consertar na medida do possível! Meu post foi sobre semântica no HTML e não sobre termos de mercado, termos esses que confesso: desconheço totalmente. Agradeço pelos esclarecimentos e comentários!

No último post sobre Semântica no HTML o Pedro sugeriu nos comentários a conhecida técnica de usar a tag <pre> dentro da tag <code> para manter a identação e as linhas.

É uma alternativa tentadora! Infelizmente ainda não é a solução ideal pra exibir código.

A tag <pre> é uma tag muito controversa. Ela deve ser usada somente quando o conteúdo depende dos espaços e quebras de linha para existir semanticamente.

Onde Não Usar <pre>

Naturalmente, todo código tem essa característica de manter identação original e quebras de linha, portanto a tag <pre> não adiciona semântica alguma nesse caso. Comparando, a técnica <code><pre></pre></code> seria como usar um <strong><b></b></strong>, é algo redundante.

Ainda nos faltam alternativas pra identificar cada linha do código. Quando falamos em código é comum ouvir “tal código tem tantas linhas”, “veja a linha tal de tal código” e por aí vai. No XHTML2 existe a tag <l> com esse propósito.

Onde Usar <pre>

Um exemplo simples são letras de música. Versos não são exatamente parágrafos e não existe uma tag específica para versos. Isso se aplica em poesia também. Ao invés de colocar cada verso em um <p> ou usar vários <br /> você coloca a letra de música dentro de um <pre>, para preservar as quebras de linha, porque elas representam a metragem da música/poesia.

Essa semana no Tableless o post foi sobre semântica no HTML, falando sobre listas de ações.

Dos problemas com semântica, sem dúvida, listas é um dos menos preocupantes! Algumas brechinhas no HTML deixam a desejar em alguns aspectos e confundem quem está formatando o texto.

Um excelente exemplo dessa confusão é a tag <code>. Ela foi criada para exibir pequenos trechos de código, como esse no qual acabei de colocar a tag. Como podemos ver na especificação do HTML4 (e no XHTML também) ela é um elemento inline por natureza.

A dor de cabeça começa quando precisamos exibir blocos de código. Coloca em um só <code>? Coloca cada linha do bloco em um <code>? Se é um por linha o que coloco pra definir o bloco?

A alternativa mais simples é utilizar somente um <code> e quebrar as linhas de código com <br />. Isso mantém o código em uma linha só, como prometido na especificação, e quebra essa linha em várias para nos dar ilusão de múltiplas. Não é uma aberração semântica, mas também não é o correto:

HTML
<code>
SELECT nome, email, telefone<br />
FROM tabela<br />
WHERE nome = "João"<br />
</code>

A alternativa mais próxima do correto seria algo assim:

HTML
<code>SELECT nome, email, telefone</code>
<code>FROM tabela</code>
<code>WHERE nome = "João"</code>

Adicionalmente, você pode cobrir todas as linhas de código com um elemento só, usando um elemento<blockquote>, porque de fato exibir um bloco de código é citar alguém, ou apenas usando um <p class="code">.

No XHTML2 já pensaram nisso e criaram o <blockcode>, no Web Applications 1.0 (um tipo de HTML5) ainda não mostraram solução para esse problema.

E vocês? como exibem blocos de código em uma página?