Tableless » tableless

Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas

Diego Eis — Wed, 09 May 2012 16:53:47 +0000

Existem três categorias de “ferramentas” que nos ajudam a desenvolver um projeto client-side: Préprocessadores, Frameworks e Bibliotecas.

Préprocessadores

Préprocessadores são ferramentas onde você escreve CSS de uma determinada forma, modificando sua sintaxe, fazendo com que na hora de sua utilização o código CSS precise ser préprocessado para que o código escrito seja transformado em código CSS puro e assim então os browsers consigam entender.

Existem muitos préprocessadores no mercado como Less, Sass, Turbine, Switch CSS e outros.

Particularmente eu não gosto de usar préprocessadores. Para começar é necessário que você aprenda a linguagem de cada um e a ideia de que seu CSS precisa ser compilado para poder funcionar não me agrada muito. O CSS é simples demais para complicarmos desse jeito. Entretanto, há uma série de coisas interessantes que podemos fazer com os préprocessadores como variáveis, funções, operações e etc que demorarão um pouco (ou não) para fazerem parte do core definitivo da linguagem. Mesmo assim, pessoalmente, para a maioria dos projetos, não vale a pena.

Frameworks

Frameworks são diferentes de préprocessadores mas são muito parecidos com Bibliotecas. Um Framework disponibiliza para o dev um conjunto de estilos e estruturas prontas para a utilização em projetos de forma escalável e uniforme. Normalmente os frameworks te dão uma coleção de componentes para que sejam usadas por todo o projeto. Esses componentes na maioria das vezes já vem com estilos visuais aplicados, bem como a estrutura. Veja por exemplo o Bootstrap ou o Blueprint.

Com o Bootstrap você consegue, rapidamente, fazer um protótipo simples ou uma estrutura básica de sistema. É o preferido dos programadores. Os elementos visuais já foram criados e desenhados. Talvez não seja uma boa ideia você utilizar um framework em um projeto cujo design já esteja aprovado. Você teria muito retrabalho para “zerar” o estilo visual de cada elemento para depois reconstruí-lo utilizando o seu design.

É muito importante que o uso de um framework CSS/Javascript seja aprovado no início de um grande projeto. Mesmo que você planeje criar um framework do zero, específico para seu projeto. O que na maioria das vezes não vale a pena.

Bibliotecas

Bibliotecas CSS geralmente não modificam o visual como os Frameworks fazem, mas eles disponibilizam uma coleção de classes, reutilizáveis e o melhor, combinatórias, para que se adeque a diversos cenários do seu projeto. Como essas classes não estão ligadas a nenhuma formatação visual, você consegue combinar sem grandes problemas com suas classes e IDs, modificando a hora que quiser a formatação visual dos elementos.

As bibliotecas são indicadas para projetos mais simples, sem grandes apetrechos técnicos, como um site ou algo parecido. Para fazer um sistema, as bibliotecas irão reforçar os Frameworks, facilitando a organização e formatação da estrutura do site. A biblioteca também ajuda na manipulação dos elementos via Javascript se baseando por estas classes prontas.

A verdade é que hoje é muito difícil diferenciar uma biblioteca de um framework.

Como todos eles trabalham juntos?

Você pode usar todos os três ao mesmo tempo em um projeto. Mas não é muito inteligente, já que se você estiver utilizando um framework, muito provavelmente ele terá uma “biblioteca” em sua base. Imagine que a biblioteca pode ser específica de estrutura ou formatação visual. O Framework, basicamente, junta os dois. Obviamente há mais coisas envolvidas. Mas para simplificarmos a explicação, imagine que um Framework é a mistura dessas duas bibliotecas.

O Preprocessador é independente do Framework e da Biblioteca. O seu ganho está ao escrever um código mais escalável, muitas vezes melhorando ou piorando a sintaxe do código. É pura sintaxe, não são classes prédefinidas. Mesmo assim você pode basear seu Framework/Biblioteca em um Préprocessador. O Bootstrap faz isso para facilitar features dinâmicas como grids, cores e etc.

Como eu disse, eu não gosto de misturar as coisas. Prefiro utilizar o Bootstrap puro, sem a interferência de nenhum préprocessador. Mas, há gosto para tudo.

Qual deles é melhor para o meu projeto

