Observem o exemplo:

Algo que tem-se pregado por aí é retirar o totalmente o Javascript do HTML, ou seja, o exemplo acima ficaria assim:

E teríamos um arquivo .js com o seguinte código para ligar o evento onclick do button:

Puxa vida, toda essa volta só para não usar a propriedade onclick no HTML e se livrar totalmente do Javascript, isso vale a pena ?

Há vários motivos para que eu não concorde com isso:

• Mais código para dar manutenção, foram criadas várias linhas de javascript para algo que funcionaria no primeiro exemplo usando a propriedade onclick da tag input.
• E quando eu quiser saber qual evento o button aciona, será fácil de achar ? Podem haver vários objetos na página, todos com seus eventos ligados apenas no momento do onload da página. Vários objetos é igual a várias linhas de código javascript com as ligações, se você estiver usando um editor de textos comum, bem... boa sorte, e mesmo com uma IDE não é tão simples assim.
• A propriedade onclick, onkeypress, etc faz parte da especificação HTML, justamente para facilitar isso, porque iria deixar de usá-los ?

Então muito cuidado ao seguir padrões ao extremo, questione-os, cada um tem o seu lugar e hora certa.

Os que odeiam, normalmente já odeiam Javascript também, e odeiam ainda mais quando os que amam exageram absurdamente no uso da técnica, conseguem fazer o site ficar inutilizável, uma usabilidade de dar medo, o teclado simplesmente não serve mais. E não me venham falar pra usar o mouse pois usabilidade é para todos os dispositivos. E o motivo principal de usar AJAX (desempenho), foi esquecido a muito tempo.

Dou certa razão para os que odeiam, a usabilidade é item prioritário na construção de um website, de que adianta ser lindo se não conseguimos utilizá-lo. Existem padrões web, utilize-os sempre na medida das possibilidades. Antes perder em semântica do que usabilidade.

Mas vamos lembrar primeiro que AJAX não é um framework, tecnologia, API ou biblioteca. AJAX é uma técnica que pode envolver o uso de várias tecnologias (Javascript, XML, DOM, etc), e pra espanto de vários, foi iniciativa da Microsoft, a própria criou o objeto XMLHttpRequest, responsável pelas requisições assíncronas, embora seja uma técnica que pode ser alcançada usando iFrames também.

Desempenho! Afinal banda de internet é cara, os serviços de hospedagem no Brasil que o digam... AJAX serve para melhorar o desempenho para todos, seja do sobrecarregado servidor ou do usuário que ainda utiliza modem (sem piadas, 53% dos internautas brasileiros ainda utilizam modem). Um bom exemplo de uso da técnica pode ser vista no sistema de creditar do Infoblogs, um simples clique e pronto lá foi o crédito, sem precisar que a página seja renderizada novamente para atualizar uma única tag, simples e ótimo para todos.

Agora um péssimo exemplo é quando temos mega formulários em alguns sites e o submit é uma chamada usando AJAX. Se não utilizar um framework decente, isso dá um trabalho enorme para implementar. E o que ganhamos com isso ? Mais manutenção, o ganho de desempenho é minúsculo. Os vários dados do formulário terão que ser enviados de qualquer forma, todo um processo de parse deve ser feito via javascript e parse de dados é algo que o próprio browser já faz naturalmente ao fazer o submit, ou seja, apenas processando à toa.

Então devemos pesar bem quando utilizar a técnica, pode até ser para algo bonitinho, mas vale mesmo a pena ganhar mais manutenção ? Pense sempre em desempenho e não perca a usabilidade de vista.

Não é novidade que o Internet Explorer é, de longe, o pior caso em seguir padrões web, mas simplesmente não podemos abandoná-lo. Que o digam os meus clientes, que de forma alguma trocam de navegador.

