O Android é o novo sistema operacional para mobiles do Google. Até para um AppleBoy, como eu, o sistema é interessante. Tem a interface bem acabada, app’s amigáveis e etc. Ele faz muito bem o papel dele. O Engine de renderização do browser dele é WebKit. O mesmo engine que o Safari Mobile utiliza. E não estou falando de versões antigas do Webkit como alguns outros celulares utilizam. O Android utiliza as versões mais atuais do Webkit, com suporte extenso a CSS e HTML. Portanto, um site que teoricamente foi feito apenas para iPhone, pode ser visualizado da mesma maneira pelos usuários de Android.

Aí entra outra questão: provavelmente você deve ter pensado que seria apenas fazer um script de detecção de browser, capturando as visitas de Safari Mobile e Android e pronto. É aí que você se engana. Já há vários outros aparelhos que estão utilizando engines parecidas e que podem renderizar sua “versão de iphone”. Exatamente por isso, que você precisa fazer um filtro por características e não por browser. Fazemos isso utilizando Media Queries.

As Media Queries permitem fazer um pequeno filtro, onde definimos as características do dispositivo que acessará a página. Com isso, podemos definir um CSS específico para aquele grupo de dispositivos que se encaixaram no seu filtro. Veja um exemplo abaixo:

1
2

<link rel="stylesheet" href="style.css" type="text/css" media="screen and (min-width:481px)">
<link rel="stylesheet" href="mob.css" type="text/css" media="screen and (max-width:480px)">

A media que fiz é muito simples de ser entendida. A primeira linha engloba dispositivos que tem tela colorida, com uma resolução de largura mínima de 481px, isso inclui seu monitor, notebook e etc. A outra linha engloba dispositivos com uma largura máxima de 480px, ou seja, iPhones, Androids e dispositivos que seguem esse mesmo esquema de resolução e etc.

Dessa forma, você filtra os dispositivos e não os browsers dos aparelhos. Isso previne que algum celular, tão bom quanto o iPhone e o Android fiquem de fora de ter uma boa experiência de uso. Quer fazer um teste interessante? Se você estiver utilizando um browser que aceita media queries, redimensione a janela para uma largura menor que 480px. Você verá o Tableless chaveando os estilos automaticamente. Perceba que alguns elementos são reformatados e outros retirados do layout.

O filtro ainda não está completo porque não estamos contemplando os aparelhos que não aceitam meda queries, mas são mobiles. Para isso, usaríamos os Media Types, com valor de handheld. Embora celulares que aceitem os Media Types não tenham um bom suporte de CSS, podemos fazer pelo menos uma formatação de texto, cor e background. Celulares que utilizam Opera Mini, terão uma ótima experiência.

É sempre aquela mesma velha idéia: dar a melhor experiência para todos os meios de acesso. Sempre.

• Porque é a web que comanda
• Introdução sobre Media Queries
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• O que são Media Types do CSS?

Para fazer sites para os iPhones e Androids da vida, não há segredo, já que eles aceitam tudo e mais um pouco de CSS e HTML. Você consegue ter homogeneidade ao desenvolver. Mesmo assim, para ter certeza, seria interessante você testar o site em um aparelho. Por isso, há simuladores que emulam o ambiente dos aparelhos. É o caso do iPhone e do Android.

Para aprender mais sobre o simulador do Android, visite a página oficial sobre o emulador deles. Assim você aprende como ele funciona, as funções, instalação e etc. O simulador pode ser instalado em Windows, Mac ou Linux.

O simulador para iPhone é só para quem tem Mac. Infelizmente a Apple ainda não liberou o SDK para outros sistemas. Uma pena, porque não só de mac vive o homem, e a maioria dos devs utilizam Windows ou Linux. Mesmo assim, você pode baixá-lo e utilizá-lo para testar qualquer site ou arquivos locais.

O pessoal da Nokia também disponibiliza vários emuladores. Contudo, aconselho que você utilize apenas o browser de S60, que é o melhor deles hoje em dia. Os browsers dos S60 suportam Webkit, mesmo não sendo a versão mais atualizada, é possível fazer muita coisa interessante, entretanto, há haver alguns erros de compatibilidade por conta do engine desatualizado.

• Simulador de Android
• Simulador de iPhone
• Simulador para Nokia

• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Sites para Dispositivos Móveis – Breve introdução
• Browsers dos Dispositivos Móveis
• Sites para Dispositivos Móveis – MediaType

Lembrando que você pode fazer isso facilmente com JQuery.

