TidBits

CSS Sprites é uma técnica muito usada em grandes portais que serve para melhorar o desempenho do site diminuindo o número de requisições HTTP. É uma técnica bem simples que serve para unir várias imagens em um só arquivo e posicionar o conteúdo através de CSS.

Ficou tudo muito abstrato né?

Imagine o seguinte menu (onde cada time tem um link próprio):

Agora pergunto:

Quantas imagens são necessárias pra fazer essa coleção de escudos de times?

Apenas uma imagem.

Fixando a altura e a largura de cada botão, podemos posicionar o background de cada link com o css position.

É mais trabalhoso, mas tem vantagens:

Carregando uma imagem grande ao invés de várias imagens pequenas, economizamos banda (nesse exemplo eram 31kb agora são 11), porque pra cada imagem tem cabeçalho, paleta de cores usadas na figura, enfim, uma série de dados que se repetiam em todos os times. E quando tempos uma figura só no lugar de 32, esses dados são preenchidos uma vez somente, e assim economizamos banda.

Além disso, o que melhora e muito a velocidade, é fazer uma só conexão HTTP. Em arquivos muito pequenos, costuma demorar mais pra estabelecer uma conexão com o servidor do que o próprio download em sí. Então, 31 conexões a menos com o servidor, dão uma boa diferença no tempo total do load da página.

É simples pra fazer, tem duas formas.

Imagine o HTML desse exemplo:

<ul class="escudos">
	<li><a href="/atleticomineiro">Atlético Mineiro</a></li>
	<li><a href="/atleticoparanaense">Atlético Paranaense</a></li>
	<li><a href="/barcelona">Barcelona</a></li>
	...
</u>

A primeira forma, que eu acho mais simples, funciona como um “mapeamento” da imagem:

/*
	Adicionando a única imagem de
	backgrounde e definindo largura na UL
 */
ul.escudos{
	background:url('times.png');
	width: 280px;
}

/*
	Posicionando os LI's com float
	como fazemos normalmente
*/
ul.escudos li{ float:left; }

/*
	Definindo uma largura e altura fixa para
	os links e adicionando text-indent negativo
	para fazer o imagem-replacement
*/
ul.escudos li a{
	width:35px;
	height:35px;
	display:block;
	text-indent:-9999px;
}

A segunda forma é uma coleção de css position

/* Definindo a largura somente */
ul.escudos{	width: 280px;}

*
	Posicionando os LI's com float
	como fazemos normalmente
*/
ul.escudos li{ float:left; }

/*
	Definindo uma largura e altura fixa para
	os links e adicionando text-indent negativo
	para fazer o imagem-replacement
*/
ul.escudos li a{
	width:35px;
	height:35px;
	display:block;
	text-indent:-9999px;
}

/*
	Adicionando o background com todos
	os escudos em todos os li's
*/
ul.escudos li{ background:url('times.png'); }

/*
	Adicionando um background para cada li
	(seria necessario colocar uma classe / id
	para cada elemento). Veja os exemplos:
*/
ul.escudos li.atleticomineiro { background-position: 0 0; }
ul.escudos li.atleticoparanaense { background-position: 35px 0; }
ul.escudos li.barcelona { background-position: 70px 0; }

A mesma técnica pode ser aplicada em menus, principalmente com mouse over:

<ul class="menu">
	<li class="videos"><a href="videos.php">Vídeos</a></li>
	...
</u>

A imagem é uma só para o estado normal e o estado com over.

E no CSS:

#menu li.videos a {
	background: url('/images/video.gif');
	display: block;
	width: 71px;
	height: 19px;
	text-indent: -9999px;
}
#menu li.videos a:hover { background-position: bottom; }

Repare que o height do link é metade do tamanho da imagem, assim, quando passa o mouse por cima do botão, o background é movido pra baixo dando a sensação de duas imagens diferentes.

Ultimamente tenho visto scrips interessantes em javascript simulando aquele efeito muito comum no flash o qual chamamos de parallax.

No dhteumeuleu, no CSSLab e no Stephband tem exemplos bem legais e bem complexos dessa técnica.

E essa semana, fazendo um freela, precisei criar algo nesse estilo. E acabei criando um script BEM SIMPLES que simula core do efeito.

Veja o exemplo abaixo e passe o mouse em cima:

Vou explicar como fiz:

O HTML:

<div id="container">
	<div id="conteudo">
		<img src="_images/parallax.jpg" alt="Parallax"/>
	</div>
</div>

O CSS:

	#container { width: 460px; height: 304px; position: relative; overflow:hidden; }
	#conteudo { position: absolute; left:0; top:0; }

E o javascript (usando jQuery):

$(document).ready(function(){
	if($('#conteudo').width()>$('#container').width()){
		var pos_x = $('#conteudo').offset().left;
		var container = $('#container').width();
		var conteudo = $('#conteudo').width();
		var diferenca = conteudo - container;
		var metade = - parseInt(diferenca / 2);
		$('#container').mousemove(function(e){
			x = e.pageX - pos_x;
			porcentagemX = parseInt(x / container * 100);
			left = parseInt(0 - (diferenca  / 100 * porcentagemX ));
			$('#conteudo').css('left',left);
		});
		$('#conteudo').animate({ 'left':metade },1000);
	}
});

