A guerra entre os Padrões Web e tecnologias como o Flash começou de verdade.
Desde o momento que as possibilidades do HTML5 e CSS3 foram publicadas, um pequeno burburinho entre os desenvolvedores sobre uma possível concorrência entre os Padrões e tecnologias como o Flash começou a rolar. Alguns desenvolvedores descrentes começaram a acreditar no poder das novas tecnologias para desenvolvimento web e novamente o HTML e o CSS tiveram a grande atenção de empresas e desenvolvedores.

Mesmo assim existem pontos que precisam ser esclarecidos. Muitos estão fazendo uma confusão com significados, objetivos e as reais soluções que essas novas tecnologias proporcionam:

1. O HTML5 sozinho não faz nada além de dar significado à informação. Com ele, o CSS 3 e o Javascript completam o pacote para que todas essas mudanças que andamos lendo faça sentido de verdade. Mesmo com a midia fazendo um alarde muito grande em cima do HTML 5, uma boa parte das mágicas deve-se ao poder do CSS 3.
   Contudo o HTML5 está sendo totalmente reformulado para que haja mais integração entre o trio HTML, CSS e Javascript.
2. Os browsers são independentes, mas trabalham todos juntos em pról dos Padrões Web. Embora cada um deles tenham interesses financeiros óbvios, todos eles sabem que a única maneira de estar à frente do concorrente é andar lado à lado com os Padrões. O que basicamente diferencia um browser do outro são os serviços agregados, velocidade e facilidade de uso. Dificilmente um browser ganhará mercado se ele for super ultra compatível com os padrões. A não ser que a massa de usuários saiba o que isso signifiqueo ou que haja uma campanha muito forte, partindos dos desenvolvedores e empresas interessadas para evangelizar e educar os usuários finais.
3. Se você não começar a forçar o desenvolvimento da sua empresa para que os projetos sejam desenvolvidos focando browsers atuais, pra ficar para obsoleto. Daqui pra frente o mercado vai ficar cada vez mais dinâmico. Conforme os browsers vão se atualizando e o W3C libera novos padrões, você, seu cliente e seu projeto podem ficar para atrás. Por isso é interessante haver principios de Graceful Degradation nos projetos para que usuários de browsers mais atuais se beneficiem de um visual mais bem acabado, velocidade de carregamento da página e tecnologia atual. Entenda que eu não estou dizendo para criar projetos para um browser específico, mas limitar características visuais e funcionais de browsers mais antigos.

O HTML foi criado por uma necessidade de compartilhar, interligar e portar informação. Logo, o HTML precisa ser uma linguagem que possa ser lida pr qualquer meio de acesso.

O HTML 5 modifica a forma com que damos significado para a informação na web. Você está acostumado a escrever código para criar elementos que são renderizados pelo browser e lidos por diversos meios de acesso. Estes elementos tem seus respectivos significados. Para manipular estes elementos, você utiliza Javascript para controlar o CSS que formata as características deste objeto. Por mais que bibliotecas como JQuery sejam ótimas, a maneira que manipulamos o comportamento dos elementos não é a melhor. Existem diversas necessidades que não são resolvidas de uma maneira fácil ou que simplesmente não há solução. Além do HTML 5 renovar a forma com que atribuímos significado, ele nos dá ferramentas para facilitar a manipulação dos elementos.

Alguns desenvolvedores não entenderam as verdadeiras mudanças do HTML 5 e suas reais implicações sobre o desenvolvimento client-side. Saiba que o HTML 5 veio para estreitar as ligações entre o HTML, o CSS e o Javascript. Todos eles trabalharão mais integrados a partir de agora. Se acostume para ver pencas de código Javascript por aí. Isso é por conta das famosas APIs que o HTML 5 está trazendo.

• Apostila sobre HTML5
• HTML5 Diff
• Conteúdo, Flash e HTML
• Google Apps não suportará mais IE6
• Porque é a web que comanda

@font-face é uma das funcionalidades mais esperadas do CSS. Ela permite que você utilize famílias de fonts em websites sem que o usuário tenha a font instalada no sistema. Veja abaixo a sintaxe:

1
2
3
4

@font-face {
     font-family: helveticaneue;
     src: url('HelveticaNeueLTStd-UltLt.otf');
}

Na primeira linha você dá um nome para a Font que você está importando. Pode ser qualquer nome.
Na segunda linha, você inclue o endereço de onde a font se encontra. Para facilitar, crie uma pasta font dentro da pasta onde está o CSS.

Feito isso, você a utiliza como qualquer outra font:

1
2
3

p {
	font:36px helveticaneue, Arial, Tahoma, Sans-serif;
}

Fiz alguns testes aqui e em algumas máquinas e conexões lerdas, o browser carrega primeiramente o texto com a font padrão do sistema e logo depois monta o texto com as fonts corretas. Nada de outro mundo para quem utiliza imagens para substituir textos. Mesmo assim, pode ser um incomodo para alguns.

Suponhamos que você queira oferecer a font para os que não a tem disponivel no sistema, mas para que o site carregue mais rápido, queira utilizar a cópia local do sistema do usuário caso ele a tenha instalado:

1
2
3
4

@font-face {
     font-family: helveticaneue;
     src: local(HelveticaNeueLTStd-UltLt.otf), url(HelveticaNeueLTStd-UltLt.otf);
}

O valor local() faz com que o browser procure a font no computador do visitante antes de executar o download da font que está no servidor.

Abaixo segue uma série de formatos que podem ser usados e que os browsers podem adotar:

Compatibilidade

A compatibilidade é melhor do que você pode imaginar. Mesmo assim há alguns entraves que chateiam. Entretando, se você pratica Gracefull Degradation, vai achar uma maravilha.

As versões 7, 8 e 9 do Internet Explorer aceitam o @font-face apenas se a font for EOT.
Safari, Firefox, Chrome e Opera aceitam fonts em TTF e OTF.
Você pode converter suas fonts para EOT diretamente no Font Squirrel.

É sempre bom você não abusar. Uma porque o design não fica bonito se você utilizar muitas fonts diferentes. Outra que o site pode ficar carregado. Lembre-se que o browser carrega o arquivo da font para só assim aplicar no layout.

Veja um exemplo pronto.

Fonts pagas

O principal problema com o @font-face o download de font ilegal. Há uma pancada de fonts que são grátis, estas não há problema. Mas há uma outra grande parte que são pagas. O problema é que você tem a licensa de utilizar essa font nos seus projetos, mas não tem o direito de compartilhá-la ou dar para alguém. Quando você utiliza @font-face, você praticamente disponibiliza para o mundo o arquivo da font. Qualquer um pode fazer o download sem problemas. Por isso, cuidado com a font que você utiliza. Certifique-se de que ela é uma font gratuita.

Leia mais direto da fonte.lan

• Conteúdo, Flash e HTML
• Colocar Rodapé fixo no fim da página
• Ah, o maravilhoso mundo real
• Propriedade do CSS: nth-child
• CSS 3 Columns

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.

• Propriedade do CSS: 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
• Propriedade do CSS: nth-child
• CSS 3 Columns
• Introdução ao CSS Animation
• Vídeo: Menu horizontal com CSS em 5 minutos