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
• Ah, o maravilhoso mundo real
• Prepare-se para a Revolução
• CSS 3 Columns
• Lançado Firefox 3.5

Graceful Degradation e Progressive Enhanced

Procurar querer dar uma boa experiência para todos os dispositivos utilizados pode se tornar um problema, já que a variação de aparelhos e hardware é muito maior quando comparado com o mundo dos desktops.
Sabemos que, para um site normal, é seguro ter uma largura de 990px. Sabemos que com essa largura, o site vai ficar bem diagramado em diversas resoluções, começando em 1024.
Mas nos aparelhos móveis não temos essa métrica. A variação dos tamanhos das telas é muito maior. Os aparelhos e a forma de uso de cada um são muito diferentes.

Eu não gosto de nivelar os sites por baixo. Pelo menos não hoje. Há muitas possibilidades de fazermos um bom trabalho de user experience, mas não o fazemos, porque há alguns perfis de usuário, que infelizmente temos que prever no escopo. Por isso sou a favor do Graceful Degradation e do Progressive Enhanced.

Fornecer a melhor experiência possível para todas as camadas de usuários. Esse é o alvo para a utilização do Graceful Degradation e do Progressive Enhanced. 
Se nivelarmos o visual e as funcionalidades do site/sistema por baixo, iremos prejudicar demais os usuário “de alto escalão”. Para entender melhor, imagine um usuário de Safari Mobile acessando um site customizado para Internet Explorer Mobile.

Versionamento Especifico

Já é prática antiga criar versões dos sites para um sistema, aplicação ou dispositivo específico. Fazíamos isso na guerra dos browsers e fazemos isso hoje para alguns browsers antigos. Versionar um site é uma das saídas mais simples para resolver um grande problema. Como a quantidade de dispositivos de acesso está crescendo, a necessidade de haver uma versão do site para estes dispositivos é mais que normal. O HTML é uma linguagem feita para que seja acessada por diversos meios. Hoje, os meios de acesso são bem escassos, consigo pensar apenas em Desktops e Aparelhos de mão (celulares e smartphones). Você consegue pensar em mais alguns outros?
Embora não sejam maioria, os consoles estão aumentando sua presença online. Aparelhos como XBOX e Playstation estão se tornando cada vez menos restritos para jogos, e estão indo muito além do que poderíamos imaginar um dia. O XBOX já anunciou sua integração com Facebook e Twitter. Embora este tipo de acesso seja ainda muito limitado e controlado pelas fabricantes dos consoles, imagine, como seria a experiência de acessar a internet que temos hoje por um Playstation ou XBOX. Eu acharia sem graça. É uma interface totalmente diferente da comum. Mesmo se tentássemos levar a mesma experiência atual com os desktops para estes dispositivos, na minha opinião, estaríamos subutilizando-os.
A mesma coisa pode acontecer com aparelhos como o Surface da Microsft. Eu não imagino um usuário abrindo um navegador como o Firefox, IE ou Opera no Surface e utilizando-o para navegar na internet como fazemos hoje. Não encaixa. É algo diferente, mais interativo, divertido. E atenção aqui: quando digo interativo, não estou querendo dizer que tudo deverá ser feito com Silverlight ou Flash, pelo contrário. O HTML 5 e o CSS 3 estão vindo para acabar com esse mito.

Também não estou dizendo que talvez você fará uma versão dos seus sites para cada novo dispositivo que aparecer. Pelo contrário. Estou dizendo que eles serão necessários de acordo com o público de cada site, e de cada negócio.

Até hoje os desenvolvedores e também os donos de sites, tem uma dificuldade muito grande em criar ou decidir se é útil ou não desenvolver uma versão dos sites para mobiles. Imagine quando a cartilha de meios de acesso aumentar.

A Globo.com e também outros grandes sites enfrentam o mesmo problema: decidir quem vai e quem fica. Decidir qual aparelho será priorizado e qual receberá apenas uma versão de texto.
Claro que com o tempo, as limitações de cada aparelho serão mínimas e as características de cada um serão bem parecidas. Isso diminuiria muito o trabalho de desenvolvimento e aumentaríamos a quantidade de acesso, pelo simples fato de que estaríamos dando quase que a mesma experiência para uma quantidade maior de dispositivos.

Outro ponto importante, mas consolador, é que há motores de renderização muito bons hoje em dia. Vide Gecko e Webkit. Ambos de código livre e que recebem sugestões e modificações do mundo inteiro. Por exemplo, os aparelhos da Nokia e também o Chrome utilizam o Webkit como base para seus softwares de acesso. Isso faz com que consigamos manter o controle de nosso desenvolvimento e nos dá uma visão melhor de todo o horizonte de possibilidades.

