JavaScript e HTML: Perdão por padrão

Ultimamente, tenho resolvido alguns problemas com JavaScript, por isso habilitei a depuração de scripts no IE7. Sempre que o navegador encontra um erro de JavaScript em uma página da Web, em vez da pequena notificação padrão e discreta da barra de status…

.. Agora recebo uma dessas caixas de diálogo de notificação de depuração de erro modal:

Deixei essa configuração ativada por puro esquecimento. Navegando na Web dessa forma, percebi rapidamente que o a Web está cheia de erros de JavaScript. O senhor mal consegue clicar em três links antes de se deparar com um erro de JavaScript de um tipo ou de outro. Geralmente, eles vêm em pares, trios, às vezes dezenas deles. É quase impossível navegar na Web com a notificação de erro de JavaScript ativada.

Na verdade, os erros de JavaScript são tão comuns que é fácil entender por que o IE os rebaixa a elementos quase invisíveis da barra de status. Se isso não acontecesse, ninguém poderia navegar na Web sem ser notificado até a morte. O Firefox vai ainda mais longe: há o nenhuma interface de usuário visível para quaisquer erros de JavaScript na página da Web atual. O senhor precisa abrir a caixa de diálogo Ferramentas | Console de erros para vê-los.

O resultado disso é que os erros de JavaScript, a menos que resultem em problemas funcionais óbvios, tendem a passar despercebidos. Coisas que causariam erros de compilação em qualquer outra linguagem são, na pior das hipóteses, pequenos inconvenientes em JavaScript. Quando os erros são ignorados por padrão, o resultado é um ecossistema de programação incrivelmente tolerante e extremamente permissivo. Se funciona, funciona, não importa os erros.

Mas essa flexibilidade sem igual tem seu preço. Basta perguntar a Dave Murdock, que descobriu da maneira mais difícil como o JavaScript pode ser flexível.

Então, analisei o código, que eu não havia escrito, e vi um JavaScript semelhante a este no caminho de execução que estava causando o travamento do Firefox:

var startIndex = 0;
for (i = startIndex; i < endIndex; i++) {
// do some stuff here
}

Isso funciona bem no Internet Explorer 7. O que acontece no Firefox? i é reinicializado para startIndex após cada execução do loop. O senhor precisa declarar o loop dessa forma para que ele funcione:

var startIndex = 0;
for (var i = startIndex; i < endIndex; i++) {
// do some stuff here
}

Colocar o var antes de i é o que deve ser feito, até onde sei, mas tanto o Internet Explorer quanto o Firefox fazem a coisa errada para os desenvolvedores aqui. Ambos os navegadores deveriam ser mais rígidos quanto à exigência de var em uma declaração de variável de loop e produzir um erro claro do interpretador de JavaScript antes que o código tenha a chance de ser executado.

Não se trata apenas de JavaScript. O HTML e o CSS também perdoam incrivelmente os erros. Ned Batchelder observou um comportamento bizarramente tolerante ao especificar cores nomeadas que não existem. Considere este pequeno trecho de HTML:

<font color="red">█ This is RED</font>

Ao variar a cor nomeada, o senhor não obtém o erro que poderia esperar. O que o senhor obtém são cores estranhas:

	Firefox	IE7	Opera
vermelho	” #ff0000	” #ff0000	” #ff0000
seagreen	” #2e8b57	” #2e8b57	” #2e8b57
verde-mar	” #0e00ee	” #0e00ee	” #0ea00e
sxbxxsreen	” #0000e0	” #0000e0	” #00b000
sxbxxsree	” #00000e	” #0b00ee	” #00b000
sxbxxsrn	” #000000	” #0b0000	” #00b000
sxbxeen	” #000e00	” #0bee00	” #00b0ee
tela	” #00ee00	” #00ee00	” #00ee00
ffff00	” #ffff00	” #ffff00	” #ffff00
xf8000	” #0f8000	” #0f8000	” #0f8000

(Se o senhor estiver curioso para saber como o “verde-mar” pode ser igual ao azul, as respostas são nos comentários da publicação de Ned.)

Não me lembro de nenhum outro ambiente de programação que se esforce tanto para evitar a apresentação de mensagens de erro, que se esforce tanto para fazer com que o código quebrado funcione, pelo menos um pouco. Embora tenha havido um esforço para tornar o HTML mais rígido, transformando-o no XHTML, que é muito mais rigoroso, o um fracasso total. Se o senhor não está convencido, leia O experimento de pensamento de Mark Pilgrim:

Imagine que o senhor postou um longo discurso sobre como o senhor [strict XHTML validation] é a maneira como o mundo deveria funcionarO senhor sabe que os clientes devem ser os guardiões da boa formação e rejeitar estritamente qualquer XML inválido que apareça em seu caminho. O senhor clica em “Publicar”, verifica duas vezes se a página foi validada, fecha o laptop e segue com sua vida.

Algumas horas depois, o senhor começa a receber e-mails de seus leitores dizendo que seu site está quebrado. Alguns deles são gentis o suficiente para incluir um URL, outros simplesmente gritam com o senhor de forma incoerente e dizem que o senhor não presta. (Essa parte do experimento mental também não deve ser muito difícil de imaginar, para qualquer pessoa que já tenha lidado com relatórios de bugs de usuários finais). O senhor testa a página e, vejam só, eles estão corretos: a página que o senhor criou de forma tão feliz e válida agora não está bem formada e não aparece em nenhum navegador. O senhor tenta validar a página com um serviço de validação de terceiros e descobre que ele apresenta uma mensagem de erro que você nunca viu antes e que não entende.

Infelizmente, os Draconianos venceram: ao renderizar como XHTML estrito, qualquer erro na sua página resulta em uma página que não só não é renderizada, mas também apresenta uma mensagem de erro desagradável para os usuários.

Eles podem não ter percebido na época, mas os Draconianos destruíram inadvertidamente o futuro do XHTML com essa decisão única e irrevogável.

A lição aqui, ao que me parece, é que o o perdão por padrão é absolutamente necessário para o tipo de adoção mundial em larga escala de que a web desfruta.

A tolerância permissiva e flexível projetada no HTML e no JavaScript é estranha aos programadores que cresceram sendo regularmente flagelados pelo compilador por erros mínimos. Alguns de nós foram tão castigados que realmente começaram a como o . Apontamos e rimos de todo o terrível HTML e JavaScript na Web que mal funciona. Coçamos a cabeça e nos perguntamos por que o navegador não pode nos dar a punição que tanto merecemos por nossos erros terríveis.

Mesmo que os programadores tenham aprendido a gostar de rigor draconiano, o perdão por padrão é o que funciona. Ele veio para ficar. Devemos aprender a amar nosso bela sopa em vez disso.