Código Bala!

O Wordpress 2.5 é fabuloso. Vi gente meio horrorizada quando testou, mas assim que se quebra o estranhamento natural de ver uma interface antiga substituída por uma nova, é puro deleite.

O redesign foi feito pela HappyCog, dos meus ídolos Jeffrey Zeldman e Jason Santa Maria. Eles pertencem ao farol que deveria guiar sempre design e desenvolvimento para web.

Há alguns minutos procurei informações sobre o ingresso de um show que pretendo assistir na semana que vem (Fernanda Takai, para os curiosos). Insatisfeito com o serviço de todos os guias culturais online da cidade de Porto Alegre, resolvi depositar minhas esperanças no site da produtora do evento. De fato, encontrei o que procurava (data, preços) de forma rápida, mas notei algo bastante interessante.

Está aí um exemplo do que acontece quando se negligencia a semântica do código de marcação do seu site. Associando-se uma navegação em Flash, temos mais que problemas de acessibilidade e usabilidade: o site é encontrado, mas a descrição dele não faz sentido algum. E pior, nesse caso: revela detalhes internos da produção (como esse comentário sobre o header), bastante dispensáveis num lugar tão nobre quanto a primeira colocação de um resultado de busca do Google.

Fiz uma busca por algo bastante determinado, pois já sabia que a Opus estava envolvida com o concerto. Mas se eu tivesse procurado por algo genérico, porém óbvio, como “fernanda takai porto alegre”, nada teria encontrado relacionando os dois. Pelo menos até a terceira página de resultados, o site da empresa não apareceu.

Advertência: a palavra indentar é um neologismo. Não existe na língua portuguesa. Endentar aparece em alguns dicionários, mas não tem o mesmo sentido. Então, será adotado nesse blog o indentar que, assim com scanear, parece não ter nenhuma tradução adequada.

Bem, a pergunta do título é bem direta: você indenta seu código HTML? E o CSS? Essa é uma questão que pode parecer estranha entre programadores. Mas nós, front-end developers, estamos lidando com uma linguagem de marcação. O que fazer?

No meu caso, sempre combati a indentação em meu código. Sempre odiei a hierarquização automática gerada pelo Dreamweaver, que acabou virando regra na maioria dos casos. Até mesmo quem escreve código no bloco de notas acaba se acostumando a encher tudo de tabs, para dar uma organizada melhor, mas eu sempre achei isso muito mais confuso e dispensioso. Sem falar que, na soma final, acabava consumindo alguns bytes a mais, o que em projetos mais complexos realmente pode ter um peso indesejado.

Durante anos, também me acostumei a escrever meu CSS na horizontal. De novo, em projetos complexos, dava maior legibilidade a um bando de classes e IDs. Só que isso andou mudando.

Desde que adquiri minha cópia do Expression Web, parei um pouco de lutar contra a indentação automática. Em uma fase de testes e, aproveitando para treinar minha mente, tenho me esforçado duramente para manter tudo absolutamente hierarquizado no espaço de codificação, com resultados variáveis. No meu novo site pessoal, o CSS está indentado, mas o HTML segue o padrão antigo que usava. E se você conferir o CSS deste blog, poderá entender a que me referia quando falei sobre classes e IDs escritos na horizontal.

Ainda não decidi o que é melhor, mas nos dois últimos projetos em que trabalhei, indentei tudo. Logo devo fazer um teste de medir o peso dos documentos, nas duas formas, e ver se existe realmente alguma vantagem real em um ou em outro.

Como todo desenvolvedor também venho acompanhando, com um misto de curiosidade e temor, a discussão que gira em torno do próximo passo em linguagem de marcação para a Web.

Para resumir a questão: há uma divisão de gente trabalhando no HTML 5, alguns dentro do W3C, outros do lado de fora. Fora isso, temos as polêmicas documentações do XHTML 2.0 e as diretrizes de acessibilidade do WCAG2.0, que foram rechaçadas por quase toda a comunidade, que acabou na sua maioria abraçando uma errata da primeira versão.

No olho do furacão está o W3C, pretensamente vivendo uma crise de identidade e de liderança que já foram inquestionáveis no meio. Gente como o Zeldman acha que se está fazendo muito barulho por (quase) nada, mas reina uma desconfiança nunca antes vista em relação ao órgão que costumava balizar quase tudo no que diz respeito a desenvolvimento.

Em artigo essa semana no A List Apart, Lachlun Hunt dá uma geral na situação do HTML 5, esclarecendo alguns pontos que andavam um tanto obscuros. Há mais gente ajudando o W3C no projeto, o que é algo muito saudável para chegar-se a uma solução mais democrática. De organizações não-governamentais a empresas, parece haver um grupo bastante plural dando pitacos nos trabalhos.