Suponha que você tenha o código HTML:

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
31
32
33
34
35
36
37

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
 
	<title>Tableless.com.br</title>
</head>
 
<body>
 
<div class="geral">
	<div class="header">
		HEADER
	</div>
	<div class="aside fleft">
		ESQUERDA
	</div>
	<div class="aside fright">
		DIREITA
	</div>
	<div class="content">
		<p>
		Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin augue erat, ullamcorper pulvinar malesuada ultricies, mollis non magna. Curabitur quis nisi ut ligula ultricies gravida. Suspendisse elit justo, vulputate in facilisis sed, tristique id nisi. Maecenas risus quam, suscipit eu vehicula ut, ultricies in neque. Donec gravida tristique turpis ut interdum. Donec lacinia nisi id enim lacinia sit amet facilisis est ullamcorper. Curabitur ipsum libero, sollicitudin nec rhoncus quis, congue non ipsum. Etiam at eros dolor. Mauris non erat vitae leo faucibus fermentum. In consectetur, diam eget faucibus dignissim, urna justo pretium dui, nec eleifend neque velit vitae odio. Nam et tristique turpis. In dictum commodo sem ut dignissim. In convallis quam non tortor posuere sed ornare nulla pulvinar. Suspendisse placerat turpis in tortor rutrum nec mollis nulla posuere. Integer tellus est, rhoncus ut sagittis eget, mattis a velit. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Quisque gravida posuere orci nec ornare. Donec elit nulla, aliquam eget cursus a, commodo sed odio.
		</p>
		<p>
		Duis id metus enim, sed dignissim magna. Quisque dapibus pulvinar diam eget adipiscing. Ut aliquet ipsum quis lorem elementum lacinia. Vestibulum feugiat ultrices orci, vel sollicitudin nibh rutrum eu. In gravida tincidunt ornare. Aenean vestibulum leo eu orci egestas semper. Proin euismod dapibus tempor. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Suspendisse rutrum purus eget lectus ultricies a consectetur ante laoreet. Phasellus ullamcorper gravida risus vitae convallis. Curabitur ante lorem, faucibus in tincidunt quis, ullamcorper at lectus. Fusce fermentum blandit varius. Donec a quam id massa bibendum commodo sit amet vel felis. Sed magna nibh, convallis nec dignissim non, vestibulum adipiscing ipsum. Mauris cursus fringilla tortor eu feugiat. Vivamus vestibulum dapibus justo, porttitor luctus nisi posuere at. Nunc mi elit, suscipit id venenatis at, suscipit nec purus. Donec malesuada fringilla tempor. Pellentesque vehicula diam a magna commodo sagittis. Nulla facilisi. 
		</p>
	</div>
	<div class="footer">
		FOOTER
	</div>
</div>
 
</body>
</html>

E o seguinte CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

*  {
	margin:0;
	padding:0;
}
 
html, body {height:100%;}
 
.geral {
	min-height:100%;
	position:relative;
	width:800px;
}
 
.footer {
	position:absolute;
	bottom:0;
	width:100%;
}
 
.content {overflow:hidden;}
.aside {width:200px;}
.fleft {float:left;}
.fright {float:right;}

Na linha 6, você faz com que as tags body e html tenham 100% de altura. Isso fará com que o rodapé entenda que o limite dos dois elementos seja o final da janela do navegador.

Na linha 8, defino que a largura mínima do div GERAL, que é o div que envolve todo o site, seja de 100%. E defino um position: relative; para que o footer seja referenciado por ele.

Na linha 14, eu defino um position: absolute; e bottom:0; para footer, forçando sempre para o final do div.
Se houver pouco conteúdo o Rodapé fica lá embaixo, se houver muito, o rodapé desce junto com o conteúdo.

Funciona em IE7+ e em bons browsers.

Link para o arquivo de exemplo: Footer fixo no Rodapé

• Tutorial Tableless Básico
• Introdução ao CSS Animation
• Formulário Básico em 8 minutos – Tableless form
• Image-Replacement x Imagens
• Centralizando um objeto na Horizontal e Vertical com CSS

A utilização de tabelas no desenvolvimento web foi um marco na história. Pode ser estranho falar isso, mas a verdade é que antes das tabelas os sites eram feios. As tabelas possibilitaram a criação de sites com 3 colunas. Você pode estar pensando que isso não é grande coisa. Mas em meados de 1996-97 isso era nirvana do design para web. As tabelas possibilitaram uma nova realidade para os designers. Foi uma mão na roda naquele tempo. Mas o desenvolvimento com tabelas é algo realmente doloroso. Controlar o layout sem influenciar a programação é um trabalho difícil de se fazer, que encarece o serviço.