Eu não sugiro que você utilize um framework para criar websites institucionais. Websites geralmente não usam os mesmos elementos, nem as mesmas estruturas, nem o mesmo design. Logo, se você utilizasse um framework como o Bootstrap, ou o JQuery UI, você acabaria gastando mais tempo reestilizando e brigando com o CSS já criado dos frameworks do que fazendo o que realmente importa: o seu trabalho.
Logo, para projetos de pequeno porte eu sugiro que você utilize uma biblioteca simples. Sugiro ainda que essa biblioteca seja criada por você.

Não precisa de muito. Em uma biblioteca você só precisa ter algumas propriedades que fazem tarefas básicas, como fazer o elemento flutuar para a esquerda, para direita, clear, retirar margens e etc. Normalmente eu utilizo um reset chamado Normalize. Ele já reseta meu CSS inteiro e então eu me foco apenas nas propriedades que eu reutilizarei no resto do projeto.

Se seu projeto for médio ou grande, você já pode pensar em utilizar um Framework. Principalmente se seu projeto for um sistema. Você já vai ter à disposição estilos para formulários (que são um saco pra fazer), botões, grids, reset CSS e outras coisas. O trabalho fica mais fácil por que você tem menos arestas para acertar. Ainda mais se o designer aceitar utilizar alguns dos estilos já prontos do Framework, assim você não precisa reconfigurar formatações visuais e etc.

A utilização do Préprocessadores é totalmente opcional. Mas se você decidir utilizá-lo juntamente com algum Framework, procure saber se o Framework escolhido suporta algum tipo de préprocessador. O Bootstrap, por exemplo, tem uma versão para LESS.

No próximo artigo vou contar como estamos fazendo aqui na Locaweb. Estamos criando uma grande biblioteca visual e de front-end que será utilizado por todos os serviços. Os programadores conseguem subir um sistema sem precisar esperar um código HTML definitivo, utilizando os módulos dessa biblioteca. A galera de design faz todos os layouts padronizados visualmente, garantindo a uniformidade de todos os sistemas. E o pessoal de front? Bom o pessoal de front cuida para que tudo isso funcione.

Posts Relacionados

Qualidade de Imagens e densidade de pixels

Diego Eis — Mon, 26 Mar 2012 13:13:42 +0000

Você se lembra quando planejavamos nossos layouts para resoluções acima de 1024? Chega ser engraçado lembrar que um dia fizemos websites para 640×480, pensando que a resolução de 1024×768 eram a minoria dos usuários. Os tempos mudaram e naturalmente diversas outras resoluções apareceram por conta de novos dispositivos, melhores monitores e etc. Acontece que na web nada é tão fácil assim. A gente se livra de um problema, mas aparece outro no lugar.

Este ano eu estou trabalhando a maior parte do tempo em um monitor fullHD. Notei uma diferença gritante ao digitar código pela primeira vez em um monitor desses. E não são apenas os monitores que estão mudando para uma resolução decente. Também, seguindo o ciclo natural, dispositivos menores estão recebendo a dádiva de ter a alta resolução em suas telas. E isso, meu caro, é uma dádiva para o usuário, para você é mais trabalho.

Pixels não são mais como eram antigamente

Na minha época de escola – nem tanto tempo assim – os professores me ensinaram que o átomo era indivisível. Era incrível por que eu, como criança, me divertia tentando entender como algo poderia ser tão pequeno que não pudesse ser partido ao meio, ficando menor… Mas aí eu descobri que os prótons, os elentrons e outras partículas subatomicas existiam também…

A mesma coisa aconteceu com o pixel. O pixel sempre representou a menor unidade da sua tela. Para os designers, o pixel é a unidade central. É onde tudo se baseia: medidas, tamanhos, alinhamentos etc… Mas o pixel não é mais como era antigamente.

Com o advento das telas HD em aparelhos móveis, o conceito de pixel mudou um ~~pouco~~ muito. Quando a tela retina display do iPhone 4 foi lançada o queixo de todo mundo caiu. A Apple conseguiu apertar quatro pixels onde apenas caberia um. Logo o pixel pode ser definido como a menor unidade na tela, como você já conhece ou pode ser baseada em uma unidade chamada hoje em dia de “pixel referência” ou do inglês reference pixel: que significa que esse novo “pixel” é uma referência ótica de unidade.

Para entrar em detalhes, leia o que é um pixel. Vai te ajudar a entender melhor.

Densidade de pixels

A sigla DPI significa Dots Per Inch, ou seja, é o número de pixels que seu dispositivo pode conter em uma polegada. Quanto mais pixels em uma polegada, mais nítida a imagem é.