Você, como desenvolvedor, tem a obrigação de viver um pouco mais além. Não pense que iremos escrever HTML e CSS para todo o sempre. E mesmo que for, serão linguagens totalmente diferentes de como as conhecemos hoje.

Conhecendo os browsers e seus motores

Os browsers estão ainda muito longe de melhorar a forma com que lidamos e navegamos com a web. Nenhum deles trouxe nos últimos anos uma inovação capaz de fazer com que melhoremos nossa experiência online. Eles ainda estão engatinhando muito e parte da culpa não é deles. O W3C se mostrou muito lerdo nos últimos 11 anos. Eles acordaram muito tarde para as reais necessidades dos desenvolvedores. A comunidade por sua vez, sacudiu todo o W3C, tomando a iniciativa e começando um novo evanlegismo em pról do HTML 5 e do CSS 3. Isso fez com que o W3C entendesse melhor o que os desenvolvedores precisavam para que a web inteira fosse privilegiada.
Os browsers por sua vez, aproveitaram toda essa mudança, e começaram uma nova guerra, em silêncio. O suporte aos Padrões dos principais browsers do mercado está invejavelmente avançada. Há browsers como o Internet Explorer que sempre serão atrasados, mas que felizmente estão acordados também para as novas atualizações do mercado.

Mesmo assim, acho que o foco não se deve dar em browsers específicos, acho que nossa atenção deve ser voltada para os Motores de Renderização. Hoje, os principais são:

• Gecko
  Motor com código aberto. É utilizado nas aplicações da Mozilla: SeaMonkey, Camino, Firefox, Thunderbird etc. Gecko é um motor herdado do antigo Netscape, baseado no Mosaic.
Depois da Guerra dos Browsers, a Netscape doou o motor de renderização para a comunidade, que culminou na criação da Mozilla.
  
• Presto
  Motor proprietário da Opera Software. A Opera é uma das empresas que mais inovam no mercado de browsers. Embora eles tenham tecnicamente um dos melhores browsers para desktops, a versão mobile é a mais utilizada. Eles tem duas versões: Opera Mobile, para smartphones e Opera Mini, para celulares mais básicos. A Opera também está muito presentes em outros mercados fora da web.
• Webkit
  Motor com código aberto, é utilizado hoje em aplicações como Safari, Safari Mobile e Chrome, browser do Google.
É o mais novo motor de renderização do mercado. Foi criado pela Apple, baseando-se no motor de renderização KHTML, que estava só presente em browsers para Linux, como o Konqueror. Aproveitando que o KHTML é um sistema OpenSource, a Apple modificou todo o seu código, fazendo melhorias e aperfeiçoando-o para criar seu browser o Safari. 
A Apple fez várias outras modificações posteriores em cima desta primeira versão. Deu o nome de Webkit, e hoje, conduz o desenvolvimento dessa plataforma.
• Trident
  É o motor proprietário da Microsoft. É utilizado em aplicações como Outlook e claro, no Internet Explorer. Eles estão criando um novo motor, que é utilizado no Internet Explorer 8 e posteriores.
Embora o Trident fora o primeiro a suportar completamente a primeira versão do CSS, atualmente ele é o motor de renderização mais atrasado. A Microsoft vem fazendo um bom trabalho para tentar recuperar essa má fama, mas mesmo assim, os outros motores do mercado estão muito além.

Quando conhecemos o motor de renderização dos browsers, e sabemos quais suas limitações, não precisamos nos preocupar com a quantidade de browsers criados. O Google lançou o seu browser chamado Chrome, baseado em Webkit. Embora fosse um novo browser, isso não deveria assustar os desenvolvedores, já que é o mesmo motor utilizado no Safari. Logo, a renderização dos dois é muito parecida. Não é uma preocupação a mais, pelo contrário.
A mesma coisa se aplica aos browsers para mobiles dos sistemas da Nokia e também do iPhone. Ambos utilizam Webkit para renderizar as páginas. Isso dá liberdade para a criação de interfaces mais elaboradas, tornando a experiência de usuário mais interessante em dispositivos móveis.

Já o Internet Explorer, com seu motor de renderização se mostra um inimigo dos desenvolvedores. Embora a Microsoft esteja trabalhando arduamente em um novo código, as versões antigas deste motor ainda assombra a muitos desenvolvedores. E infelizemente, em alguns projetos, precisamos dar um passo para trás por conta da massa de acessos feitos por este motor.
A mesma história se aplica para a versão do Internet Explorer Mobile. O suporte crítico aos Padrões Web faz com que os aparelhos com este sistema se tornem obsoletos quando se trata de experiência online.

