As melhores ferramentas para validar seu código

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.
html validator

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.
CSS validator

copyJá 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.
link checker

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.

Recurso de impressão amigável – Todo site deveria ter

A dias atrás escrevi uma matéria falando de material de estudo sobre padrões web em português . Lendo a apostila criada pelo e-gov, tem um tópico com esse título.

Mas o que é uma “impressão amigável”?

Impressão amigável, é definir um css só para o usuário imprimir o conteúdo.

Quando mandamos imprimir uma página, estamos interessados somente no conteúdo. A página de impressão não deve vir com menu, cabeçalho, rodapé, banner, background do site, ilustrações enormes, etc etc… e é possível retirar esses elementos na hora do impressão com um css a parte.

copyNão é dificil, no tidbits nós usamos um template pronto de wordpress (que naturalmente, veio sem um css de impressão) e pra colocar eu criar um, não demorou nem 10 minutos.

O uso de folhas de estilo para equipamentos específicos é feito através do atributo media, existem vários tipos de media, mas na prática somente 3 tipos são usados, veja a relação abaixo de medias e dispositivos:

  • all – todos os tipos de dispositivos;
  • screen – computadores;
  • print – impressoras;
  • handheld – PDAs, mobiles palmtops;

Existem duas formas de escrever um atributo media que é colocado sempre dentro do <head> é claro:

Chamada externa:

<link media=“screen” type="text/css" href="style.css" rel="stylesheet"/>
<link media=“print” type="text/css" href="print.css" rel="stylesheet" />

<!-- ou assim pra quem prefere com import !-->

<style type="text/css">
@import url("style.css") screen;
@import url("print.css") print;
</style>

Repare que chamamos um css pra tela e um pra impressão.
Quando o atributo media não é declarado o padrão é media=”all”.

ou no css:

@media screen { 
	h1 { font-size:28px; color:#ff0;}
}
@media print { 
	h1 { font-size:14px; color:#000;}
}

Basicamente é bem rápido, não é necessário mexer em muitas tags, veja o que foi necessário para implementar aqui no tidbits:

@media print { 
	div#header, div#footer, div#sidebar-wrapper, 
	p.bookmark-me, div.post-footer, 
	form#commentform, h3.comentar {
		display:none;
	}
}

8 erros de CSS que você não deve cometer

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 :)