Os aparelhos como o iPhone 4 e outros que carregam Android tem uma densidade de pixels muito alta. Ou seja, eles conseguem comprimir um grande número de pixels em suas telas, tornando as imagens melhores. O problema é que as imagens que criamos hoje podem parecer ruins nesses dispositivos. Algo parecido como aumentar uma imagem pequena no Photoshop, entende? Ela fica toda pixelada, sem qualidade nenhuma. Isso por que você está aumentando o tamanho de uma imagem que é pequena e não tem pixels suficientes para dividir pelo tamanho que você definiu.

Entenda fazendo um teste: Vá até o site da Apple utilizando SAFARI. Agora, dê um zoom em alguma imagem. Veja como ela parece pixelada por causa do zoom. Agora abra o Inspector do seu navegador, vá até o console e coloque as duas linhas abaixo:

1 2	AC.ImageReplacer._devicePixelRatio = 2 new AC.ImageReplacer()

A imagem foi trocada para uma imagem com o dobro de tamanho da imagem original para que ela ficasse melhor em telas com alta densidade de pixels… Veja a diferença. Eu vi esse truque aqui.

Ações para otimizar

Existem algumas atitudes que vocês já pode tomar agora para poder chavear estes aparelhos e entregar uma experiência melhor para seus usuários.

Utilize media queries

Media Queries são um chuchuzinho. Você pode utilizar uma regra chamada device-pixel-ratio para detectar qual CSS servir dependendo do pixel-ratio do dispositivo. Não precisa ser maníaco e servir vários CSS para vários pixel-ratios… Você vai ficar doido se fizer isso.

Abaixo veja uma tabela de exemplos de aparelhos com seus valores de pixel-ratios:

Dispositivo	Resolução	device-pixel-ratio
Android LDPI	320×240	0.75
Iphone 3 & Android MDPI	320×480	1
Android HDPI	480×800	1.5
Iphone 4	960×640	2.0

Agora, como seria o CSS:

1
2
3
4

="stylesheet" media="screen and (-webkit-device-pixel-ratio: 0.75)" href="low-dpi.css" />
="stylesheet" media="screen and (-webkit-device-pixel-ratio: 1.0)" href="medium-dpi.css" />
="stylesheet" media="screen and (-webkit-device-pixel-ratio: 1.5)" href="high-dpi.css" />
="stylesheet" media="screen and (-webkit-device-pixel-ratio: 2.0)" href="retina.css" />

Eu sugiro que você se limite apenas para o pixel-ratio 2. Do jeito que as coisas estão andando, os aparelhos de pixel-ratio menor do que 2 desaparecerão logo e os aparelhos com pixel-ratio igual a 1 são maioria e você já faz versões para eles, já que não precisam de fallbacks.

Considere chavear versões de imagens

Este é um problema que ainda não existe uma solução inteligente e definitiva.
A ideia é tentar evitar que o usuário baixe duas imagens iguais, mas de tamanhos diferentes para cada tipo de necessidade. Logo, existem vários fallbacks, em Javascript ou linguagens server-side para servir apenas a imagem necessária.

O pessoal da Clound Four escreveu um artigo muito interessante sobre isso.

Há outros artigos bons por aí. Eu estou dando uma lida em vários para tentar escrever um artigo mais simples aqui no Tableless. Mas o assunto é muito vasto e ninguém tem uma opinião definida ainda. Isso não é útil apenas para a situação dos aparelhos hires, mas também para encontrarmos maneiras de servir imagens menores para versões de sites mobiles.

Text rendering

Você consegue melhorar muito a leitura dos usuários utilizando a propriedade text-rendering.

1	h1, h2, h3 { text-rendering: optimizeLegibility; }

Esta propriedade melhora muito a leitura quando o usuário dá o zoom nos aparelhos móveis e também corrige suporte de ligaduras e kerning. Coisa linda.

Text Smoothing

A propriedade font-smoothing é útil agora! A leitura melhora demais em monitores normais e previne serrilhamentos ocasionais quando utilizandos @font-face.

1
2
3
4
5
6
7

body * {
-webkit-font-smoothing: antialiased;
-moz-font-smoothing: antialiased;
-o-font-smoothing: antialiased;
-ms-font-smoothing: antialiased;
font-smoothing: antialiased;
}

Tente usar CSS3

Tente usar e abusar dos efeitos do CSS como sombras, gradientes, bordas arredondadas e etc. Além de facilitarem sua vida evitando a criação de imagens desnecessárias, elas ajudam na velocidade de carregamento do site.

Considere utilizar SVG

