Arquivo da tag: scripts

Border-Radius em todos os navegadores

Outra coisa que geralmente me deixa furioso é ter que fazer border-radius usando sobreposição de imagens, e criar uma infinidade de codigo css e javascript para conseguir executar esta função tão querida dos nossos colegas designers.

Então o ultimo site que recebi solicitando a propriedade de border-radius nas imagens começei uma odisseia testando varios scripts que prometiam fazer o indicado em todos os navegadores, inclusive o famigerado IE. Demorei algum tempo de pesquisa, mas finalmente encontrei o javascript que faz o que eu preciso.

Corner.js é o nome da aplicação que eu precisava. Funciona de uma maneira bem simples, basta vc colocar algumas descrições a mais em uma classe indicando o que vc quer que faça e o resto é por conta do script. Como eu uso wordpress, tive que fazer um pequeno ajuste via jquery para que a classe fosse adicionada automaticamente em toda a imagem nova publicada.

Depois de feito download do script, coloquei ele na pasta js/ que fica dentro na pasta do meu tema, algo assim wp-content/themes/meu-tema/js/. Depois inseri este codigo no arquivo functions.php

wp_enqueue_script('corner', get_bloginfo('template_url') . '/js/corner.js', array

Que é uma maneira elegante de chamar o javascript que vc precisa, sem colocar ele diretamente no arquivo header.php, ou algo do genero. Coloquei ele precisando do jquery pois vou precisar do jquery para colocar as classes necessarias.

No arquivo header.php antes do escrevi o seguinte codigo:

<script type="text/javascript">
* <![CDATA[ */
    jQuery(document).ready(function(){
        jQuery("img").addClass("corner iradius15");
    });
/* ]]> */
</script>

Isto faz com que todas as imagens do site tenham border-radius 15px.

Testei em todos os navegadores quanto eu consegui, e funcionou em todos.

Qual o local correto para adicionar scripts em seu site?

Outro dia, após publicar o artigo “Como Adicionar o Código do Google Analytics ao Blogger e WordPress” tivemos uma pequena discussão relacionada a qual parte do código da página, devemos adicionar o código de monitoramento do Google Analytics.

O correto seria adicionar perto da tag </body> que se encontra já no final do código da páginas, porém um dos visitantes perguntou: _ Porque no final?

Temos vários motivos para que o código do Google Analytics seja adicionado no final do código da página. Confira alguns deles.

Ps. Se você não tem idéia de como uma página é construída, recomendo que aperte o botão direito do mouse e clique em “Exibir código fonte” para que você não fique perdido durante o resto deste artigo.

Agilidade no carregamento

Os sites são carregados no computador dos visitantes de acordo com a sequência dos elementos presentes na página. Se você sobrecarregar o início do código da página, com elementos que deveriam estar no final, você poderá deixar o carregamento do que é realmente importante para o visitante mais lento. Conteúdo!

Melhor para SEO

Especialistas em SEO dizem que o Google indexa apenas uma determinada quantidade de KB da página e que todo o resto é ignorado. Por isso, se você deixar elementos desnecessários no começo, o indexador pode deixar de indexar o conteúdo ou outra coisa que seria mais vital para o posicionamento do site.

Monitoramento correto dos visitantes

Ao adicionar o código de monitoramento do Google Analytics no começo do código da página, você poderia coletar dados incorretos sobre os visitantes que acessam seu site, já que existem casos em que o carregamento da página é interrompido/travado por algum motivo ou o visitante desiste de acessar o site antes de carregar a página completamente.

Neste caso, como o código de monitoramento está mais perto do começo do código da página, ele poderia ser contabilizado, mesmo sem o visitante ter permanecido na página.

“É claro que isso não seria um problema se você deseja apenas ter números para aumentar seu EGO”.

Outros exemplos

Existem scripts que exigem que seus códigos sejam adicionados no local exato em que você deseja que ele apareça dentro da página, como é o caso de chats, contadores de visitas, players de músicas e etc.

Mas também existem alguns scripts, que independente do local da página em que você o adicione, ele sempre será exibido (seja lá o que for) em locais determinados pelo código fornecido pelo desenvolvedor. Um exemplo disso é a barra de ferramentas do Wibiya, que não importa se você o adicione no começo, meio ou fim da página. A barra sempre aparecerá no rodapé, exatamente como pode ser visto aqui no CriarSites.com.

Portanto, neste caso não faria sentido adicionar o código no começo do código da página, já que isso estaria atrapalhando o desempenho do site de diversas formas.

Conclusões

Cada script deve ser adicionado ao site de acordo com as especificações do fornecedor de forma que ele funcione corretamente e da melhor maneira. Portanto, recomendo que procure informações no site que fornece o script e que faça como ele descreve.

Fonte: Celso Lemes/CriarSities

Ruby 2.0: Planos do criador

O blog RubyInside reportou que Yukihiro Matsumoto (“Matz”), criador da linguagem Ruby, realizou um commit esse mês, que marcou o início do desenvolvimento de ideias que há tempos vinham sendo discutidas para a próxima versão principal da linguagem, o Ruby 2.0.

Segundo Matz, o novo Ruby apresentará uma série de novas funcionalidades, mas de maneira geral, as mudanças serão menores do que as realizadas na versão 1.9. Apesar de ainda não estar totalmente definida, a versão 2.0 do Ruby será compatível com as aplicações escritas seguindo a sintaxe 1.9.x.

Koichi Sasada, criador do YARV, uma máquina virtual de execução dos scripts Ruby, recentemente postou o resultado do questionário de funcionalidades desejadas para o Ruby 2.0. Até o momento, as ideias de novas funcionalidades estão sendo ativamente sugeridas e discutidas (principalmente nas listas ruby-talk e ruby-core). Abaixo alguns itens mais cotados para o novo Ruby, segundo o RubyInside:

  • Refinamentos (Refinements): Trata-se de uma construção que torna mais seguros os monkey-patches (modificações dinâmicas em classes), por limitar as alterações em classes centrais dentro de contextos específicos (veja uma explicação detalhada por Yehuda Katz). É uma funcionalidade polêmica, por apresentar impacto direto na performance do interpretador.
  • Exportação e importação de bytecode: O Ruby 2.0 tornará simples o processo de exportação e importação de scripts Ruby pré-compilados, para serem executados diretamente. Esta funcionalidade permite que o tempo de análise (parsing) dos scripts seja eliminado durante sua execução.
  • Argumentos com palavra-chave: Uma mudança da sintaxe de definição dos métodos que permite a associação de palavras-chave aos argumentos do método, que torna a leitura do código mais clara, de forma similar à utilização de hashes com parâmetros.

Outras mudanças sendo consideradas incluem uma limpeza na sintaxe da linguagem, coleta de lixo simbólica, suporte a macros, obtenção das árvores de parse e de código, I/O não bloqueante e uma revisão de todas as bibliotecas padrões.

Fonte: Fernando Ultremare/InfoQ

HTML 5: Já podemos usá-lo?

Os trabalhos de especificação do HTML 5 estão em andamento há quase quatro anos e boa parte dos desenvolvedores web já conhece e deseja as novidades. Entretanto, o termo HTML 5 é usado como um “guarda-chuva” para diversas melhorias em HTML, JavaScript e CSS, o que dificulta a tarefa de avaliar sua maturidade e adoção. Existem tanto os que defendem que o HTML 5 deva ser adotado, quanto os que apresentam controvérsias, principalmente os problemas de segurança do JavaScript e as diferenças entre os navegadores.

A adoção do HTML 5 certamente depende das necessidades de cada aplicação, mas considerando as funcionalidades mais desejadas nos navegadores modernos, já podemos usá-lo?

Funcionalidades

Para responder a essa pergunta precisamos definir claramente o que significam “funcionalidades mais desejadas” e “navegadores modernos”. As primeiras são aquelas que tornam possível ou facilitam muito a implementação dos requisitos de aplicações ricas para a web. É o caso das funcionalidades definidas pelos conjuntos de tecnologias e especificações, que são apresentados a seguir.

Aplicações Offline

  • Cache da aplicação
  • Persistência chave-valor

As funcionalidades para aplicações online são importantes para trazer a experiência de aplicações desktop para a web, principalmente em ambientes onde a conexão com a internet é lenta ou eventual. A persistência ainda é limitada a 5 MB na maioria dos navegadores, mas é importante notar que esses “bancos de dados do navegador” não têm o objetivo de armazenar todos os dados do usuário indefinidamente; apenas de retê-los até a próxima sincronização com o servidor ou acelerar a carga de páginas.

Novas APIs JavaScript

  • Web Sockets
  • Web Workers
  • Geolocalização
  • Histórico do navegador

As novas APIs JavaScript simplificam o desenvolvimento de diversas funcionalidades que hoje dependem de tecnologias proprietárias não padronizadas ou de particularidades dos navegadores.

Estilo e semântica

  • Tags Semânticas (article, nav, section etc.)
  • Layout em colunas
  • Opacidade
  • Cantos arredondados e bordas

As tags semânticas e o CSS3 são muito importantes para os web designers, que com elas poderão reduzir e melhorar a codificação de layouts de páginas, além de fazer com estilos o que hoje é feito de forma muito mais trabalhosa com imagens, ou mesmo código JavaScript.

Multimídia

  • Tags audio e video
  • Gráficos 2D (tag canvas )

Usando as tags multimídia e para desenho em 2D, o desenvolvedor pode reduzir muito a necessidade de plugins externos, como Java e Flash. Há ganhos em produtividade, desempenho e segurança.

Para conhecer mais sobre estas funcionalidades e diversas outras propostas pelo HTML 5, recomendo esta excelente apresentação do grupo html5rocks.

Navegadores

Para verificar o suporte dos navegadores, vamos considerar a versão mais recente e uma anterior dos três navegadores mais usados no desktop (IE, Firefox e Chrome) e os navegadores padrão dos dispositivos iOS (iPhone/iPad/iTouch) e Android. A tabela abaixo detalha o suporte às funcionalidades selecionadas. Os dados vêm do site caniuse.com, que rastreia a implementação do HTML5 pelos browsers.

IE Firefox Chrome iOS Android
9 8 6 5 13 12 4.3 4.1 2.3 2.2
Cache da aplicação N N S S S S S S S S
Persistência chave-valor S S S S S S S S S S
Web Sockets N N S P S S S N N N
Web Workers N N S S S S N N N N
Geolocalização S N S S S S S S S S
Histórico N N S S S S P N S S
Tags semânticas S N S S S S S S S S
Multimídia S N S S S S S S S N
Gráficos 2D S N S S S S S S S S
Layout em colunas N N S S S S S S S S
Opacidade S P S S S S S S S S
Cantos arredondados S N S S S S S S S S

Pode-se ver que o suporte dos navegadores às funcionalidades fundamentais destacadas nesse artigo já é razoável. As principais deficiências estão no Internet Explorer e no suporte a Web Sockets e Web Workers, principalmente nos smartphones.

Os Web Workers, que são scripts executados em background, juntamente com com os Web Sockets (canais de comunicação bidirecionais com o servidor), são importantes para aplicações onde os usuários interagem entre si, como em chats e jogos. Para contornar a falta de suporte no IE e nos smartphones, pode-se usar AJAX Reverso (Comet) ou frameworks como o Atmosphere e o Kaazing, que permitem que se desenvolva a comunicação bidirecional usando as funcionalidades disponíveis em cada navegador.

As deficiências do Internet Explorer são mais difíceis de se contornar. Além de sugerir que o usuário atualize o navegador, uma alternativa para ter maior suporte ao HTML5 no IE é recomendar a instalação do Chrome Frame, um plugin que faz com que o IE (6 ou mais recente) apresente as páginas usando o engine do Google Chrome.

Conclusão

Claramente, o suporte ao HTML 5 melhora a cada versão dos navegadores e, nos casos em que não é totalmente suportado, existem alternativas. Decidir se o HTML 5 está maduro o suficiente e se as alternativas são aceitáveis ainda é muito particular para cada aplicação. Mas nos casos em que pode ser usado, o HTML 5 certamente torna possível (ou muito mais simples) o desenvolvimento de aplicações ricas para a web.

Fonte: InfoQ