Um dos principais problemas do desenvolvimento com tabelas é a mistura das camadas. Nós não conseguimos dividir o desenvolvimento em camadas. As três principais camadas, que você já deve conhecer são: informação, formatação e comportamento. 
O HTML é responsável pela camada de informação. É ele que vai definir importâncias e significado para toda a informação que consta no site. Essa camada é especialmente importante. Os buscadores e os leitores de tela dependem de um HTML bem escrito e semântico para que funcionem plenamente.
O CSS é responsável pela camada de formatação. É ele que vai controlar todo o visual e estruturação do site.
O Javascript e o Ajax controlarão a terceira camada que define qual será o comportamento dos elementos manipulando o código CSS.

A divisão por camadas é a alma do novo desenvolvimento para web. Pouquíssimas pessoas sabem das influências que ela pode trazer, não apenas no código do site, mas também em toda a organização da equipe em empresas. Hoje há especialistas em HTML e CSS, coisa que nunca imaginaríamos no começo da web. Empresas fazem questão de treinar em HTML e CSS, profissionais das suas equipes, que cuidam de Arquitetura de Informação e Usabilidade, mesmo que eles não trabalhem diretamente com o código client-side. Isso faz com que toda a equipe se transforme e saiba das possibilidades e limitações dos projetos.
Durante muito tempo agências web achavam que o desenvolvedor deveria ser uma espécie de canivete suiço. Lembro-me que haviam empresas que procuravam designers que soubessem duas ou três linguagens server-side e programadores que entendessem bem de photoshop, fireworks e illustrator. Pague o salário de um e leve dois. Contudo, também haviam profissionais que achavam que ele deveria ter exatamente este perfil. Talvez por pressão do mercado ou até mesmo porque ninguém entendia direito esse negócio de web.

Quando comecei a ministrar cursos e palestras em empresas sobre este assunto, eu me assustava com a falta de conhecimento e interesse dos profissionais. Eles estavam desenvolvendo a anos utilizando tabelas para a estruturação, sem separar as camadas e fazendo todo o processo de desenvolvimento linearmente. Então chega alguém e diz para eles que está tudo errado e eles precisam reaprender. Eu também ficaria assustado com isso.
Outro ponto ruim era o preconceito com novas idéias. Eu já cheguei a perder uma oportunidade em uma empresa de web porque eu não desenvolvia para Netscape 4 e não fazia sites utilizando o Dreamweaver. O mercado tinha um cenário muito diferente do que temos hoje.
Os novos desenvolvedores nasceram sabendo que estruturação de sites se faz com divs e CSS. E que tabelas servem para exibir dados tabulares. Eles nem imaginam que antes nós quebrávamos nossas cabeças para criar sites arrasadores com uma infinidade de tables, tds, trs, tags fonts e centers. Melhor para eles. Melhor para o mercado.
Dar atenção a um código XHTML bem escrito, com uma bela formatação CSS, significa que o site poderá ser bem acessado por um público ampliado. É abrir portas para deficientes e usuários de diversos dispositivos. É melhorar a indexação em buscadores e facilitar o desenvolvimento de novas versões. É fazer com que a equipe trabalhe independentemente. Isso aumenta as vendas e as possibilidades de novos negócios, idéias, entre outras possibilidades.

Estou feliz porque os browsers também mudaram sua maneira de olhar as coisas. O pessoal que desenvolve o Internet Explorer está com a mente aberta para novidades. A Guerra dos Browsers ainda não acabou, e provavelmente está longe de acabar. Acontece que a Guerra de hoje é mais saudável. Todos ganham. Principalmene usuário final e desenvolvedores. Os fabricantes de browsers descobriram que há caminhos mais inteligentes de conquistar os usuários.

Não sei se estou conseguindo fazer-me entender. Mas quero que você olhe com outros olhos o código HTML, CSS, Javascript, Microformats e qualquer outra linguagem que trabalhe no cliente.
Os padrões web não estariam tão em foco hoje se essa importância não fosse tão explicita.

O que me empolga mais é que daqui pra frente o mercado de desenvolvimento para web tende a ficar mais interessante. Idéias de novos meios de acessar a web estão surgindo todos os dias. Não demorará muito para acessarmos a internet de outros dispositivos que não sejam smartphones e desktops. A internet está se tornando realmente popular agora. Mais empresas descobriram que a internet é algo que pode trazer lucro e abrir novas oportunidades. Uma pena que elas tenham aberto os olhos apenas em tempos de crise. Mas isso é uma outra história.

