Blog do Jerônimo

Não é de hoje que várias pessoas utilizam a 5ª edição do JavaScript - The Definitive Guide do David Flanagan (ed. O’Reilly) como referência principal de JavaScript. Eu mesmo utilizo.
Mas temos de concordar que o livro já está um pouco desatualizado. A 5ª versão é de agosto de 2006, ou seja, já tem mais de dois anos.

Uma editora da qual tenho comprado alguns livros é a Sitepoint. Estou gostando bastante do estilo de livro deles, e sempre achei o conteúdo muito bom. Comprei a referência de CSS deles, que é excelente; o que mais me conquistou no livro é a tabela de compatibilidade de atributos CSS por navegador, incluindo a versão. A versão online da referência pode ser vista gratuitamente aqui.
Outra referência muito boa que eles lançaram recentemente é a referência de HTML. Já comprei a minha, mas ainda não chegou pelo Correio. A versão online também conta conta com o mesmo recurso: tabela de compatibilidade por versão de navegadores, logo, creio que a versão impressa também seja assim.

Contudo, o que faz falta mesmo é uma tabela de compatibilidade de JavaScript, com navegadores e versões. Não temos isso no livro do Flanagan, infelizmente.
Mas podemos ver no site de referências da Sitepoint uma referência de JavaScript com a marca “Coming soon”. Se esta referência seguir a linha das outras duas, poderemos, quem sabe, ter a tabela de compatibilidade por propriedade/método de JavaScript, com os principais navegadores e versões. Além disso, quem sabe tenhamos também a versão impressa (e se houver, certamente comprarei).

Se isso se confirmar, será que teremos um concorrente de peso (e atualizado) para o The Definitive Guide? Resta aguardar e torcer.

Dois objetos são extremamente importantes no JavaScript: window e document.
O objeto window premite acessar propriedades e métodos relativos à janela toda do navegador. Por exemplo, o método window.resize redimensiona a janela do navegador, se as configurações de segurança permitirem isso.
Já o objeto document é o mais utilizado. Ele corresponde ao corpo do documento HTML em questão. Cada div, tabela, célula de tabela, campo de texto, checkbox, enfim, tudo que forma seu documento é acessível pelo objeto document.

Para pegar um elemento específico de sua página, basta chamar o método getElementById do objeto document. Para isso, é necessário que o elemento que queremos pegar tenha um atributo id definido. Lembre-se que não pode haver mais de um elemento com o mesmo id na mesma página. Há alguns problemas com versões mais antigas do IE, compreenda todo o problema clicando aqui.

Então, para pegarmos, por exemplo, um campo de texto (input type=text) cujo id seja “meu_texto”, basta fazer no JavaScript:
document.getElementById(”meu_texto”)
A partie disso você pode acessar propriedades desse elemento. No caso do nosso exemplo:
document.getElementById(”meu_texto”).value - Acessa a propriedade value do elemento, tanto em leitura como escrita. Para escrita, basta colocar a expressão citada, o sinal de igual, e o novo valor entre aspas. Assim:
document.getElementById(”meu_texto”).value = “Um texto qualquer”
Para acessar o atributo disabled, podemos fazer:
document.getElementById(”meu_texto”).disabled
E assim vai.

Para uma referência completa sobre quais atributos podes acessar, quais permitem leitura e escrita, quais são apenas escrita, etc, recomendo consultar o livro JavaScript - The Definitive Guide, de David Flanagan, 5ª Edição (O’Reilly). Caso não possa ter acesso ao livro, procure referências diversas no seu buscador favorito; mas recomendo dar uma olhada na W3Schools.

Encerro aqui a parte 2 do tutorial. Quando me der na telha escrevo uma parte 3.

A partir de hoje postarei mini-tutoriais de JavaScript com dicas básicas para iniciantes na linguagem. Se você já sabe JavaScript, provavelmente não vale a pena ler. Se você não sabe nada da linguagem e está querendo aprender o básico, talvez seja um bom guia.

O que é JavaScript?

JavaScript é uma linguagem interpretada para criação de scripts de propósito geral. Contudo, é utilizada mais comumente em navegadores como linguagem para manipulação de páginas. Os tutoriais que serão postados aqui, começando por esse, vão se referir justamente à linguagem sendo executada nesse tipo de ambiente: navegadores.

JavaScript tem capacidades de Orientação a Objetos (OO), e é fracamente tipada. E principalmente: JavaScript não tem NADA a ver com a linguagem JAVA, da Sun.