Não sou bom em design, nunca fui, dou minhas patadas, mas para bolar layouts de sites novos eu sempre passo para um outro amigo, também freelancer. Infelizmente ele, embora crie layouts muito bons, não tem experiência em padrões web, sendo assim, cabe a mim adequar o código fonte, e como já disse, faço o melhor que posso. Mas quando o seu layout deve ser flexível e um determinado elemento teima em não se apresentar corretamente em um certo "browser", é necessário parar para pensar: "sacrifico o layout ou a semântica desse bloco ?"

O tempo urge pelo sacrifício da semântica, os mega indexadores preferem o sacrifício do layout. Eu opto tentar ao máximo ir pela semântica, mas não sou fanático ao ponto de jogar fora o layout só porque um elemento não funciona direito no browser X ou Y. Se o elemento que fugirá da semântica é de mínima importância, não pense duas vezes,  quebre o padrão, mas somente faça isso quando não houver outra alternativa, esgotaram-se mesmo as possibilidades. É fácil seguir a semântica quando sua página é um "linguição fixo", agora quando os elementos devem ser adequar ao perfil do usuário aí você se complica.

Podem me jogar pedras, mas por favor, o façam também contra o IE. Sempre crio o conteúdo utilizando como navegador o Firefox, e tudo que fiz sempre funcionou corretamente nele. Rezo para que um dia ele chegue à liderança e com grande margem, e somente nesse dia é que eu conseguirei convencer meu cliente a trocar de navegador, antes disso, nós é que temos que ser flexíveis.

Mas lembre-se um pequeno trecho sacrificado que no futuro pode ser corrigido com o uso de melhores navegadores é uma coisa, chutar toda a semântica é bem diferente, por favor nunca façam este último, sigam padrões, ou pelo menos 99,99% deles.

Bom não tem jeito, Google ao resgate... minutos depois problema encontrado e resolvido, o que ocorre é um limitação imposta pelo próprio compilador, um método em Java pode ter um tamanho máximo de 65534 bytes, portanto quando o JSP era convertido em Servlet acabava gerando esse método monstrinho gordinho, mais informações sobre este e outros limites você encontra aqui na especificação da Virtual Machine.

Para resolver o problema foi necessário, adivinhem ? Simmmm, REFATORAR..... basta dividir o JSP em arquivos menores que façam mais sentido e uni-los com <jsp:include>. Para ajudar ainda mais não se esqueça de utilizar padrões web para o HTML gerado, mais tableless, o código fica muito mais enxuto, e quando possível, pense bem antes de criar uma tela com tantos dados, para uma melhor usabilidade.

Claro que, embora seja uma limitação imposta pelo compilador, NUNCA crie um método tão grande, isso vale para qualquer linguagem.

"Nelson, acho que aconteceu algum problema, o PDF abriu mas só tem uma página aqui!"

Pensei: "Bom enquanto ele não responde vou dar uma olhada na capa". Pra minha surpresa, ao vislumbrar a imagem abaixo, percebi que nada havia de errado com o arquivo, lá estava tudo o que precisava ser dito, ou no caso mostrado =D, sobre padrões em um página HTML.

Simples assim.

Tudo que eu já havia lido sobre padrões nessa área, tudo o que muitas pessoas de bom senso pregam como ideal, está aí. Ao invés de um calhamaço de 600 páginas, uma imagem que é compreendida em alguns segundos.

Javascript, CSS e HTML separados. Quem dera todos os designers fizessem isso, as vantagens são absurdas: menos consumo de banda, afinal os mesmos arquivos de CSS e Javascript serão usados em todos os outros arquivos HTML, reusabilidade e o principal, um padrão de separação entre o comportamento e apresentação da página, maravilhas das maravilhas para futuras manutenções. Basta apenas ligar os arquivos .css e .js com uma tag no arquivo HTML e pronto.

É claro que não poderia deixar de dar crédito a autora pela obra de arte.

Standards For Life

Preciso criar um cartaz bem grande com isso, talvez alguém olhe e crie juízo. =D