Este artigo foi originalmente publicado na Revista TIDigital do Mês de Abril de 2009

• Client-side e sua importância
• Processos e Adoção de Padrões
• Produtividade: editores e snippets
• Porque é a web que comanda
• Versionamento inteligente para mobiles

Em primeiro lugar, é importante distinguir o ideal daquilo que é possível fazer. Li um bocado sobre RDF e ontologias há uns dez anos. Li “A Revolução Inacabada”, vi o RSS nascer e se tornar popular, vi as primeiras aplicações entenderem o formato. RDF falhou. Dez anos se passaram e continuamos escrevendo HTML para ser lido por navegadores e só. Há poucos exemplos de aplicações semânticas na vida real, e a maioria seria desenvolvida de uma forma ou de outra.

Há muita gente, por exemplo, definindo seu próprio padrão de XML para trocar dados com sistemas parceiros. Quantos desses estão usando RDF, com uma ontologia interpretada automaticamente por sistemas que “descobrem” os serviços um do outro? Ou seja, não há novidades nisso nos últimos dez anos.

Escrever HTML bom é importante, porque vai ajudar o Google a indexar seu site e vai facilitar a vida de quem tentar HTML parsing nele. Mas, seja sincero, você tem mesmo esperanças de que alguém vá lê-lo como XML? Vê alguma vantagem real em validar seu código como XHTML, além de provar a si próprio que fez tudo direito? E onde está a promessa dos microformats? Microformats só fazem diferença se forem usados por muita gente. Ninguém vai fazer um parser de um formato usado em apenas um site. Você consegue citar, de cabeça, cinco sites que usem microformats e não foram feitos por você? Ah, claro, não vale incluir na lista o microformats.org.

Nem RSS é um bom exemplo de aplicação de semântica XML. Existem pelo menos dois formatos populares do padrão, além do padrão Atom, que serve para a mesma coisa. E não sei de nenhum leitor de RSS de sucesso que faça parsing dos feeds como XML. O que todos fazem é ler e interpretar a string. É isso mesmo que você entendeu, quase tão bom quanto um CSV! Outro exemplo digno de nota é o SOAP, que foi criado para fornecer aos webservices a capacidade de “autodescoberta”. Você conhece alguém que use isso de verdade? Já viu algum robô que varre a web em busca de serviços e entende sozinho como usá-los? SOAP só tem a vantagem de oferecer tooltips para ajudar os programadores .Net que usam Visual Studio. Enquanto isso, lá fora, XMLRPC e REST (com JSON) estão mudando o mundo.

Por que essas tecnologias falharam, embora pareçam todas boas idéias? Meu palpite é que elas exigiam um raciocínio de longo prazo, um tipo de aposta, que é muito difícil de conseguir. Embora XHTML, Microformats ou SOAP sejam idéias muito boas, aplicá-las em seu site só vai ter valor se muito mais gente o fizer. Se você aplicar o formato sozinho vai perder seu tempo.

O que é muito diferente de, por exemplo, deixar de usar tabelas para layout, escrever bom HTML ou usar jQuery. Essas coisas lhe devolvem um benefício imediato. Se deixar de usar tabelas para layout vai ter um site mais leve e vai perder muito menos tempo quando tiver que mudar o layout, se escrever HTML bom vai ter menos trabalho para escrever CSS, para fazer o CSS mobile e o de impressão, e se usar jQuery vai escrever javascript em um terço do tempo.

Note que esses três exemplos também tiram benefícios do fato de muita gente estar usando. Há muitos bons lugares para se aprender HTML e CSS, há muitos sistemas Open Source que já trabalham gerando código bom e os buscadores entendem a semântica do bom HTML. Mas você não depende desses benefícios para tomar a decisão de uso. Quando começamos, há dez anos, a fazer layouts tableless, não aparecíamos melhor no Google e praticamente não havia sistemas gerando HTML direito. Mas o fizemos assim mesmo porque os benefícios imediatos compensavam o esforço.

É por isso que eu temo que nunca teremos uma web semântica de verdade, e estamos condenados a fazer HTML parsing para sempre.

Há exceções. RSS, por exemplo. RSS é uma sombra do que poderia, mas é um padrão de sucesso, amplamente adotado. E não pode ser explicado com minha teoria do benefício individual imediato. Se você estiver usando RSS sozinho no mundo, não terá nenhum benefício. Talvez o sucesso do RSS se deva ao fato de precisar de uma pequena rede de usuários para oferecer um grande benefício.