Usando JavaScript em sua página

Para colocar código JavaScript em suas páginas, há basicamente duas formas:

1. Escrever o código dentro do próprio arquivo HTML

   Não é uma opção lá muito elegante, mas é útil. Para fazer isso, basta colocar o código JavaScript desejado dentro de uma tag script. exemplo:

   <script type="text/javascript">
   window.alert("Hello World!");
   </script>

   Como se pode ver acima, é necessário especificar o tipo de script que o navegador deve interpretar com o atributo “type”, com valor igual a “text/javascript”. Antigamente, era usado também um atributo “language” com valor igual a “JavaScript”, mas esse atributo foi deprecado em favor do type pelo W3C.

2. Escrever código em um arquivo separado e importá-lo no HTML

   Esta forma é a mais elegante. Basta escrever seu código JavaScript em um arquivo com extensão “.js”, e importá-lo no HTML assim:

   <script type="text/javascript" src="meu_codigo_javascipt.js"></script>

   Você vai encontrar por aí muitas recomendações que o código JavaScript deve ser importado/escrito no início da página, dentro da tag HEAD. Contudo, aconselho o oposto: colocar todo o código (se possível) no fim da página. Esse meu conselho não é infundado, pois é o que aconselha o guia de boas práticas para melhoria de performance de páginas web escrito pelo Yahoo!.

Escrevendo o Hello World em JavaScript

Para colocar algum código a rodar, vamos fazer um Hello World. O exemplo dado acima é um bom código para isso:

window.alert("Hello World!");

Aqui, podemos ver um importante objeto, o “window”. O objeto window refere-se à janela do navegador na qual o script está sendo executado. Então, chamamos o método “alert”, um método do objeto window que serve para mostrar uma popup na tela com uma mensagem e um botão de “Ok”. O parâmetro é a mesagem que a janela deve exibir.

Para ver esse código rodando, clique aqui.

Encerro aqui a parte 1 do mini-tutorial de JavaScript. Em breve posto a parte 2.

Sem dúvida, uma das funções mais usadas do JavaScript (se não for A mais usada) é o document.getElementById(). O que nem todos sabem é de um pequeno problema sobre a implementação desta função no Internet Explorer.

Bem, segundo o que o próprio nome da função diz, ela é uma função para “pegar um elemento pelo id”; contudo, no IE, esta função também pega um elemento pelo name.Veja o exemplo.

Imagine o seguinte código:
<input name="teste" type="text" value="oops">
<script type="text/javascript">
var a = document.getElementById('teste');
try{
alert(a.value);
}
catch(e){
alert('"teste" não existe!');
}
</script>

O que se espera é que ‘”teste” não existe’ seja alertado, pois não há elemento com id igual a “teste”, logo “a” seria nulo. Isso ocorre no Firefox, por exemplo. Já no IE o valor “oops” é alertado, pois ele pega o elemento pelo name, e não pelo id.

Duvida? Faça o teste com o código acima.
Podemos dizer então que o IE está errado em sua implementação? Não necessariamente.

Do ponto de vista do nome da função, “getElementById”, os elementos deveriam ser pegos por e somente por id, e não por name. Contudo, o W3C define que id e name compartilham do mesmo namespace; segundo o consórcio, quando id e name são usados simultaneamente em uma mesma tag eles PRECISAM ter o mesmo valor. Além disso, é proibido usar um id igual a um name para elementos diferentes. Assim, a Microsoft não pode ser acusada de ter implementado incorretamente a função pois, no exemplo acima, se existisse algum elemento com id igual a “teste”, seria o mesmo input text, visto que o seu name já é “teste”, logo o id “teste” só poderia ser aplicado aquele elemento, semanticamente falando.

Mas ainda tem a questão de que o nome da função informa que o elemento será pego pelo id, e não pelo name… Afinal, quem tem a razão?

Minha resposta pessoal é: não sei. Mas tenho uma opinião pessoal.

Eu acho que se o nome da função informa que o elemento será pego por id, ele deve ser pego somente por este atributo, e não por name (ao contrário do que ocorre no IE). Pois, semanticamente falando, o atributo id pode existir ou não, independentemente da existência do atributo name, e vice-versa! O fato é que se há um atributo name definido e o atributo id não foi, então NÃO HÁ um elemento com o atributo id igual ao valor passado por parâmetro, logo, não se pode pegar o elemento por id.

Isso é o que eu acho. Mas quem deve decidir qual das implementações é correta é o W3C.

