Blog do Jerônimo

Seguindo a linha de referência rápidas para parede, iniciadas com a tabela de cores para html, hoje posto uma Referência Rápida de HTML, toda comentada.

Pode baixar aqui.

Muita gente tem dúvida sobre as cores em html, sobre o formato em hexa RRGGBB, e tudo mais.
Sendo assim, resolvi criar uma tabela fantástica com as cores utilizadas mais comumente em diversos sites. Nela, estão as cores, o código RGB e também o nome CSS correspondente.

Apesar de bastante simplificada, creio que será de muita utilidade. Sinta-se livre para imprimir sua própria cópia para utilizar como referência. Se quiser repassar a tabela a alguém, por favor, indique o link desse post.

Chega de papo. Aí vai o link para a tabela:
HTML Color Codes Sample Sheet

Bom proveito!

Hoje li uma notícia no Folha Online, Microsoft planeja Windows para rodar pela internet. Segundo a notícia, a Microsoft planeja lançar um sistema operacional baseado na internet. Confuso…

Há tempos que as pessoas falam em “sistemas operacionais via web”, mas em minha opinião isso não existe. O conceito de sistema operacional que apendi é outro. Isso me parece mais algo como… “web desktop”.
E esse Windows Cloud não traz novidade alguma. Já há alguns web desktops bem famosos por aí, como o EyeOS e o G.ho.st.

Além disso, para rodar esses supostos “sistemas operacionais via web”, precisamos de um sistema operacional (de verdade) rodando nativamente na máquina, e então um navegador, o que reforça que o sistema não passa de um web desktop.

Construir uma plataformazinha via web, tudo bem… agora, chamar de sistema operacional…
Acho melhor dar o nome certo aos bois. Coisa que eles provavelmente não farão. Sistema operacional via web é mais “marketeiro” do que web desktop.

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.

Todos andam falando, quem sou eu para não falar também.

O Google lançou recentemente um novo browser no mercado: o Google Chrome. Beta, pra variar, como quase tudo no Google. Mas no Google, beta não é sinônimo de ruim.

Infelizmente, ainda não tive o prazer de experimentá-lo, visto que sou um linux guy, e o Chrome só foi lançado para Windows, por enquanto. Mas pelo que pude ler, dizem ser um excelente navegador em termos de velocidade, o que é ótimo. É bom ver um navegador rodando JavaScript mais rápido também.

Lendo o post do Diego Eis no Tableless, não pude deixar de notar que muita gente torce para que o Chrome desbanque o Internet Explorer, principalmente a versão 6. Não posso discordar que também detesto essa versão do navegador.

Contudo, nesse aspecto, sou um pouco pessimista. Há tempos o Firefox está aí, é bem melhor que o IE, e as pessoas resistem em migrar de um navegador para outro. Muita gente sequer atualiza a versão do próprio navegador que usam. Uns, por comodidade; outros, por não saber como fazê-lo, ou por desconhecer a existência de outros navegadores. Mas o pior, e creio que é o fator principal de não haver a migração: muita gente não sabe o que é um navegador; eles simplesmente sabem que “clicaram no ícone da internet”. O Internet Explorer vir junto com o Windows é o maior problema (e que desbancou o finado Netscape).

Torço que a Microsoft adote uma solução mais rígida para o IE6: forçar a atualização para o IE7 em todos os computadores, obrigatoriamente. Não que o IE7 seja bom, mas é menos pior que o 6. E torço para que venha por aí um IE8 no mínimo razoável.

Não creio que o Chrome vai desbancar o IE. Mas creio que será mais uma boa opção de navegador, e com tantas boas opções, quem sabe faça a MS pensar e melhorar o velho IE.

Mas, de minha parte, viva Firefox.

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.