Você já se perguntou como foram vendidos os primeiros aparelhos de FAX? Ter um FAX só faz sentido se mais gente tiver. Foram vendidos aos pares. As empresas o compravam para trocar documentos entre a matriz e as filiais. O fato de poder trocar documentos com o resto do mundo era, no início, um “benefício adicional”. Se você precisa trocar conteúdo com um site parceiro e vocês forem os únicos usuários de RSS no mundo, terá valido a pena. Conforme a comunidade de usuários aumentava, o valor de ter RSS crescia. Muita gente começou a usar Bloglines e todo mundo queria entrar na festa.

Há alguns anos eu percorri o país com o pessoal da Locaweb comparando o modelo de adoção do RSS com o que eu imaginava que seriam os microformats. Eu estava errado. Pense um segundo no formato de reviews dos microformats. Qual o real benefício de usá-lo? Há alguma aplicação indispensável, onde você realmente quer estar, baseada em hReview? Para que você vai perder seu tempo?

Será que não estamos resolvendo o problema errado? Quando o Diego diz que bordas arredondadas são mais importantes que RDF, será que ele não tem razão? Para meus clientes, hoje, bordas arredondadas com CSS significam um site mais rápido, mais barato (menos tempo gasto recortando imagens) e, para os sites muito visitados, economia de banda. É uma diferença pequena, mas é uma vantagem. E RDF? Além de oferecer RSS, que nem vai ser lido como XML, o que eu posso fazer de real hoje com RDF para meus clientes?

Desculpe se meu raciocínio parece mesquinho. Ele é. Estou tentando ser realista. Uma das principais influências sobre as decisões humanas é a inércia, e não acredito que o mundo vá, num futuro próximo, adotar de maneira revolucionária o RDF ou mesmo o XHTML. Ainda acho essas idéias fantásticas, só não sei se são possíveis.

O realismo também me faz crer que a nova estratégia de especificações modulares do W3C é uma coisa boa. Sofremos décadas com implementações parciais do HTML 4 e do CSS 2. Agora vamos assumir a realidade inevitável. Os desenvolvedores de navegador se sentirão mais à vontade para dizer a você o que funciona ou não. E não precisamos esperar anos para a definição de um padrão. Podemos usar os recursos com os quais o consórcio já concordou hoje. Leva mesmo alguns anos para o W3C bater o martelo sobre determinado padrão, e as especificações modulares representam um ciclo de releases muito mais dinâmico.

Já temos um acordo sobre CSS Transform, bordas arredondadas, múltiplos backgrounds, repetição no DOM, validadores de formulários, SVG, DOM Storage, querySelectors e uma série de outros recursos legais. Por que esperar até a próxima Olimpíada para dizer aos desenvolvedores de browsers: “Ok, pessoal, fechamos tudo, HTML 5 e CSS 3 já são padrões, podem implementar”? De qualquer maneira, a adoção modular das especificações do W3C é inevitável. Embora a especificação tenha saído inteira, a adoção foi modular no HTML 3, no HTML 4, no CSS 2. Sabendo que não vai ser diferente mesmo, não é melhor que tenhamos bonitas tabelas de compatibilidade entre o que existe e o que cada navegador suporta?

Dá uma olhada na lista de módulos do CSS3. Você não quer esperar isso tudo ficar pronto para ter bordas arredondadas.

• O Caminho Suave para o Tableless
• O que é Tableless?
• Sobre Internet Explorer para Mobile – Breve impressão
• Não “otimize” seu código
• O que são Media Types do CSS?

Um dos objetivos do W3C – se não o maior objetivo – é organizar toda a informação da internet. Para fazer isso, precisamos identificar toda essa informação de forma que a extração não seja complexa, pelo contrário, de maneira que a toda a informação que precisarmos possa ser extraída rapidamente, fácil e de qualquer tipo de dispositivo ou aplicação. Por isso, o W3C perdeu muito tempo criando padrões como RDF, por exemplo. Não desmerecendo essas tecnologias, que aliás são bem úteis para nos hoje. Mas cá entre nós, fazer bordas arredondadas para mim, hoje, é mais importante do que algumas necessidades de semântica.
Alguns dos desenvolvedores, a grande maioria gringos, também tinham essa visão. A necessidade de grande parte dos desenvolvedores eram ter coisas simples como suporte a PNG, bordas arredondadas, resize de imagem no background, colocar várias imagens de backgrounds em um elemento, css animation, e assim por diante. Por isso, muitos desenvolvedores começaram reinvidicar uma alteração de prioridades. O HTML 5 surgiu daí. Muitos se enganam se acham que o HTML 5 foi idéia original do W3C. Ele surgiu de um grupo de inconformados de o HTML não ter a pelo menos 10 anos, uma nova atualização. Então começaram a estudar e a escrever um novo padrão para a linguagem. Isso surgiu de uma união de desenvolvedores da Apple (Safari/Webkit), Mozilla e Opera. Muitos se enganam também, se acham que só o W3C pode criar padrões. Você pode criar um. Se vai haver suporte da comunidade, do W3C e dos fabricantes de browsers, é outra história. Mas você tem todo o direito de criar.