Já tem alguns que estão começando a utilizar SVG para facilitar a vida. Para ícones, SVG é ótimo. Você consegue reutilizá-los em diversos tamanhos, aumentando o diminuindo de acordo com a sua necessidade e também do aparelho. Veja um exemplo que a Smashing Magazine escreveu.

Novo elemento HTML

O W3C já criou um grupo chamado Responsive Images Community Group para a criação de elementos do HTML que facilitam a entrega de assets dependendo do contexto. Eles estão propondo um novo elemento que identifica as dimensões do dispositivo, velocidade de rede, densidade de pixels e outros pontos para servir melhor imagens e outros assets dependendo do contexto.

Muitos artigos para ler

Posts Relacionados

Boas práticas de Acessibilidade

Diego Eis — Mon, 23 Jan 2012 16:14:18 +0000

Preparei uma pequena (nem tão pequena assim) apresentação que mostra algumas boas práticas e técnicas sobre acessibilidade para sistemas e websites. São pequenos ajustes que podemos incorporar mesmo depois de todo o desenvolvimento pronto e que dão resultados importantes para adequação dos seus sites ou sistemas.

Apresentancao acessibilidade

Veja mais apresentações de Diego Eis

Posts Relacionados

Declarando idiomas no HTML

Diego Eis — Mon, 09 Jan 2012 10:00:42 +0000

Publicar conteúdo na web definitivamente não é a mesma coisa da publicação de conteúdo nos meios impressos. Quando imprimimos o conteúdo, temos como foco um determinado público de uma determinada região. Eu, estando no Brasil, não vou fazer uma revista em no idioma Japonês. Quando falamos publicação de conteúdo online a coisa muda de cenário. O conteúdo online pode ser acessado no mundo inteiro, não importa seu idioma. Obviamente se você conhece outros idiomas, você amplia suas possibilidades para encontrar conteúdo e novos sites.

Os desenvolvedores do mundo inteiro juntamente com os fabricantes de browsers e outros interessados, querem ter certeza que os navegadores, robôs de busca, leitores de tela e outros sistemas detectem da forma ideal o idioma correto.

A declaração do idioma no código HTML não determina a informação no encoding de caractére do texto nem a direção de leitura do texto em outros idiomas. Essas definições precisam ser declaradas separadamente.

Nós precisamos definir o idioma por alguns motivos:

Melhor pronunciação do texto em leitores de tela.
Para que os buscadores possam indexar o website no buscador do respectivo idioma. Por exemplo: não tem sentido o Google ranqueear muito bem um site em português no Google americano.
Selecionar as fonts corretas para mostrar na tela. Nesse caso para idiomas como Chinês.
Para que os browsers escolham o dicionário correto para a correção gramatical nativa em textos e formulários.
Renderizar a página rapidamente – o browser carrega o documento mais rápido quando o browser sabe qual o idioma nativo.

Definindo o idioma padrão do documento

Existem algumas maneiras que você pode definir o idioma padrão no documento exibido ou em partes do texto para aqueles termos em idiomas diferentes.

Podemos definir diretamente via metatag nativa:

1	<meta http-equiv="Content-Language" content="pt-br">

Pela Metatag podemos definir vários valores no atributo content:

1	<meta http-equiv="Content-Language" content="pt-br, en, fr, it">

Via HTTP Header:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

HTTP/1.1 200 OK
Date: Fri, 30 Dez 2011 10:46:04 GMT
Server: Apache/1.3.28 (Unix) PHP/4.2.3
Content-Location: CSS2-REC.en.html
Vary: negotiate,accept-language,accept-charset
TCN: choice
P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml
Cache-Control: max-age=21600
Expires: Wed, 05 Nov 2003 16:46:04 GMT
Last-Modified: Tue, 12 May 1998 22:18:49 GMT
ETag: "3558cac9;36f99e2b"
Accept-Ranges: bytes
Content-Length: 10734
Connection: close
Content-Type: text/html; charset=utf-8
Content-Language: pt-br

Via atributo lang nos elementos do HTML.

1	<p>Nós utilizamos o <span lang="en">mouse</span> para navegar na <span lang="en">web</span> por meios dos <span lang="en">browsers</span>.

Assim indicamos, principalmente para os leitores de tela, quais termos ele deve ler com o idioma nativo do termo.

Temos o costume de indicar o atributo lang no elemento html logo no início do documento para indicar que todo o conteúdo contido dentro do html está escrito em um determinado idioma.

1
2
3
4
5
6
7
8

<html lang="pt-br">
<head>
<title>Título</title>
</head>
<body>
</body>
</html>

Ordem de herança