No entanto, novos desenlaces estão gerando mais discussões acaloradas. Fora a previsão de término do projeto daqui quinze anos, há alguma polêmica com o novo modelo de marcação e as tags que serão usadas para isso.

Segundo o texto ilustrou, o que temos hoje em XHTML assim:

<div id=”header”></div>

<div id=”nav”></div>

<div id=”article”>

<div id=”section”></div>

</div>

viraria:

<header></header>

<nav></nav>
<article>

<section></section>

</article>

O argumento é que isso é mais claro, organizado e semântico no que diz respeito à interpretação correta dos elementos pelos dispositivos utilizados durante a navegação.

Mas será que isso não tornaria o HTML algo excessivamente específico? Apesar de longe do ideal no que diz respeito à organização, o XHTML 1.0 permite uma boa flexibilidade com o emprego de IDs. Quem conhece web standards sabe onde os elementos devem ser usados, que <h1> é um título de nível um e assim por diante. Entretanto, poder jogar com DIVs para fazer a divisão do código conforme a disposição do conteúdo é uma grande vantagem, ao meu ver.

O projeto, como visto, está longe de estar pronto. A discussão que surge até agora só beneficia todo mundo. Mas na hora de dar o passo adiante e adotar o novo caminho, não se pode prever se será um sucesso ou um grande tiro no pé.

Um dos paradigmas mais recorrentes no momento de conceber uma interface para a Internet diz respeito a um mito que tornou-se bastante popular com o passar dos anos: o de que usuários não usam a barra de rolagem (scroll) para navegar pelo conteúdo. Isso se origina de uma premissa parcialmente verdadeira, o que produz a confusão citada. Usuários não usam o scroll se a navegação não for fluida o suficiente, ou se ela não fornecer elementos que justifiquem tal ação.

Outro mito antigo, que já caiu por terra há um bom tempo, é de que os usuários só navegam pelos links fornecidos dentro do site em si. Isso é um absurdo, dado que já é senso comum que o botão "voltar" do browser, por exemplo, é o segundo elemento de navegação mais utilizado, depois dos próprios hyperlinks (NIELSEN, 1999). Ainda assim, pessoas continuam tentando interferir nas escolhas do usuário, que é quem deve decidir como quer fazer as coisas.

A respeito dessa sensação de onipotência sobre o que o internauta vai poder fazer enquanto navega, já ouvi pessoas querendo bloquear o aumento e redução de fontes feitos pelos softwares. Acho engraçado essa gente jamais perguntar por que seu layout quebra quando as letras mudam de tamanho e o que se pode fazer para corrigir isso no nível de codificação. Não, é muito mais sedutor tentar exercer um poder de cima para baixo, condicionando o visitante a uma (má) experiência.

Voltando ao scroll, que é um problema ainda bastante recorrente: clientes até pedem por isso, algumas vezes. Me parece que é um condicionamento oriundo dos designers, que ainda insistem nessa prática ou são seduzidos por abrir um site num pop-up despido de comandos de navegação padrão. Claro, a culpa não é toda deles, porque sempre vem alguma ordem superior. Mas eles têm sua cota de participação na história, é inegável.

Sobre isso, o Jared Spool fez um comentário rápido e incisivo, no contexto de sua apresentação sobre aroma da informação (tradução livre de scent of information):

Users scroll. Designers usually create barriers for this.

Como justificativa, usou um exemplo extremo. O site de uma empresa de componentes eletrônicos listava todos os seus produtos numa só página na capa, em três colunas divididas horizontalmente por categorias. Todos os produtos eram apresentados com seus nomes, linkados diretamente no texto azul e sublinhado. Horror para designers e arquitetos de informação, mas uma tentativa de mudança nessa estrutura redundou numa enxurrada de reclamações de clientes, que não consigam mais achar o que procuravam.

Como dito, o exemplo é extremo. O público é muito específico (engenheiros eletrônicos e entusiastas), e provavelmente outras pessoas não teriam paciência de rolar uma tela imensa cheia de itens. No entanto, nesse contexto, uma tentativa de "facilitar" a navegação evitando o uso de scroll quase tornou-se desastrosa.

Por isso é tão importante refletir sobre esse ponto, não simplesmente decretando "não vamos usar rolagem" ou "teremos rolagem horizontal para diferenciar-nos do resto". Cada situação é diferente, e depende sempre do tipo e quantidade de informação, bem como os perfis de público que potencialmente tentarão se beneficiar dela.