Entenda a importância dos motores de renderização. Eles tem um papel fundamental no comportamento do mercado e faz com que avancemos no desenvolvimento web.

No final tudo dá certo. Ou não.

A web está passando por uma transação infinita. A cada dia ela ganha mais foco na mídia, mais atenção das empresas, tanto grandes, quanto pequenas. Sempre que um novo dispositivo é criado, um novo nicho de usuários surge, com novas maneiras e costumes de navegação. É impossível agradar a todos. Por isso é importante estabelecer prioridades. Um bom caminho é ajudar no desenvolvimento e compartilhamento de sistemas que ajudam a web a avançar. “Muda, porque quando a gente muda, o mundo muda com a gente.” Gabriel O Pensador.

• Ah, o maravilhoso mundo real
• Aonde nos leva a morte do Internet Explorer 6?
• Lançado Firefox 3.5
• Graceful degradation é tudo sobre Acessibilidade
• HTML 5 – Mudanças na estrutura e semântica

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
• Implementar XHTML/CSS é grátis

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.

• Ah, o maravilhoso mundo real
• Lançado Firefox 3.5
• Graceful degradation é tudo sobre Acessibilidade
• Porque só para o iPhone?
• Sites para Dispositivos Móveis – MediaType

A 1a. Conferência Web W3C Brasil 2009 será realizada em São Paulo, SP, nos dia 23 e 24 de novembro, no Blue Tree Towers Morumbi no bairro do Brooklin. Acesse os links para obter informações sobre o local, hotéis da região, chamada de trabalhos ou sobre como se inscrever para participar da conferência da web brasileira.

Chamada para trabalhos

Você pode ser um palestrante da 1a. Conferência Web W3C Brasil! Se você tem um caso prático e inovador de uso da web, ou fez uma pesquisa cujos resultados merecem ser compartilhados com toda a comunidade web brasileira, ou ainda tem o “pulo do gato” para ensinar em um tutorial, então atenda a nossa Chamada de ‘Papers’, Casos de uso e Tutoriais.

O Comitê de Programa vai selecionar as submissões mais relevantes para compor a programação da Conferência. Mais detalhes em Chamada de trabalhos.

Entre na comunidade da conferência no Facebook e fique por dentro.

• Prepare-se para a Revolução
• nth-child
• Canivetes na web
• HTML 5 – Semântica e o que é importante na web
• Navegando com a jQuery

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
• Digest – Referências de CSS
• Introdução sobre Media Queries
• Introdução ao CSS Animation

• 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

Mas não é tempo de comemorar, ainda há muito trabalho a fazer. Há oito anos o Zeldman publicou seu célebre artigo To Hell With Bad Browsers, em que nos explicava porque devíamos abandonar o suporte aos navegadores 4.0. O ponto básico era não ter que fazer várias versões do mesmo site. Uma versão apenas, com bom layout CSS, podia funcionar para todo mundo, com todas as vantagens dos padrões web, mas não nos navegadores 4.0.

Bom, fazem oito anos. OITO LONGOS ANOS! Há oito anos que podemos escrever uma versão só de cada site, desde que saibamos escrever hacks de CSS e ajustes de float para o Internet Explorer 6. Há oito anos que estamos repetindo o fato de que o Internet Explorer 6 é a pedra que restou em nosso sapato. Há oito anos que sonhamos em não ter que escrever hacks.

A morte do Internet Explorer 6 significa apenas isso: poder usar PNG transparente e não ter que escrever hacks (ou não ter que escrever tantos hacks.)

A Microsoft passou oito anos sem atualizar seu navegador para nos dar exatamente o que? PNG transparente? Nesse período, Firefox, Opera, Safari e Konqueror estão trabalhando em coisas como controle de opacidade, CSS transform, bordas com imagem, sombras, media queries, colunas e os maravilhosos novos seletores do CSS3. Coisas maravilhosas que você já pode usar, mas a maioria de seus usuários não vai ver porque usa Internet Explorer.

A morte do Internet Explorer 6 nos leva apenas ao lugar onde deveríamos ter chegado há oito anos: sites sem hacks. A Microsoft ainda está algumas gerações atrasadas e, se queremos usar CSS 3 e HTML 5 um dia, é bom parar de comemorar e voltar ao trabalho. Há um mundo para mudar.

• Ah, o maravilhoso mundo real
• Introdução: diversidade dos meios acesso
• Prepare-se para a Revolução
• Lançado Firefox 3.5
• A internet tem que avançar sem o IE6

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
• Digest – Referências de CSS
• Introdução ao CSS Animation

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
• Ah, o maravilhoso mundo real