Os meios de acesso, normalmente browsers, seguem esses passos de verificação para identificar o idioma:

Verifica se elemento HTML que tem o atributo lang, se não,
Verifica se pai mais próximo ao termo que tenha o atributo lang, se não,
Verifica se o documento tem a metatag definida , se não,
Verifica se o HTTP Header Content-Language tem uma tag de idioma definido. Se não,
O idioma é tratado como não reconhecido.

O W3C recomenda que você sempre utilize o lang no elemento html para definir o idioma padrão de todo o conteúdo e também em todo o termo encontrado no texto com idioma diferente do definido como padrão.

Declarações de idioma baseados nestes atributos são importantes para a maioria das aplicações web hoje, que vão desde as corretores ortográficos embutidos diretamente nos browsers até leitores de telas que interpretam as páginas web, etc etc.

Estas possibilidades são interessantes para que possamos globalizar ainda mais nossos projetos. Imagine por exemplo um website que ensina Russo para Chineses. É interessante que possamos marcar os termos dos dois idiomas de forma que os mecanismos trabalhem adequadamente em diversos meios de acesso. Os browsers precisam identificar quando o texto está em Russo ou quando está em Chinês. Os buscadores também precisam entender essa diferença, bem como os leitores de tela.

Aos poucos vamos padronizando características que antes eram ignoradas no desenvolvimento web. Não são ações muito difíceis de aplicar. Para começar, basta colocar o atributo lang no elemento html dos seus documentos e pronto.

Referências

Artigo que explica os Charsets, encodes e tabelas de caractéres no HTML.

Veja aqui a documentação oficial do W3C que fala sobre este assunto.

O W3Schools tem aqui uma listagem dos códigos de idioma que podem usados.

Posts Relacionados

Guia de Referência de HTML5

Diego Eis — Mon, 02 Jan 2012 15:07:13 +0000

Ter sempre um guia de referência sobre qualquer tipo de linguagem é sempre bom. Ainda mais quando é completo e atual. O pessoal do WDL nos presenteou com uma série de Cheat Sheets sobre HTML5.

Os guias são divididos em 3 gráficos: Um mostra as novas tags, o segundo mostra os eventos e atributos e o terceiro mostra o suporte dos browsers.

Cada Cada um diferencia as características novas, existentes ou não suportadas do HTML5. O visual deles é bem simples e muito fácil de entender. O mais legal é que dá para imprimir e deixar à vista para quando você ou a equipe precisarem.

HTML5 Tags Cheat Sheet

HTML5 Cheat Sheet By InMotion Hosting – A Virtual Private Servers Provider

HTML5 Event Handler Content Attribute Cheat Sheet

HTML5 Cheat Sheet By InMotion Hosting – A Web Hosting Provider

HTML5 Browser Support Cheat Sheet

HTML5 Cheat Sheet By InMotion Hosting – A Dedicated Server Provider

Posts Relacionados

Experiência deve ter começo, meio e fim

Diego Eis — Mon, 28 Nov 2011 23:55:31 +0000

Esse artigo pode parecer meio confuso, mas é apenas um pensamento que estive matutando. Não ligue se a ordem das ideias estiverem tortas e sinuosas.

Tive uma experiência muito ruim no primeiro dia de 2010: pulei na piscina com meu iPhone no bolso.
Ok, pode me xingar agora.

Depois da tragédia, ele durou rápidos 5 segundos, e faleceu. Não ligava, não apitava, não fazia nada. “Paciência”, falei para mim mesmo. No dia seguinte peguei um celular reserva que eu tinha guardado: um HTC Touch, com Windows Mobile 6 (não Windows Phone). Foi então que eu notei o porque o trabalho da Apple vicia os consumidores.

Estamos bem acostumados a utilizar um notebook ou um computador desktop, com monitor, teclado e mouse. A interface do sistema muitas vezes parece desaparecer quando se abre o navegador. A experiência de uso dos periféricos já é bastante conhecida e isso facilita muito a forma com que o usuário interaje com a interface. Há uma harmonia, se é que você me entende. A mesma coisa é dificil de acontecer quando utilizamos um dispositivo mobile. Em um dispositivo móvel você precisa de foco. Não há espaço para milhares de botões com dezenas de ações. É SIM e NÃO. É OK ou CANCELAR e mais nada. O que não é o caso do Windows Mobile. O Windows Mobile foi feito daquele jeito Microsoft. Muito, mas muito diferente do Windows Phone que está um primor. Com uma interface totalmente repensada, do zero, onde seu visual se integra com os outros sistemas da marca. Há uma homogeneidade na experiência do usuário quando ele usa a Live do XBOX, o Windows Phone e o Windows 8. A experiência é cross-platform. A Apple faz isso durante anos. E durante todos estes anos esse foi seu segredo. O famoso “eco sistema Apple”. Tudo funciona muito bem quando estamos com nossos iPhones, iPads, MacBooks e iPods. Se eu tenho um iPad, mas utilizo um PC, algo fica estranho. Funciona, mas fica estranho.