Vou explicar basicamente o que o script faz, linha a linha.

1 - Faz com que a função seja executada quando terminar de carregar a página;

2 - Verifica se a área do conteúdo é maior do que a do container pra poder aplicar o efeito;

4 a 8 - Declara variáveis com os valores dos elementos;

10 - Escreve uma função que será executada toda que passar o mouse em cima do elemento “container”;

11 e 12 - Obtem a posicao do mouse (em porcentagem) em relação a div “container”, elemplo, se o mouse tiver bem no meio do container, a posicao é de 50%, mas se o mouse tiver bem na direita do container então a posição será próxima a 100%;

13 e 14 - Com a porcentagem obtida, é só posicionar o left do conteudo. O conteúdo não precisa ser uma imagem, pode ter quaisquer elementos dentro.

17 - Para o usuário perceber o efeito, é legal centralizar o conteúdo, usando o animate do jQuery já mostra o movimento.

Apesar do exemplo bobo aqui nesse post, esse script da liberdade pra fazer efeitos mais complexos. È mais facil trabalhar em cima dessa base do que usar um plugin de jQuery com mil opções.

Pra quem achou legal, pode fazer o download do exemplo completo.

O seu browser estar apresentando seu site corretamente não significa que seu código esta correto e também não significa que vai funcionar em mais 40 browsers que são usados atualmente. Programar a interface de um site é bem diferente do que programar numa linguagem server side onde, se você esquecer um “;” ou não fechar um if, seu código nem roda. Programando no lado do cliente, diversos erros de html são “consertados” pela maioria dos browsers. Ou seja, você esquece de fechar uma tag, ou coloca um <h1> dentro de um <a> no seu browser e aparece tudo ok, mas é errado.

Ok, mesmo que o site seja testado no Firefox, ie6, ie7, Safari, Chrome e Opera, quem garante que os navegadores Netscape 6.0, Ant Galio 3.1, Blaze 6.0 ou o Playstation 3 5.0 vão interpretar corretamente também?

E é por isso que devemos validar o código. Existem diversas ferramentas para validação de código.

A mais importante delas, creio que é o HTML validator, uma extensão de firefox. Além de válidar seu (x)html, ele diz o que está errado e como consertar o que é ótimo pra quem está começando a programar interface.

Para validar CSS, a melhor opção é o CSS validator da W3C. Infelizmente não existe (ou não conheço) nenhuma opção desktop. Mas mesmo assim, vale a pena utilizar.

Já o link-checker é um validador de links que analisa seu site e procura por links quebrados, muito útil. A análise é BEM completa, e demora muito tempo, afinal ele checa tudo. Analisando a home do TidBits ele demorou 286 segundos e checou mais de 200 arquivos.

Outras ferramentas como o firebug, ajudam bastante na codificação, principalmente pra detectar erros de JavaScript. E finalmente, para garantir a acessibilidade do seu site, existe diversas opções, duas em português: o Da Silva e o ASES desenvolvido pelo governo eletrônico.

Inspirada pelo meu último post, e pelo artigo do Glen Stansberry resolvi aproveitar o momento para incentivar a avaliação não só da usabilidade de um site, mas também do CSS. Agradecendo a dica do Jamaica segue a minha lista “adaptada” do que eu acho que ninguém deve fazer com o CSS do site:

1. Ignorar a compatibilidade de browser
A gente já falou um monte sobre crossbrowser aqui no Tidbits. Já falamos de truques para checar se o seu site está compátivel com todos os navegadores, ensinamos a utilizar os Global Resets para zerar as propriedades automaticamentes setadas pelos browsers, e o Danilo no post anterior falou sobre o CSS compatível sem uso de hacks. Com esse material todo, você não pode nem pensar em deixar o seu CSS “quebrar”…

2. Não validar o HTML e o CSS
Também no post sobre garantir a qualidade do seu site em todos os browsers, eu dei o link de ferramentas de validação. Passem por elas para garantir um código semântico!

3. Não utilizar classes para formatações que se repetem em vários elementos
Se você tem elementos que tem propriedades de formatação iguais, utilize apenas uma class para definir essas propriedades para todos elementos. Se você tem em uma página, por exemplo, todas as fotos e boxes de um site tem borda e flutuam a direita, você pode simplesmente criar uma class para definir esses atributos e invocá-la em todos os elementos que a utilizam. Se, por um acaso, você precisasse mudar a cor da borda, teria que fazer isso em todos os elementos, se não atribuir a propriedade uma única vez.

