O boto escreveu sobre seu ódio às autotools. Não é segredo que eu adoro autotools com amor masoquista, mas também tenho minha cota de ódio para partilhar com a audiência anônima do diário. Anos passam, sistemas computacionais evoluem, as pessoas continuam usando coisas ruins na Web e eu continuo chateado. Quero esclarecer de maneira direta o que me deixa insatisfeito no software atual, e o que gostaria de fazer a respeito.

XHTML 1.1 é bom. O resto não é.

HTML “sopa de tags“, sem padronização, é uma droga. Não dá nem para validar, e você tem que adivinhar como o navegador vai interpretar. Apesar disso, muita gente faz assim.

HTML 4.01 Transitional é horrível, misturando apresentação com conteúdo em todo lugar.

XHTML 1.0 é bogus. A idéia de “compatibilidade com HTML” (o apêndice C) é lesada. Se o navegador vai ler a coisa como HTML sopa de tags mesmo, você não ganha nada mandando o conteúdo como XHTML; poderia mandar HTML de uma vez. E o trabalho vai todo para o autor, que precisa ficar escrevendo espaços antes de barras, evitando quebras de linhas, escrevendo atributos redundantes (name pra id, lang pra xml:lang e companhia).

XHTML 1.1 é bacana. Modular, sucinto, e com furigana. Eu usaria XHTML 1.1 pra tudo, mas aquele navegador popular de má qualidade não entende o padrão. E pior, mesmo um programa do nível do Firefox não entende o módulo Ruby sem uma extensão (e lá se vão quatro anos desde a especificação).

O que eu gostaria de fazer a respeito

Muito tempo atrás haqueei um programa XSLT para converter XHTML 1.1 para HTML 4.01 (funciona bem no sablotron). Usado com negociação de conteúdo (do Apache, por exemplo), você pode mandar HTML para aquele navegador ruim, e XHTML para quem entende.

A idéia seria integrar isso de forma mais transparente em algum framework existente. Meu alvo atual é o Ruby on Rails.

XSLT é lento. Vejo quatro abordagens para este problema:

  1. Usar apenas páginas estáticas, e gerar as versões HTML automaticamente usando make, rake ou similar. Como vantagem, poder-se-ia usar o módulo de negociação de conteúdo do apache.
  2. Algum esquema de cache para o HTML gerado.
  3. Implementar a mesma funcionalidade em ruby (usando ReXML) e comparar o desempenho.
  4. Abordagem nenhuma. Os usuários daquele navegador que esperem.

Ruby é muito bom. Lisp é muito bom. Python é bom. Perl não é. PHP muito menos.

Apesar disso, o povo escreve tudo em Perl e PHP. Raios, este diário é escrito em PHP!

E por que eu deveria me importar com a linguagem usada? Em primeiro lugar, porque cedo ou tarde você quer mexer no programa, e até hoje não mexi no Wordpress por nojo de PHP. Além disso, montar a parte de dentro da caixa preta com bons materiais traz bom karma.

O mesmo se aplica a MySQL. Todo mundo usa MySQL porque todo mundo usa MySQL. PostGreSQL é melhor em tudo.

Multilíngua

Alguns amigos meus entendem inglês, e não português. Outros, o contrário. Alguns preferem japonês a qualquer uma das duas, e em um ano ou dois espero já ser capaz de produzir conteúdo para eles.

Muita gente trabalhou para produzir padrões bastante decentes de suporte multilíngua. Use Unicode, nada além de Unicode, e em todo lugar. Use os atributos xml:lang, hreflang e amigos. Use negociação de conteúdo para escolher o idioma padrão.

Quantos softwares para weblog vocês conhecem que fazem tudo isso? Quantos me deixam escrever com facilidade para audiências de diferentes idiomas, e deixam a audiência encontrar o conteúdo preferido facilmente, tudo de forma padrão? Zero. Nada. Nothing. Nanimo nai.

Para escrever o parágrafo anterior, gastei um tempão digitando coisas como <em lang="en" xml:lang="en">, porque o diário usa XHTML 1.0, e porque o Markdown não tem sintaxe para multilíngua.

O que eu gostaria de fazer a respeito

Primeiro, UTF-8 em todo lugar, e marcação XHTML multilíngua em todo lugar. Preciso também de um sistema genérico para seleção de linguagens com o seguinte comportamento:

  • Se o usuário selecionou a URL de um idioma específico, então selecione este idioma.
  • Senão, se o usuário tem uma lista de idiomas preferidos em um cookie, itere pela lista procurando uma língua na qual o documento esteja disponível, e a selecione.
  • Se nenhuma das línguas do cookie está disponível, monte uma lista de idiomas a partir do cabeçalho HTTP Accept-language e busque da mesma forma.
  • Em último caso, selecione o primeiro idioma disponível de uma lista de idiomas padrão (mantida no servidor).

Por fim, uma abreviação para multilíngua compatível com Markdown seria bacana.

Hierarquia é ruim.

Auto-explicativo. Sou obrigado a usar árvores em um monte de lugares em que preferiria usar palavras-chave.

Má tipografia

Para saber o que é pontuação tipográfica boa, leia isso. Admito que o problema está resolvido em sistemas como o Wordpress, mas deveria estar também em todo lugar.

E hífens não são travessões!

O que eu quero, afinal?

  • Um weblog decente, em uma linguagem de programação boa, multilíngua desde o nível mais baixo, autorado em XHTML 1.1, com categorias em palavras-chave (tags). Tudo isso o mais transparente possível para o leitor.
  • Um sistema de galerias decente, linguagem boa, multilíngua, tipográfico, XHTML 1.1, categorias e metadados em tags, informações EXIF explícitas e acesso à foto em vários tamanhos, sem que o usuário precise se registrar pra ver fotos. E sem Flash! *cof*
  • Uma maneira prática de escrever páginas independentes, em uma linguagem de programação boa, multilíngua, etc. etc.