Assim como sistema dos mobiles, os sites precisam seguir a mesma fórmula de simplicidade e foco. Por isso, criar sites para mobiles é uma arte. É um jogo de prioridades. Você precisa saber o que é importante na página e focar naquilo. Há um bom trabalho de arquitetura de informação que precisa ser feito. E não se engane, as vezes é muito mais dificil desenvolver um projeto de arquitetura para mobiles do que para versões full.

O iPhone, e agora o Windows Phone, se destacam muito por conta dessa harmonia que citei acima. Há uma ligação em tudo ali. Quando você aciona o Safari, ele tem uma interface intuitiva, bem acabada e que não agride a usabilidade do site. O iPhone tem um browser 100% atualizado com os Padrões Web e isso ajuda um bocado o desenvolvimento de interfaces inteligentes.
E a Apple se preocupa com essa harmonia da qual estamos falando, ela prepara uma série de materiais que ajudam os desenvolvedores. São guias de desenvolvimento e referência com os princípios de design e usabilidade que garantem a experiência completa. Por causa disso os desenvolvedores e designers fazem ótimos apps, tornando a experiência do usuário completa e uniforme durante o uso do dispositivo.

É por isso que a vale a pena municiar os desenvolvedores e designers do mundo todo, para que a experiência não termine quando o consumidor feche o seu aplicativo ou abra o navegador. Experiência tem começo, meio e fim. A Apple se preocupa com essas etapas. Ela sabe que se o site abrir “quebrado” o consumidor vai xingar primeiro o aparelho e não site. Tudo é uma única experiência. Começa no sistema do aparelho e termina no site de um terceiro.

O resto dos aparelhos começam pecando por ter um browser ruim ou uma interface de uso complicada. Na maioria os browsers não dão suporte algum aos Padrões. Isso é um pecado. Se eu tenho um Smartphone, eu passarei mais tempo na internet, conectado, do que falando ao telefone. Esse é apenas um ponto sobre o porque um dispositivo móvel precisa ter um browser decente.

O usuário tem uma boa experiência quando consegue com sucesso a informação que procurava, sem bloqueios. Se ele consegue passar esse processo com sucesso, como se o dispositivo (mobile, desktop, notebook, leitor e tela etc) e o site/sistema fossem transparentes, aí cumprimos com o nosso dever.

Posts Relacionados

Performance do seu CSS

Diego Eis — Tue, 29 Mar 2011 13:00:27 +0000

Modular seu código CSS é uma boa prática para que o website carregue apenas o código necessário para montar a pagina que o visitante está. Por isso não precisamos carregar o código CSS que monta a página de contato uma vez que o usuário está na home, possibilitando um ganho de performance.
Podemos ainda melhorar um pouco mais nossa performance tendo atenção com a forma que escrevemos os seletores do CSS. Há algumas dicas que podemos seguir para que isso seja possível.

O seletor é a alma do CSS. É com ele que o browser procura e captura o elemento que você deseja formatar. Existem diversos seletores que possibilitam a captura de elementos em diversos cenários e necessidades. Com a atualizações dos browsers em relação a padronização do CSS 2.1 e do CSS 3, os desenvolvedores ganharam novos ferramentas e formas de capturar elementos.

Quero que você entenda que essas dicas são sugestões. Não seja um purista cabeça dura. Seja flexível e tolerante com alguns cenários que podem surgir durante o projeto. É bom sempre procurar o meio termo entre performance e velocidade de produção.

Outro ponto para pensar é que a má performance do CSS pode significar muito pouco perto de outros fatores como servidor, performance server-side, peso de imagens e outros fatores. Por isso é importante que você tenha em mente que fazendo as sugestões abaixo não é garantia de que seu site ficará super ultra rápido. =^)

Processo de leitura

O browser segue um processo de leitura muito fácil de ser entendido.
Todo o seletorer (se voce não sabe o que é um seletor de CSS, recomendo que leia isto e isto antes de continuar).