O grupo do HTML 5, queria mudar. Eles estavam cansados de usar uma tecnologia antiga e começaram a fazer o trabalho que se esperava que o W3C fizesse. Por fim, essa iniciativa ganhou tanta popularidade e ajuda de outros desenvolvedores, que o W3C resolveu abraçar a idéia e hoje ele cuida desse padrão.
O CSS3 também começou a aparecer por que o W3C abriu os olhos e resolveu começar a revolucionar a linguagem.

O W3C mudou. Os times que cuidam dessas linguagens foram divididas. Modularizadas. Deixe-me explicar. O CSS3 não será mais lançado de uma vez, mas em módulos. Há um time que cuidará da propriedade background. Outra que cuida da propriedade position, outra que cuida da propriedade border, e assim por diante. Isso possibilita que cada módulo, cada propriedade, cada parte do CSS seja lançado independentemente, acelerando o processo de suporte dos browsers e utilização pelos desenvolvedores. Logo, não há mais aquela história de “Browser tal não suporte CSS3”. Mentira, ele suporta, mas algumas das funcionalidades. A mesma coisa acontece com o HTML5. Dizem que o IE8 não suporta HTML 5, mas é mentira. Ele suporta partes do HTML 5. Já há vários módulos implementados no IE8, que fazem parte da especificação do HTML 5. Isso também acontece com os outros browsers.

A web vai ficar mais dinâmica agora. O CSS 3 e o HTML 5 vieram para separar o joio do trigo. Os designers não vão mais ficar pintando quadradinhos como antes. O CSS está virando uma linguagem visual de verdade. Há, por exemplo, working drafts de suporte a variáveis no CSS. E isto é só o começo.
A mesma coisa para o HTML 5. A mudança das tags estruturais do HTML é apenas a ponta das novas possibilidades. Para o pessoal que achava que o HTML é coisa de criança, se prepare, porque o buraco, agora, é mais embaixo.

• Processos e Adoção de Padrões
• Ah, o maravilhoso mundo real
• Lançado Firefox 3.5
• Graceful degradation é tudo sobre Acessibilidade
• Porque só para o iPhone?

Existem algumas propriedades do CSS que quando aplicadas aos “elementos pais”, os “elementos filhos” herdam a característica aplicada no pai. Um exemplo disso é a propriedade color. Quando aplicamos a propriedade color em um elemento div, o texto dos elementos contidos no div são coloridos de acordo com a propriedade.

1
2
3

div {
   color: green;
}

O texto que há dentro deste div irá ter a cor verde, independente se este texto está “solto” dentro do div ou se ele está dentro de um parágrafo, por exemplo. Ou seja, os filhos herdaram o resultado desta propriedade. A mesma coisa acontece para, por exemplo, a propriedade font-size.

Há também as propriedades não herdadas pelos “filhos”. Estas propriedades geralmente são propriedades referentes a formatação da caixa, como por exemplo a propriedade width, height, margin, padding e assim por diante.

Essa herança é responsável por uma parte da cascata. É aí que está uma das primeiras vantanges de se utilizar o CSS no desenvolvimento com padrões. A vantagem da herança é exatamente podermos modificar poucas linhas do CSS para fazer alterações no site inteiro, sem ter que caçar elemento por elemento e modificando suas propriedades.

A herança é largamente utilizada em frameworks de CSS ou até mesmo em técnicas para que a customização de layouts seja explorada de forma automática ou manual pelo cliente, como homes de portais, e-commerce etc. Assim, o controle fica mais genérico, e é aí que entra a especificidade do CSS para controlar o detalhe.

O valor INHERIT

O valor inherit é utilizada em propriedades destinadas aos elementos filhos. Suponha que você tem um elemento div. Este elemento div tem uma borda e você quer que seus filhos tenham a mesma borda. Veja o código:

1
2
3
4

<div id="pai">
  <div>um filho</div>
  <div>outro filho</div>