4. Utilizar nomeclaturas ruins para classes e ids
Isso pode ser uma questão aparentemente insignificante, mas se você precisar fazer qualquer alteração no CSS depois de um tempo, vai se arrepender amargamente de não ter gastado 2 segundos a mais do seu tempo para pensar em um nome mais descritivo do que #box_top ou .coluna_left. Rótulos orientados à posicionamento ou ao formato do conteúdo dificultam a manutenção e substituição desse CSS.

5. Usar CSS para tudo
Quando se abandonaram os layouts com tabelas as tabelas ficaram tão mal faladas que até quando se precisa de tabelas, as pessoas tentam fazê-las da maneira mais díficil. O conceito é “Tableless” e não “Tablenone” - com o perdão do trocadilho infeliz. Enfim, o HTML precisa ser semântico, e quando você exibe dados em uma tabela, nada mais semântico do que utilizar uma tabela mesmo, não?

6. Usar CSS inline
Um dos piores erros que se pode cometer, é não se utilizar o conceito de “layers” (camadas), na hora de desenvolver uma interface. Na época que eu aprendi a mexer com o Photoshop, eu levei um tempo até perceber o qual importante era esse conceito, de manter cada coisa, em um plano diferenciado, e como isso facilitava a aplicação, manutenção e alteração de qualquer erros. Esse conceito é igualmente aplicável para o CSS, mantenha ele sempre em um arquivo externo. Um dos principais problemas remete ao item 3 dessa lista: com o CSS inline, você precisaria atribuir os valores para cada elemento individualmente, o que se transformaria em um caos, quando precisasse fazer modificações no layout.

7. Carregar muitos arquivos de CSS
Dividir o conteúdo do CSS em arquivos separados, facilita a manutenção - até certo ponto. Se você divide demais o CSS, pode acabar dificultando não só a manutenção, pela dificuldade de encontrar o arquivo que exatamente está procurando, como também o carregamento da página. Arquivos de CSS são bem leves (em sua maioria), o problema é que muitas conexões com o servidor, que precisam ser feitas para cada arquivo de estilo que for baixado, normalmente demoram mais que o próprio download. Normalmente, eu e o Danilo utilizamos um arquivo default.css setando propriedades que replicam em todo o site, por exemplo o CSS do Header, Footer, Menu lateral, e coisas do tipo. E criamos para cada área, o arquivo nomedaarea.css com as propriedades específicas da página, ou por exemplo um conteudo.css com as propriedades de css de páginas geradas dinamicamente.

8. Não utilizar o Firebug para acelerar os ajustes do css
O Firebug é uma ferramenta mais importante que o editor de códigos. Se um layout está com problemas de posicionamento, ou você está com dificuldades de entender porque uma div está herdando um padding fantasma de algum lugar, o Firebug ajuda você identificar quais são as propriedades de css que estão influenciando aquele elemento. Além do CSS, ele também facilita visualizar a estrutura do HTML, e identificar possíveis erros.

Acho que seguindo essa lista, já é possível otimizar o tempo de desenvolvimento, e ao mesmo tempo fazer um CSS de melhor qualidade. E se alguém se lembrar de algum outro erro que também poderia ser evitado, fique a vontade para comentar, e construirmos nossa lista juntos

Ví hoje no DGmike que saiu uma matéria no Ajaxian dizendo que o Firefox 3.1 que deve sair em breve vai suportar as tags de áudio e vídeo. Atualmente o formato suportado pra vídeo é somente o ogg mas outros formatos estão sendo discutidos para serem implementados no futuro.

Para chamar, vai ser bem simples:

<video src="videos/teste.ogg" autoplay="autoplay">
Seu navegador não suporta vídeo
</video>

E se quiser mandar dar play ou pause com javascript, será bem simples também:

<script type="text/javascript">
    document.getElementsByTagName('video')[0].play()
</script>  

Ou por jQuery:

<script type="text/javascript">
    $('video')[0].play();
</script>  

O HTML5 está apenas iniciando a ser implementado nos novos browsers, mas dá pra ver que vai mudar muita coisa, dando muito mais ferramentas a nós, programadores de interface.

Recentemente o site do Governo Eletrônico lançou um projeto implementar padrões web no site do governo. E inclusive lançou uma cartilha de codificação para auxiliar as administrações públicas.

O objetivo da cartilha é:

• Estabelecer padrões de qualidade de uso, desenho, arquitetura de informação e navegação;
• Estabelecer um fluxo de criação, desenvolvimento e manutenção na gestão dos sítios governamentais;
• Consolidar a acessibilidade;
• Criar artefatos de acordo com os padrões estabelecidos pelo W3C.

A apostila pode ser lida por qualquer desenvolvedor web, pois fala de padrões web em geral e não de sites do governo.

Clique aqui para baixar a cartilha.

Outra coisa que chamou a atenção essa semana, foi o blog do Danilo Nunes, ele está traduzindo um curso sobre padrões web que funcionários da Opera fizeram pra implementar nas universidades americanas, um projeto bem legal.

O curso (original, em inglês) tem 50 artigos, cada um bem detalhado. O Danilo Nunes disse que vai traduzir um por semana.