E você? Tem opinião formada sobre isso?

Fonte de inspiração: Quirksmode

Já como primeiro post, vou dar minha opinião pessoal (e rápida, espero) sobre esse assunto que já está provocando “guerras” de opiniões pela Internet: afinal, o que é essa tal Web 2.0?

Esta semana, li o excelente post do Alex Hubner no Webinsider falando o que pensa sobre o termo (recomendo fortemente que leia); em um resumo - em minhas próprias palavras - ele dá sua opinião de que não há motivo para o alvoroço vindo da disseminação da “Web 2.0″, pois ela não acrescenta NADA tecnologicamente: ela é nada mais, nada menos, do que a velha web (1.0, se quiser chamar assim); ele comenta ainda que boa parte da tão famosa “participação ativa do usuário” no conteúdo dos sites não passa de um amontoado de lixo.

Eu concordo. Com quase tudo.

Minha opinião vai ao encontro da idéia dele: não há nada novo na tecnologia. As tecnologias utilizadas já existem há tempo. XmlHttpRequest já vem de longa data (ok, não tão longa, mas já tem uma boa história…). Javascript, CSS, XML, JSON, etc. Tudo é conhecido há tempo.

CONTUDO, em minha opinião, o que está se fundamentando hoje (isso sim pode se chamar de novo) é a consciência do desenvolvedor web a respeito de tais tecnologias. Atualmente, mais desenvolvedores se preocupam em aprender os padrões web e a construir suas páginas/sistemas web seguindo-os, o que sem dúvida é “um grande passo rumo a uma Internet melhor” (uma pitada de utopia não mata ninguém). Hoje, utilizamos mais essas tecnologias, e as utilizamos melhor; isso certamente provoca o que vemos hoje: interfaces mais ricas visualmente, mais fáceis de usar, com mais recursos, que funcionam melhor entre os diversos navegadores existentes, etc.

A utilização em massa do AJAX, por exemplo, traz ao usuário final uma grande vantagem: a sensação de ter uma resposta imediata a uma ação sua, mesmo que seja um “Loading”, ou “Please wait while…”; afinal, podemos utilizar as requisições assíncronas como uma grande ferramenta para esconder a “triste realidade”: a web continua a mesma. Ainda temos latência na rede, falhas de HTTP, quedas de servidor, etc. Todavia, a lógica não é complicada (agora venho eu com equações):

Não há resposta imediata = Usuário triste

Ainda com latência, mas mostrando um belo “Loading” = Usuário feliz

Exemplo? Compare os sistemas de webmail antigos com os novos. Alguém prefere as velhas interfaces, que se recarregavam a cada interação? Ou a maioria dos usuários preferem a nova interface, com respostas imediatas, assim como podemos ver no YAHOO! Mail ou GMail, por exemplo? Eu, particularmente, prefiro o meu YAHOO! Mail com interface AJAX.

O por quê de minha insistência em destacar e priorizar a felicidade do usuário, ainda que seja conquistada com um “disfarce” para a velha Web 1.0? Simples. Porque acho que este é o trabalho de todos nós, desenvolvedores web: conquistar o usuário, e mantê-lo utilizando o serviço desenvolvido.

Já quanto ao amontoado de lixo na Internet, decorrente da participação ativa do usuário, concordo plenamente. Não é difícil perceber quanta coisa inútil tem por aí (espero que não incluam este post nessa lista…). Vide os “vídeos-lixo” no YouTube que, por causa de uma grande audiência, acabam atrapalhando buscas de conteúdo sério; ou ainda, a destruição do idioma, com a geração MiGuXoS (me deu trabalho pra escrever isso!). Contudo, não há solução pra isso. É público, caiu nos braços do povo. Quando não tinha essa interação toda, as pessoas se contentavam repassando para todos os seus contatos e-mails advertindo sobre os terríveis males do monóxido de dihidrogênio (spam é coisa que tem cada vez mais). Agora,  outras formas de interação também são utilizadas para diversos propósitos, mesmo que estapafúrdios como esse de “banir a água”. Basta-nos tentar ignorar o amontoado de bobagens.

Para encerrar minha opinião, digo que concordo plenamente com o comentário da Valéria, no post do Alex Hubner. Dane-se o novo jargão. O que importa é que estamos aprendendo melhor a tecnologia. Fazemos mais, e melhor. A “Web 2.0″ veio pra nos tornar desenvolvedores melhores, mesmo sabendo o que é fato:

A Web 2.0 não existe.