</div>

No CSS, o normal seria fazer isso:

1
2
3
4
5
6
7

div#pai {
  border: 2px solid black;
}
 
div#pai div {
  border: 2px solid black;
}

Se você quisesse modificar a borda do pai e mesmo assim manter a borda do filho, teria que fazer das alterações no código. O valor inherit serve para que o filho sempre herde um determinado valor de uma determinada propriedade do pai. Quando o valor do pai muda, o valor do filho também. Veja o código e o exemplo.

1
2
3
4
5
6
7

div#pai {
  border: 2px solid black;
}
 
div#pai div {
  border: inherit;
}

Especificidade

A especificidade define os detalhes. Quando você define no body as propriedades font-family, font-size, essas propriedades são herdadas por toda árvore de elementos do documento. Isso tráz uma uniformidade para o texto, mas nem todos os elementos terão esse valor genérico de font, logo você terá que ser mais específico e definir valores diferentes de font para estes elementos. É aí que a mágica acontece.

Suponha que você tenha o seguinte código:

1
2
3
4
5
6
7
8

<div class="content">
   <p>
        Vivamus in leo lacus. <em>Nam condimentum viverra odio</em>, non molestie orci commodo sit amet. <strong><em>Proin aliquet leo eu</em></strong> ipsum adipiscing tristique vestibulum nunc gravida. In porta dignissim enim sit amet vulputate. Quisque lacinia malesuada convallis. Sed sit amet orci non lacus sollicitudin pellentesque. 
   </p>
</div>
   <p>
        Vivamus in leo lacus. <em>Nam condimentum viverra odio</em>, non molestie orci commodo sit amet. <strong><em>Proin aliquet leo eu</em></strong> ipsum adipiscing tristique vestibulum nunc gravida. In porta dignissim enim sit amet vulputate. Quisque lacinia malesuada convallis. Sed sit amet orci non lacus sollicitudin pellentesque. 
   </p>

E também o código CSS:

1
2
3

em {
   background: red;
}

Definimos no código acima que os elementos em terão o background vermelho. Isso irá capturar os 4 elementos em que colocamos no HTML. Correto? Ótimo. Estamos sendo bem genéricos aqui. Ele irá capturar todos os elementos em, não importa onde ele esteja. Vamos analisar outro código CSS:

1
2
3
4
5
6
7

em {
   background: red;
}
 
div p em {
   background: green;
}

Já mudamos toda a história com este seletor. Queremos dizer que apenas os em que estão dentro de p e que por sua vez estão dentro de um div terão o background verde. Deixamos a regra mais específica excluindo todos os elementos em que estão fora do div. Os em que estão fora do div continuam com o background vermelho.

No caso acima, a ordem não altera o resultado da renderização. O seletor mais específico sempre é o que vai funcionar.

Essa explicação é bem básica. Contudo, entendendo como ela funciona, você sabe o que acontece com seletores mais complexos.

O valor !important

A especificidade apresenta muitos problemas quando a equipe é grande e o código CSS está gigante. Você tenta fazer uma alteração em um determinado objeto, e nada funciona. Isso acontece porque alguém já definiu um seletor mais específico que o seu e definiu um valor diferente para sua propriedade, e isso te impede de fazer a alteração que precisa. Essa seria uma cena clássica, mas há outros cenários cujo o uso do valor !important.
O !important indica que aquela propriedade sempre será a principal, e que nunca será substituída mesmo que o seletor seja mais complexo. Veja:

1
2
3
4
5
6
7

p {
   color: black;
}
 
div p {
   color: red;
}

No código acima, o parágrafo terá a cor vermelha por conta do seletor div p ser mais específico.

1
2
3
4
5
6
7

p {
   color: black !important;
}
 
div p {
   color: red;
}

Agora, mesmo o seletor div p sendo mais específico, ele não controlará o elemento. O !important está jogando toda a relevancia para o color: black;.
Use com cuidado. Se você colocar muitos !important no seu código, a utilidade deste valor se perderá. Veja o exemplo.

• nth-child
• CSS 3 Columns
• Produtividade: editores e snippets
• Colocar Rodapé fixo no fim da página
• Digest – Referências de CSS

• Efeito cascata, herança e especificidade do CSS
• nth-child
• CSS 3 Columns
• Introdução ao CSS Animation
• Vídeo: Menu horizontal com CSS em 5 minutos