O sistema de leitura consiste em encontrar o elemento da extrema direita do seletor. Logo a leitura do seletor começa da direita para a esquerda. A medida que o browser lê o seletor, ele vai encontrando os elementos e só pára quando há um erro no seletor ou não encontra o elemento.

Tenha como exemplo este seletor:

1	ul li a {...}

Nesse primeiro momento, ao ler o elemento da direita, o browser seleciona TODOS os elementos A da página, independente se ele está ou não dentro de um LI.

“The style system matches a rule by starting with the rightmost selector and moving to the left through the rule’s selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.” – David Hyatt

Não use IDs ou Classes ligados a tags

EVITE:

1 2	div.content {...} div#geral {...}

RECOMENDADO:

1 2	.content {...} #geral {...}

Tente especificar os elementos

Sempre que puder tente especificar os elementos com IDs ou Classes em vez de escrever seletores longos.

EVITE:

1	nav#menu ul li a {...}

RECOMENDADO:

1	.menuitem {...}

Eu não gosto muito desta sugestão porque teríamos de colocar uma classe “menuitem” em cada um dos ítens do menu. O HTML ficaria horrível. Prefiro fazer como abaixo. Não é a melhor forma (como eu cito no próximo tópico), mas é um meio termo entre performance, flexibilidade e produção de código:

1	#menu a {...}

Não misture IDs com nomes de tags e classes

EVITE:

1 2	button#botaoverde {...} .menu#menuPrincipal {…}

RECOMENDADO

1 2	#botaoverde {...} #menuPrincipal {…}

Não coloque nomes de tags nos nomes de classes

Muita gente relaciona o nome da tag ao nome da class ou id do CSS. Essa prática pode confundir posteriormente tanto na manutenção quanto no processo de produção por pelo menos dois motivos: 1. Você pode atribuir essa classe a elementos diferentes e não somente aquele que você relacionou no nome. 2. A classe pode fazer muito mais do que estava descrito inicialmente.
Por isso é interessante que cada nome de Classe seja ÚNICA e não seja relacionada a nenhum elemento em específico.

EVITE:

1	li.selected {...}

Bom, mas não muito:

1	.liselected {...}

RECOMENDADO:

1	.selected {...}

Evite seletores filhos

Sempre tente evitar declarar hierarquia nos seletores. Sempre que puder, coloque o nome do elemento diretamente por meio de class ou id. Mesmo assim tenha em mente a limpeza do seu HTML. Se você já aplicou boa parte dessas sugestões no resto do site, você pode abrir mão em alguns lugares que poderão ser úteis como na criação de um menu.

EVITE:

1	section form#cadastro fieldset label input.Text {...}

RECOMENDADO:

1	input[type="text"] {...}

Evite seletores descendentes

Os seletores descendentes são os seletores tem menos performance no CSS.

EVITE:

1	section article h1 {...}

É bom, mas nem tanto:

1	section > article > h1 {...}

RECOMENDADO:

1	.tituloh1 {...}

Claro que é muito complexo colocar uma classe nos títulos do site, ainda mais se os títulos são gerados por outras pessoas. Por isso prefiro, dependendo do site, dependendo do cliente, dependendo de como eu acordar de manhã, utilizar a primeira sugestão, que está marcada para EVITAR. Lembre-se ache o meio termo.

Referências:

Posts Relacionados

CSS3 – Abas com a pseudo-classe :target

Diego Eis — Mon, 21 Mar 2011 17:30:03 +0000

O CSS está cada vez mais facilitando as coisas. Alguns problemas que eram resolvidos apenas via Javascript já podem ser resolvidos inteiramente com CSS. Obviamente que para alguns browsers temos que usar algum script para conseguir a compatibilidade. Mesmo assim, se for já possível utilizar as novas maravilhas do CSS 3 e outras compatibilidades que estão surgindo do CSS 2.1, faça-o já. Você com certeza vai se agradecer um tempo próximo!

Um caso muito comum na produção de sites é a construção de tabs. Todo desenvolvedor já deve ter feito pelo menos uma vez na vida um script de tabs. Com a pseudo-classe :target seus problemas acabaram.

Quando queremos relacionar um link na própria página, utilizamos o recurso de “âncora”. Quando colocamos um link com o valor assim:

1	<a href="#nome-da-ancora">Link</a>

Falamos para o browser que ao clicar no LINK, ele deve encontrar um ponto na página chamado, nesse exemplo, nome-da-ancora. Ele vai encontrar o elemento na página que tenha um ID com esse nome e navegará a barra de rolagem até a posição deste elemento. Você já deve saber disso e já deve ter visto funcionando.