Você já precisou de criar uma tabela zebrada? Eu já, muitas vezes. Provavelmente se você não sabe programar, você precisa chamar um programador para escrever duas ou três linhas de código Javascript ou até mesmo usando JQuery, para fazer a mágica para você. A idéia do CSS, é que nós, designers, possamos controlar a aparência dos elementos HTML. Isso inclui conseguirmos fazer uma maldita tabela zebrada também. Para isso e para outros problemas parecidos, podemos utilizar a pseudo-classe nth-child. Com esta pseudo-classe é possível selecionar um determinado elemento dentro de uma árvore de elementos. Por exemplo, podemos selecionar todas as linhas ímpares das tabela. Legal, hein?

Cálculo básico

O cálculo utilizado pelo nth-child é bastante simples. Você vai usar na maioria das vezes soma. Lembra? A fómula será a seguinte: an+b.

1
2
3

table tbody tr:nth-child(2n+1) {
  background:lightgray;
}

O funcionamento é o seguinte: o browser aplica o estilo a cada 2 tr.
O código abaixo, aplica o estilo a cada 3 tr. E assim por diante.

1
2
3

table tbody tr:nth-child(3n+1) {
  background:lightgray;
}

Você pode facilitar, utilizando as palavras odd ou even, para selecionar os elementos ímpares ou pares da árvore.

1
2
3

table tbody tr:nth-child(odd) {
  background:lightgray;
}

Caso você queira pegar 9º, 19º, 29º e assim por diante:

1
2
3

table tbody tr:nth-child(10n-1) {
  background:lightgray;
}

Se o valor de a (an+b) é igual 0, você não precisa colocar a fórmula, apenas o número referente a ordem do elemento. Exemplo:

1
2
3

table tbody tr:nth-child(1) {
  background:lightgray;
}

Neste código, o browser iá colorir o background apenas do primeiro tr.

Veja o exemplo.

A propriedade nth-child faz parte dos seletores do CSS 3 e já pode ser utilizado em browsers atuais.

Se você ainda não leu sobre seletores do CSS, leia estes artigos abaixo:

• Seletores encadeados e agrupados
• Seletores do CSS – Pseudo-classes
• Seletores Complexos do CSS

• CSS 3 Columns
• Efeito cascata, herança e especificidade do CSS
• Introdução sobre Media Queries
• Colocar Rodapé fixo no fim da página
• Digest – Referências de CSS

column-count

A propriedade column-count define a quantidade de colunas terá o bloco de textos.

1
2
3

 /* Define a quantidade de colunas, a largura é definida uniformimente. */
-moz-column-count: 2;
-webkit-column-count: 2;

column-width

Com a propriedade column-width definimos a largura destas colunas.

1
2
3

/* Define qual a largura mínima para as colunas. Se as colunas forem expremidas, fazendo com que a largura delas fique menor que este valor, elas se transformam em 1 coluna automaticamente */
-moz-column-width: 400px; 
-webkit-column-width: 400px;

Fiz alguns testes aqui e há uma diferença entre o Firefox 3.5 e o Safari 4 (Public Beta).
O column-width define a largura mínima das colunas. Na documentação do W3C é a seguinte: imagine que você tenha uma área disponível para as colunas de 100px. Ou seja, você tem um div com 100px de largura (width). E você define que as larguras destas colunas (column-width) sejam de 45px. Logo, haverá 10px de sobra, e as colunas irão automaticamente ter 50px de largura, preenchendo este espaço disponível. É esse o comportamento que o Firefox adota.

Já no Safari, acontece o seguinte: se você define um column-width, as colunas obedecem esse valor e não preenchem o espaço disponível, como acontece na explicação do W3C e como acontece também no Firefox. Dessa forma faz mais sentido para mim.

Como a propriedade não está 100% aprovada ainda, há tempo para que isso seja modificado novamente. Talvez a mudança da nomenclatura da classe para column-min-width ou algo parecida venha a calhar, assim, ficamos com os dois resultados citados, que são bem úteis para nós de qualquer maneira.

column-gap

A propriedade column-gap cria um espaço entre as colunas, um gap.

1
2
3

 /* Define o espaço entre as colunas. */
-moz-column-gap: 50px;
-webkit-column-gap: 50px;

Veja um exemplo destas propriedades aqui..

Utilizamos aqui os prefixos -moz- e -webkit-, estas propriedades não funcionam oficialmente em nenhum browser. Mas já podem ser usados em browsers como Firefox e Safari. Fique à vontade para testar e comentar aqui os resultados!

• nth-child
• Efeito cascata, herança e especificidade do CSS
• Introdução sobre Media Queries
• Image-Replacement x Imagens
• O que são Media Types do CSS?