Com a pseudo-classe :target isso ganha nova vida. O :target consegue relacionar isso a um objeto de forma que se você estiver criando abas (tabs), ele mostra automaticamente a aba relacionada. Vamos ao exemplo. Primeiro faça um HTML como o abaixo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<ul class="itens">
<li><a href="#aba1">Aba 1</a></li>
<li><a href="#aba2">Aba 2</a></li>
<li><a href="#aba3">Aba 3</a></li>
</ul>
<div class="aba">
<div id="aba1">
Primeira Aba
</div>
<div id="aba2">
Primeira Aba 2
</div>
<div id="aba3">
Primeira Aba 3
</div>
</div>

Note um detalhe muito importante: o valor do HREF dos links é exatamente o nome do ID dos DIVs referente ao conteúdo das abas.

Agora, para formatar e deixar bonitinho:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

* {margin:0; padding:0;}
body {
font:13px verdana, arial, tahoma;
}

ul { margin:20px 20px 0; list-style:none;}
li {float:left;}
.itens a {
float:left;
border:1px solid black;
background:gray;
padding:5px 15px;
color:#FFF;
text-decoration:none;
}

.itens a:focus {background:red;}

.aba { padding:0 20px;width:400px; clear:both;}
.aba div {
background:white;
border:1px solid black;
padding:10px;
width:100%;
display:none;
}

.aba div:first-child {
display:block;
}

Note que a última linha está dizendo para que os DIVs referentes às tabs fiquem escondidas e que só a primeira apareça.

A coisa toda acontece aqui, com uma linha de código:

1
2
3

.aba div:target {
display:block;
}

Essa linha entende o valor do HREF do link, capturando o ID referente ao div que o browser deve mostrar.

Veja o exemplo completo aqui.

Posts Relacionados

Convertidos do Tableless

Diego Eis — Mon, 21 Mar 2011 04:47:10 +0000

Quem acompanha o Tableless desde o começo conhece a história de como este humilde website nasceu. Eu estudava e aprendia CSS com HTML de uma única maneira: praticando. Eu convertia para tableless a home de alguns grandes sites just for fun. Só para provar que a técnica era real, possível e muito melhor que tabelas. O Tableless nasceu quando eu decidi compartilhar este material para outros desenvolvedores.

Este material não estava publicado porque uma das empresas que eu utilizei como estudo me mandou uma simpática carta extrajudicial dizendo que eu estava fazendo cópia indevida e todo aquele blá blá blá e que eu devia tirar o materia deles imediatamente do ar… Eles com certeza não eram bem humorados. Com medo de outras empresas fazerem o mesmo, tirei logo todos os exemplos publicados.

Neste fim de semana estava jogando algumas coisas fora e encontrei um CD com alguns documentos destes websites convertidos. Você pode verificar e baixar os arquivos nesta página. Até segunda ordem.

Atenção:

Se você é um troll babaca que vai analisar o código só para criticar como foi feito, entenda que o código mais antigo é de pelo menos uns 6 ou 7 anos atrás… Eu faria tudo diferente.

Se você pertence a alguma empresa listada nos exemplos, tenha em mente que esse material é utilizado apenas para estudo.

Posts Relacionados

PDF – Browsers antigos: guerra contra o terror

Diego Eis — Wed, 09 Mar 2011 14:46:33 +0000

É muito difícil tomar a decisão de não suportar browsers antigos ao produzir um grande site. Sempre há um número que se elevado a milhões de usuários o problema pode se agravar. Para uma grande empresa que tem 8 milhões de clientes, ignorar 1% destes usuários é algo realmente fora de questão. O ponto é que você não precisa ignorar estes valiosos 1%. Mas também não precisa gastar milhões nem perder muito tempo tentando resolver os problemas que estes usuários trazem para a produção. Nossa ideia aqui é dar a melhor experiência que eles podem ter sem prejudicar os outros 99%.  

Com este pensamento, criei um PDF simples, onde cito os principais problemas se prever o desenvolvimento para browsers ou meios de acesso antigos. É um documento onde você poderá imprimir e dar para o seu chefe e integrantes da sua equipe. É uma ferramenta para que você tenha alguma munição para te ajudar a convencer aqueles que tentam insistir no erro de manter uma compatibilidade perfeita entre browsers atuais e browsers de 12 anos.

Baixar o PDF – Guerra contra o Terror

Update A Microsoft anunciou sue a partir de 2012 o IE terá atualização automática nos sistemas Windows XP, Windows Vista e Windows 7. Isso quer dizer que estamos mais perto da salvação.