Definir padrões é normal para que a equipe inteira escreva o código da mesma maneira. Esse assunto é longo e muito importante para todas as equipes de desenvolvimento. Programadores já quiseram me matar várias vezes porque eu uso TABS em vez de ESPAÇOS em arquivos Python/PHP. Programadores gostam de espaços. Eu não. Mas não é o nosso gosto que vai definir quais os padrões de código que devemos seguir.

Quando definimos padrões e boas práticas, garantimos que todos da equipe conseguirão ter o mínimo de entendimento do código daquele projeto que está na empresa a tempos. Se alguém da equipe adoecer ou precisar ir para o Canadá, outro integrante pode assumir o seu lugar sem precisar se preocupar em aprender novas regras, porque elas devem ser as mesmas do projeto anterior.

É importante que os integrantes da equipe sejam sempre fiéis aos acordos firmados no momento em que combinam esses padrões. É importante também que, caso eles encontrem um integrante fora da lei, que eles forcem o meliante a seguir as regras. Já vi gente perdendo o trabalho de uma semana por que estava trabalhando diretamente pelo FTP e o projeto não estava no GIT. O programador simplesmente APAGOU o projeto da pessoa. Nunca mais ela resolveu editar os arquivos fora do controle de versão. Esse tipo de atitude é perigosa mas muito necessárias às vezes. Devemos forçar as regras num ambiente onde todos devem quem, quando e como as linhas de código do projeto foram escritas.

Alguns pontos para se pensar e combinar:

Identação

Como devemos identar o código? Com espaços ou tabs? Se for com espaços quantos?

Espaços em brancos (Whitespaces)

Espaços devem ser incluídos depois de uma operação condicional? Espaços devem ser colocados entre o seletor e as chaves? E no final de cada linha, precisa?

Nomenclatura

Como as classes, ids e variáveis devem ser nomeadas? E as funções? Vamos usar CamelCase?

Comentários

Como faremos com os comentários? Como serão os delimitadores do comentário? O comentário deve ser completo ou precisa ser algo mais resumido?

Arquivos

Como os arquivos, que não fazem parte da estrutura padrão do CMS, Framework e etc deverão ser chamados? E o nome das pastas? Como as páginas serão chamadas?

Chaves e ponto/vírgula

As chaves deverão ser abertas na mesma linha ou devemos quebrar linhas? Vamos sempre usar ponto/vírgula? Vamos usar o padrão K&R ou Allman?

Quando definimos estas pequenas coisas, diminuímos muitos percalços no meio do caminho. Já vi projetos atrasarem meses por que um palerma abriu e salvou arquivos com o charset diferente do que já tinha sido combinado no início.

“It’s more important for people on a team to agree to a single coding style than it is to find the perfect style.” Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications
Indico este livro sobre esse e outros assuntos sobre a construção, desenvolvimento e manutenção de websites

Posts Relacionados

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução das premissas dos controles de versão
• Boas práticas de Acessibilidade
• CSS1K

Mas não se anime muito. Eu sei que você está ansioso para sair por aí colocando efeitos 3D de CSS em tudo quanto é aplicação. Mas calma… entenda que o CSS foi feito para estilizar documentos. Você o utiliza para melhorar a experiência dos usuários nos diversos dispositivos e não para enfeitar seu website como se fosse uma penteadeira. Lembra-se dos websites cheios de gifs animados? Pois é, cuidado para não cair no mesmo erro. Você estará utilizando o CSS 3D da maneira certa se seus efeitos passarem desapercebidos pelo usuário ao utilizar seu sistema. Encher seu sistema com efeitos a cada clique ou a cada ação pode fazer com que o usuário perca tempo e a paciência.

Mas vamos ao que interessa.

O suporte

Infelizmente isso ainda está restrito para browsers. O Internet Explorer não tem suporte ainda e nem tem data para tal. Todos os exercícios que você ver neste post são feitos para browsers que tem WebKit como motor de renderização. Por isso teste em seu Chrome ou no seu Safari. Eu testei no Chrome porque o Safari mostrou algumas inconsistências. O Opera está esperando as especificações de CSS Transforms amadurecerem para adicionar este recurso. Testei no Firefox 8.0.1 e o exercício não funcionou.

A degradação do CSS 3D para os browsers que não o suportam é um pouco infeliz. Sugiro que se você for utilizar essas features, tente fazê-lo em projetos restritos para que não haja problemas com usuários de browsers antigos. Se ainda assim você quiser arriscar, crie soluções especifica para seu projeto, fazendo com que a experiência do seu cliente não seja muito prejudicada.
Sugiro que utilize a biblioteca Modernizr para identificar os browsers que não entendem o CSS 3D.

Tudo é uma questão de perspectiva

Para falar de 3D, precisamos falar sobre perspectiva. Para ativar uma área 3D o elemento precisará de perspectiva.
Você pode aplicar a perspectiva ao elemento de duas formas: utilizando diretamente a propriedade perspective ou adicionando um valor perspective() na propriedade transform.

Ou:

Estes dois formatos são os gatilhos que ativam a área 3D onde o elemento irá trabalhar.

O valor da perspectiva determina a intensidade do efeito. Imagine como se fosse a distância de onde vemos o objeto. Quanto maior o valor, mais perto o elemento estará, logo, menos intenso será o visual 3D. Logo, se colocarmos um valor de 2000, o objeto não terá tantas mudanças visuais e o efeito 3D será suave. Se colocarmos 100, o efeito 3D será muito visível, como se fosse um inseto olhando um objeto gigante.

Você também precisa entender sobre o ponto de fuga. O ponto de fuga por padrão está posicionado no centro. Você pode modificar essa posição com a propriedade perspective-origin, que é muito parecido com a propriedade transform-origin, que define onde a ação de transformação do objeto acontecerá, nesse caso quando falamos de ações 2D. A propriedade perspective-origin afeta os eixos X e Y do elemento filho.

Veja um exemplo com dois elementos: um com pouca perspectiva e outra com muita perspectiva.

CSS 3D Transforms

Se você ainda não leu sobre CSS Transforms você pode ler algo aqui e ver em ação aqui. As propriedades são praticamente iguais, mas aplicadas para os princípios de 3D e não 2D.

Você deve estar acostumado a trabalhar com os eixos X e Y no CSS padrão. No CSS 3D podemos manipular também o eixo Z, que representa a profundidade.
Veja um exemplo utilizando os valores rotateY, rotateX e translateZ. Perceba que no translateZ eu utilizei valores negativos e positivos. Quando utilizo o valor negativo, o objeto fica “mais longe”, se coloco valores positivos, o objeto fica “mais perto”.

Abaixo segue uma imagem do resultado do exemplo:

Nós podemos utilizar também alguns atalhos para estes valores onde podemos definir as três dimensões de uma vez:

• translate3d(x,y,z)
• scale3d(x,y,z)
• rotate3d(x,y,z,angle)

Muito importante: ao utilizar as propriedades resumidas, os browsers ativam automaticamente a aceleração por hardware no Safari para que as animações tenham uma melhor performance.

Fazendo o efeito de Card Flip

O efeito de Card Flip é muito conhecido entre os usuários de iPhone. Para ter ideia de como é o efeito veja o exemplo final.

A estrutura HTML é esta:

O elemento .geral é onde iniciaremos o ambiente 3D. O elemento .carta age como container dos objetos 3D. Cada face da carta está separada por um elemento figure, com uma imagem.

Para começar, precisamos aplicar a perspectiva para o elemento .geral iniciar o espaço 3D.

Defini uma largura e altura, coloquei um position: relative; para que os elementos dentro dele sejam posicionados se referenciando por ele. Coloquei uma margem só para separá-lo do topo do body a fim de conseguirmos ver melhor os efeitos.
Por fim, coloquei a propriedade -webkit-perspective: 500; para aplicarmos o efeito 3D. O valor de 500 faz uma boa perspectiva.

Agora definiremos as dimensões da carta e suas propriedades.

Largura e altura precisam ser de 100% para definir a área que o 3D irá aplicar. O position: absolute; é necessário para que as cartas fiquem relativas ao elemento .geral. A propriedade -webkit-transition: -webkit-transform 1s; define o tempo de transição do efeito, neste caso ele vai durar 1 segundo.

Formatando as cartas:

Vamos direto para a propriedade -webkit-backface-visibility: hidden; já que as outras dispensam comentários. Essa propriedade faz com que a face de trás da carta não apareça e nem se sobreponha no momento do efeito.
E finalmente, para fazer com que a parte de trás da carta apareça no verso correto, nós temos que rotacioná-la.

E feito se completa com o trigger para fazer a animação acontecer. Nesse caso farei com um hover no elemento .carta, onde iremos rotacioná-lo em -180 graus.

E Voilá! Se quiser brincar um pouco, modifique a origem da transformação com a propriedade -webkit-transform-origin. Adicionando essa linha, a transformação acontece para a direita em vez de ser pelo centro, como é o padrão:

3Drollover.css

Encontrei uma biblioteca muito interessante que nos permite fazer estes efeitos de forma fácil e de acordo com os princípios do OOCSS. É necessário apenas estruturar da forma correta e trocar as classes de acordo com o efeito que você quer fazer. Coisa muito simples.

O nome da biblioteca é 3Drollover. Clone no seu computador e divirta-se. Dá para usar em projetos facilmente. Veja abaixo um vídeo que mostra os efeitos:

Para ler mais

• Leia a documentação oficial do W3C sobre CSS 3D Transforms.
• Pessoal do WebKit explicando sobre outras propriedades do CSS 3D Transforms.
• Você pode brincar um pouco com as propriedades do CSS 3D aqui.

Posts Relacionados

• CSS3 – Módulo Template Layout
• CSS3 – Animation e regra keyframe
• CSS3 – Abas com a pseudo-classe :target
• ePub: Aprenda a criar um livro digital
• OOCSS ou CSS do jeito certo

Escrever CSS é fácil. Isto não deveria ser um problema, mas é. Por ser fácil os desenvolvedores acabam se esquecendo de princípios básicos, técnicas e metodologias que nos ajudam a manter o controle durante a produção. Entenda que algumas dessas metodologias não precisam ser aplicadas em sites pequenos. Por exemplo, aqui no Tableless eu não modularizo o CSS em vários arquivos por um ou dois motivos: 1) Somente eu tenho acesso ao código. 2) O site não é grande. Ele tem meia dúzia de páginas e funcionalidades. 
Mas quando falamos de sites grandes (em visitação e quantidade de páginas) existem algumas restrições: velocidade de carregamento, compatibilidade entre browsers, manutenção, flexibilidade para mudanças etc. Tudo isso deve ser pensado e planejado antes de colocarmos a mão na massa. É no planejamento que iremos estruturar como serão feitas as manutenções posteriores, como iremos mudar elementos principais sem interferir no layout como um todo.

O CSS Orientado a Objeto (em inglês OOCSS – Object Oriented CSS – Sendo sincero, esse nome é muito ruim) tem como conceito técnicas que já falamos durante muito tempo, mas que como o Responsive Web Design, está ganhando força somente agora.

Princípios

O OOCSS está baseado em dois pontos cruciais que são a separação da estrutura e do visual e a independência do container em relação ao conteúdo.

Separação da estrutura e do visual

A maioria dos elementos estilizados em uma página web tem diferentes características visuais que são repetidas em diferentes contextos e situações. Algumas características são fáceis de identificar como cores, títulos, gradientes, bordas etc. Essas são características visuais. Contudo, existem também as características de estrutura, que é onde nós “montamos” os elementos, definindo tamanhos, distâncias, medidas etc. Essas características também são repetidas em diversos elementos no decorrer do site.

A ideia é que nós separemos as características visuais das características estruturais, tornando-os modulares de forma que possamos reutilizá-los em diferentes elementos tendo resultados iguais.

Imagine 3 elementos diferentes, como um botão, uma caixa de chamada e um destaque que normalmente fica na lateral do site. Eles tem características estruturais diferentes, como width, height, paddings, margins etc. Mas as características visuais são iguais, como por exemplo o border-radius, background e o box-shadow. O CSS normal ficaria assim:

Para reutilizar de forma inteligente as características iguais destes elementos e prevendo que talvez seria criado outros elementos com as mesmas características – já que o designer mantém sempre (quase sempre, né?) um padrão visual estético – é interessante que criemos uma classe que componha estas características e apliquemos essa classe nos elementos necessários. Assim:

Em cada elemento que necessitasse destas características visuais, basta inserir a classe .boxEffects ao elemento.

Entenda que o abuso dessa técnica pode trazer complicações. Você não vai criar uma classe para cada característica visuais e sair aplicando essas classes em tudo quanto é elemento. Você estaria voltando a 1999 onde tínhamos aquele velho problema de misturar as camadas de formatação e informação.

Independência dos containers e do conteúdo

Imagine que você crie algum estilo para a formatação de algum elemento como por exemplo um parágrafo e atrela este estilo para os parágrafos localizados no article principal:

Mas então surge a necessidade de ter um parágrafo com as mesmas características no rodapé, por exemplo, mas com o tamanho da fonte maior! Você pode fazer assim:

O que é ainda é ruim, mas é muito melhor do que fazer assim:

Onde duplicamos desnecessariamente vários estilos.

Com o OOCSS nós devemos transformas estes estilos em módulos para serem reutilizados e não atrelando os estilos a um elemento específico.

Isso acontece também quando já fizemos uma classe onde carrega os estilos comuns. Se voltarmos ao exemplo anterior, alguém pode fazer assim:

Estamos aqui atrelando a classe que antes era para ser algo genérico ao elemento footer. Cuidado ao fazer isso. Tenha um bom motivo antes de ir adiante.

Outras boas práticas

Existem algumas boas práticas que fazem parte do OOCSS e que melhoram muito o planejamento e a prática do desenvolvimento web:

Modularização de código CSS

Não estou falando aqui sobre a modularização de arquivos CSS, mas sim do Código. Essa modularização é feita sob medida para cada um dos projetos. O objetivo é que o código CSS seja reutilizado em várias partes da produção evitando que você crie mais código. É aconselhável que se defina padrões de código para os principais elementos do layout. A equipe pode fazer isso ou delegar esse importante trabalho para um desenvolvedor, que será responsável em criar os métodos e os padrões estruturais dos elementos.

Minimizar usos de seletores muito específicos

Encontre o meio termo. Não faça seletores muito específicos ou seletores muito genéricos. O CSS trabalha com especificidade: quanto mais específico, mais certeiro você é ao capturar um elemento, mas seu CSS fica mais engessado e consequentemente você usa mais código. Quanto mais genérico, mais elementos do mesmo tipo você formata, mas o risco de conflito de estilos aumenta. O ideal é encontrar o meio termo, onde você é tão específico e nem tão genérico.

Dependendo da forma que você utiliza os seletores os browsers podem ser ou não mais rápidos ao renderizar seu site. Já falamos disso aqui.

Formate elementos com classes modulares

A ideia é que ao criar uma nova página, você não tenha que criar novo código CSS. Se a página tiver a estrutura diferente mas os elementos tem características visuais iguais, aí está uma boa oportunidade para modularizar o código visual dos objetos.

Um exemplo para demonstrar essa prática é ao fazer botões para diferentes ações. Normalmente utilizamos os mesmos botões com cores diferentes para definirmos visualmente ações diferentes que o usuário pode tomar. O botão de SALVAR tem o mesmo formato de CANCELAR, mas a cor dos dois é diferente, sendo que o primeiro é verde o segundo vermelho. O código seria assim:

Este código cria toda a estrutura do botão. Agora falta definir as cores de fundo. Eu farei isso criando duas classes: btVerde e btVermelho. Essas classes serão utilizadas em pareceria com a classe botao

Agora, o HTML ficaria assim:

Porque criei os nomes das classes btVermelho e btVerde em vez de btCancelar e btSalvar? Porque pode ser que exista algum botão que também seja verde, mas não tenha a ação de salvar. Assim deixo meu leque aberto para novas atribuições.

Concluindo

Seguir esses pequenos detalhes evitam uma série de problemas comuns no desenvolvimento client-side. A reutilização de código CSS se torna real, a velocidade do carregamento melhora e os problemas de manutenção são solucionados. A flexibilidade que teremos ao modificar o CSS será muito grande e não aumentaremos nosso código a cada modificação feita. A ideia é que seu código CSS fique sob controle. A utilização de frameworks e bibliotecas podem ajudar em muitos momentos.

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• CSS3 – Animation e regra keyframe
• Pontuação de especificidade da CSS
• CSS3 – Sombras em textos e elementos
• CSS3 – Módulo Template Layout

O LESS chega nesse barco, adicionando um alto nível de personalização e permitindo recursos de programação em folhas de estilo estáticas. Com a biblioteca, é possível utilizar recursos como variáveis, funções, operações e escopo dentro de simples regras CSS.

Variáveis

Uma das principais funcionalidades do LESS é a criação de variáveis.

Variáveis servem para definir valores padrões para seus projetos e facilitar a manutenção e alteração dos mesmos. As variáveis acima poderiam ser utilizadas em diferentes estilos, por exemplo:

Mixins

Mixin é um conceito de programação orientada a objetos e basicamente representa a utilização de classes dentro de classes. Essas classes não são instanciadas e servem apenas para reaproveitamento de código.

No LESS, mixins são classes/declarações que serão utilizadas dentro de outras classes de estilo.

Variáveis e mixins são as principais ferramentas para evitar uma terrível prática: repetição de código (no nosso caso, repetição de estilos).

Funções

Estendendo o conceito acima, funções são mixins que recebem parâmetros. Os parâmetros podem ter um valor padrão, como o exemplo borda_arredondada abaixo (6px), que será utilizado caso nenhum parâmetro seja passado.

Regra dentro de regra dentro de regra…

Alguns desenvolvedores já aplicam essa técnica visualmente. No entanto, com LESS, as regras aninhadas também herdam os valores de seus “pais”.

Note o símbolo “&” que representa a concatenação. O elemento não herda simplesmente os atributos de seu antecessor, ele também sobrescreve o novo valor. Essa regra é importantíssima para pseudo-elementos como :hover, :focus etc.

Operações

O LESS também permite operações com valores e cores. Por exemplo, é possível multiplicar uma cor hexa-decimal ou dividir uma certa quantidade em pixels.

As funções de cores englobam efeitos como dessaturação e fade.

Para valores compostos, como o border do div#conteudo abaixo, é obrigatório o uso de parênteses.

Na documentação oficial do LESS você encontra uma lista completa das funções para cores.

Escopo & Namespace

Para quem já programa, os conceitos explicados até agora são familiares. O LESS nada mais é do que um framework que transforma o CSS em uma pseudo linguagem de programação.

Escopo é outro conceito importante em programação que também está presente no LESS.

Uma variável possui um escopo global e outro local, dentro de sua função/mixin. O LESS vai sempre procurar primeiro por varáveis no escopo local e depois em seus antecessores.

Você também pode reutilizar apenas uma parte de um mixin aplicando um namespace para encapsular seu código.

O h1 do elemento #header herda apenas o .principal do #titulo.

Implementações

A implementação do LESS pode ser feita on the fly, com JavaScript. Esse método é recomendado para sites pequenos, com pouca audiência. Para sites mais visitados, pré-processe seus arquivos LESS, transformando-os em folhas de estilo estáticas.

Por exemplo, para aplicativos Ruby/Rails existe uma gem que converte arquivos LESS para CSS. Já o o módulo compressor do Django oferece suporte nativo.

Outra solução bacana é o aplicativo LESS para Mac.

E se você procura elementos básicos já prontos, a dica é visitar o site Less Elements. Nele você encontra soluções para bordas, degradês e sombras.

Posts Relacionados

• ePub: Aprenda a criar um livro digital
• Experiência cross-device
• Introdução ao CSS 3D – Flip Card
• OOCSS ou CSS do jeito certo
• Biblioteca CSS ou Framework?

O background do profissional neste momento não importa muito, apenas a afirmação que ele está trabalhando na camada de front-end. Só isso basta para confirmar os papéis acima.

Em muitas empresas o front-end é trabalhado de maneira criteriosa, com separação de tarefas em maior ou menor intensidade, de modo que o processo esteja sempre azeitado e atento aos prazos dos outros times que dependem da interface. Em algumas outras, o responsável pelo código é o unico responsável por fazer tudo isso acima. E isso acontece com frequência.

É o famigerado exército-de-um-homem-só, que em um projeto normalmente é responsável por:

• Pesquisa: Fornece dados e insights para o desenvolvimento de todo o projeto – sobre o usuário, suas características, hábitos e necessidades. Apesar de orientada a um projeto específico, essa pesquisa também deve ser constante, oferecendo atualização e embasamento para a criação de novas experiências.
• Arquitetura da informação: Organização de informação, entendendo o modelo mental do usuário, para que ele se reflita também no produto final.
• Design da interação: Desenhar a interação de forma que ela seja consistente, fácil e auto-explicativa. Entende ros requisitos de usabilidade criados na fase de pesquisa e dominar os padrões de interação que a aplicação deve ter, além de saber lidar com a multiplicidade de devices e plataformas onde a interação ocorre.
• Design Visual: Balanceando beleza e comunicação, domina tanto a direção de arte do produto que está sendo desenvolvido quanto o acabamento final dos pequenos detalhes da interface.
• Redação: Expressar as ideias, simples ou complexas que o cliente passou para o desenvolvedor em palavras simples e que sejam facilmente entendidas pelos usuários do produto. Este conteúdo vem do cliente, mas não é difícil acontecer  do desenvolvedor ser responsável por criar algum conteúdo, seja transformando a linguagem do cliente dentro de um contexto web, deixando-a mais dinâmica e convidativa a leitura, seja pequenos conteúdos que devem ditar padrões visuais para interações do usuário.
• Prototipagem:  Criação da UI. Isso serve tanto para o estágio inicial do projeto (com protótipos de papel, de baixa fidelidade) quanto para o estágio que precede o desenvolvimento, onde o produto já está mais amadurecido e mais próximo do final. Esta etapa pode ser a da criação das páginas em si, uma vez que os modelos de conceito e interação estão prontos e o design está criado ( sites tipicamente estáticos ou de menor porte ) ou pode ser a fase da criação dos protótipos que devem ir para a integração depois (back-end).
  
• Gerenciamento: Garantir o funcionamento de todas as áreas de entrega da melhor e mais produtiva maneira possivel. E ainda ser o ponto focal com cliente e usuário, quando necessário.

Em um departamento multidisciplinar de UX, no melhor dos mundos, temos atribuições diferentes para diferentes profissionais. Muitas vezes, isso não acontece. Outros casos, não raros, a empresa não está interessada na matéria, ou apenas não tem profissionais que atuam nesta área que se preocupam com o código (e design) que entregam. Vai saber. Em empresas com atribuções de projeto mais estruturadas um departamento de UX conversa claramente com outros áreas, como Arquitetura, DBA, Requisitos, Integração, Testes e Gerência.

No FrontInBH, conversando com os desenvolvedores no final do evento, e também em conversas com devs de todos os cantos, é fácil perceber que empresas com equipes de desenvolvimento reduzidas (SMB, agências, pequenos portais) mantém um ou dois especialistas que acabam fazendo todo o serviço. E estes profissionais acabam por andar entre duas profissões distintas: Designer de Interação e Interfaces ou o Desenvolvedor web.

Vale lembrar que estas duas profissões tem backgrounds muito diferentes. Enquanto os designers lidam com abstração, devs costumam lidar com aobjetividade do código. Disciplinas que vão de Teoria de Cores à Orientação a objetos fazem parte do background destes profissionais, porém é com muito trabalho que são desenvolvidos as especialidades, devido a matérias tão antagônicas.

Algumas das disciplinas que um profissional de web hoje deve saber para atender demandas de projeto

Essa diferença de backgrounds acaba por oferecer barreiras que fazem com que o desenvolvimento e a integração das disciplinas seja muito difícil. E com isso temos profissionais que desenham interfaces e interações lindas, mas que não podem funcionar sob conceitos de acessibilidade, ou ainda websites perfeitamente acessíves e fluídos, mas que não tem um design tão impactante.

Diante deste cenário tenho trabalhado para desenvolver um conceito que chamo de Metawebdesign. A proposta é justamente encurtar estes espaços, sem incomodar profissões importantíssimas e já consolidadas, mas que por razões diversas em algumas vezes acabam por ser a mesma coisa no organograma de uma empresa.

Meu primeiro e segundo artigos sobre o assunto vão falar sobre formulários. Muito já foi falado, e não quero repetir o que já sabemos. Porém é importante mostrar como conceitos de design da interação, arquitetura da informação e código são usados para criar aplicações que oferecem uma experiência inesquecível para o usuário. Estes dois posts iniciais sobre o assunto se transformam em um toolkit muito útil aonde você poderá com a parte 1 e 2 escolher usando conceitos de design os melhores elementos de controle e depois entender como codificá-los de acordo com os padrões do W3C, mantendo usabilidade e acessibilidade.

Aplicando o Metawebdesign a formulários: o design da interface

Cedo ou tarde, a aplicação que você esta criando vai precisar perguntar (ou pedir) ao usuário algum tipo de informação. E sob o ponto de vista do usuário, nesse momento a credibilidade de seu design de interação e código estarão em jogo, pois complexidade e simplicidade aqui separam o céu e o inferno.

Todos sabem como usar alguns elementos de controle como input texts, checkboxes, radio e dropdowns – e isso não somos nós desenvolvedores de aplicações web. Isso é consenso, domínio público: um status quo que todo usuário de computador aprendeu a identificar e saber operar. Mesmo novos usuários entendem estes elementos com uma rapidez impressionante. O problema é como agrupar todos eles em torno de um bem comum – o bem sucedido submit. Afinal de contas, fazer um formulário é simples, basta colocar um bando de informações ordenadas de maneira racional, colocá-las na página com alguma ordenação top-bottom e é isso, correto?

Para começarmos a conversa, isso é o que os usuários esperam.

De acordo com o w3c, um formulário HTML (form) é uma seção do documento HTML que pode conter informação estática, elementos de controle (os mesmos mecionados acima e alguns outros que vamos falar aqui) e labels que referenciam estes controles semanticamente. Tudo isso para permitir que o usuário possa responder (ou preencher) uma série de perguntas que a sua aplicação precisa para prosseguir com o fluxo. E o usuário interage com tudo isso alterando elementos de controle.

Bons e maus exemplos:

Bons exemplos de formulário são fáceis: você mesmo deve conhecer vários; são aqueles que você usa diariamente sem gastar muito tempo ou que não entediam durante seu preenchimento. Maus exemplos são fáceis e estão por todos os cantos da internet, não é difícil encontrar um (na verdade não precisamos nem procurar). Só que não é ético questionar o trabalho de ninguém sem saber as variáveis que levaram aquela implementação. Sendo assim, olha que “bonito” esse formulário que está no site da Apple como exemplo de um mau form.

Acredite: foi difícil até colocar tudo isso em um espaço visível. E ainda nao ficou bom.

Antes de entrarmos de cabeça nos elementos e como formulários devem ser criados, precisamos entender alguns principios básicos de um design de form:

Form Design – O básico:

1. Tenha certeza que o usuário entende o que e o porque você está pedindo ou perguntando algo;
   Escreva labels com palavras que seus usuários possam entender facilmente independente de serem usuários frequentes ou novos usuários, tenha cuidado com os jargões ou acrônimos utilizados. Se necessário, desenhe para o usuário.
• exemplo 1 : antes de um grande formulário, tome algum espaço da tela para explicar como ele funciona e o porque você precisa de todas aquelas informações.
• exemplo 2: Se você precisa colocar um controle na tela que não é imediatamente óbvio dentro de um fluxo da tela, use uma tooltip ou outro tipo de ajuda que mostre ao usuário o que ele deve fazer em seguida.
2. Se puder, evite a redundância;
   Antes de colocar os campos em uma tela, analise a informação e o contexto de cada um deles e se possível, agrupe informações para minimizar o numero de campos a serem preenchidos. Mesmo no melhor dos cenários, gastar tempo preenchendo caixas de texto não é algo divertido.
• exemplo 1: se o usuário já preencheu o endereço de entrega no formulário de checkout, você pode reutilizar esta informação para o endereço de cobrança. Basta adicionar um checkbox perguntando se o endereço de entrega e cobrança são os mesmos que em caso de positivo, você já atendeu aos requisitos.
• exemplo 2: Se 80% dos seus usuários estão no Brasil, 15% estão na Argentina e 3% nos Estados Unidos, você pode usar um <select> ao invés de uma <input type=”text”> para atender os requisitos de país. As opções seriam Brasil, Argentina, USA e logo após teríamos lista com a ordenação alfabética.
• exemplo 3: Para endereços no Brasil, no <fieldset> de localização, perguntando apenas o CEP podemos recuperar endereço, bairro, cidade e estado. Com isso faz sentido perguntar primeiramente o CEP, recuperar o valor via webservice e após o sucesso automaticamente preencher estes campos para o usuário.
• Existem também exceções: A segurança deve ser levada em conta ao ponderar sobre recursos de auto-completion. Não seria ético tampouco legal recuperar os dados do cartão de crédito do usuário para onerá-lo da tarefa de inputar seus dados bancários, uma das partes mais tediosas e passíveis de erro durante a transação de um checkout.
• 
  
3. Informações de conhecimento público normalmente são mais acuradas que informações de conhecimento pessoal; Quando perguntamos algo ao usuário, temos que ter em mente que eles podem mentir (everybody lies) ou mesmo errar. Podemos minimizar isso reduzindo problemas. O sistema de auto-completion com o CEP mencionado acima é um exemplo claro. Um erro simples de digitação pode causar um problemão na hora da entrega: a rua Roda dos Ventos pode virar rua Rosa dos Ventos em um clique. Probabilidade altíssima de problemas futuros que você pode evitar usando este tipo de abordagem.
4. Tenha cuidado ao transformar os requisitos de design em forms;
   A maioria dos forms é criada para manipular transações feitas com o banco de dados ou alterar objetos de uma tela. Explore as dependências entre os elementos, procure por similaridades que possam ser agrupadas graficamente, como campos de endereço ou informações pessoais. O exemplo do endereço de entrega versus o endereço de cobrança mencionado na regra #2 pode ser repetido aqui. Porque não habilitar em um form de inserir produto um drag-n-drop para definir a ordenação das imagens de descrição deste produto ao invés de subir as imagens em uma ordem pré definida ou ainda primeiro subir as imagens para só depois ordenar?
   
   
5. Teste, teste novamente e quando achar que está tudo ok, teste de novo; Por alguma razão que nunca vamos descobrir, é incrivelmente fácil desenvolvedores e usuários terem idéias completamente diferentes quando o assunto é preencher um formulário. O mesmo form! Isso pode acontecer pelos mais variados modos:
• conhecimento prévio com interações passadas,
• respostas possíveis,
• fluxo de página que depende de um contexto que o usuário pode entender de maneira diferente dependo de variáveis externas.

Por isso é importante montar o formulário e se certificar que todas as possibilidades de interação do usuário com os elementos da tela estão garantidas:

• preenchimento de campos;
• clique/toque em botões e objetos de tela;
• entrada de dados validados para atender requisitos de design da aplicação;
• condições especiais de uso e interação do form.

Isso nos dá evidência empírica do que funciona e o que nao funciona em sua aplicação, além de claramente indicar o caminho a seguir no caso de identificar um problema.

1. Escolha sabiamente os elementos de controle: eles impactam a expectativa do usuário sobre o que ele está sendo perguntado e como deve responder a isso:

• Os usuários tendem a associar o tamanho e forma física dos campos a o que eles imaginam que seja o que estamos perguntando. Só depois desta associação é que os usuários lêem o que o label de um campo está pedindo.
• Uma única radio button vai ser algo ditatorial pois sugere a existência de pelo menos duas opções na tela.
• Após você estar acostumado com o processo de compra de sua loja online e seu formulário, automaticamente você irá suavizar sua atenção por não ser uma tarefa nova e sim uma repetição (e daí entendemos o porque a estrada para para erramos um formulário que preenchemos “todo dia” é tão curta)

Escolhendo elementos de controle

Quando estamos montando o design do nosso form temos que nos ater a algumas situações que impactam diretamente todo o formulário:

1. Espaço disponível na tela: não precisamos falar nada sobre isso. Cada pixel conta e sabemos disso muito bem, então escolha sabiamente como usar os elementos para tirar total proveito da sua área de exibição.
2. Sofisticação no formulário deve respeitar uso geral dos forms: <input type=”text”> é algo que todos os usuários estão familiarizados a usar e vão fazê-lo bem, mas nem todo mundo estará confortável em usar um slider de range, com acionamento duplo.
3. O form deve respeitar o conhecimento público nos domínios da sua app: É aceitável você usar um <input type=”text”> para um campo que aceita valores entre 0 e 1000. Mas isso iria requerer uma validação para certificar que numeros maiores ou negativos fossem inputados. Se a maior base dos seus usuários está confortável com esta regra, não existe o motivo de usarmos o mesmo slider de range mencionado acima, por todos os problemas de implementação, tempo, acessibilidade e principalmente, dificuldade de uso.
4. Elementos externos criam expectativas que podem ser erradas: Temos o conhecimento que negrito, itálico e sublinhado são iconografias que foram criadas para dar um destaque a alguma palavra. Fica fora de contexto utilizarmos estas formas para exibir labels por exemplo.
   
   Olha o fast-food “encostando uma arma na sua cabeça” ao perguntar o que é mais saudável.
5. Tecnologia disponível: o HTML e suas APIs oferecem suporte a muitos elementos de controle, e para os que não são suportados nativamente, existe uma grande gama de toolkits e frameworks que vai te ajudar a implementar aparência e controle em situações específicas.

Elementos de controle de Formulários

Para fazer o design de uma tela de formulário, precisamos de elementos de controle. No jargão do HTML, seriam elementos HTML, que nada mais é que o conteúdo que está dentro de uma tag, podendo inclusive ter outros elementos filho caso seja do interesse. Dito isso, fica muito mais fácil entender como o design trabalha com elementos de controle. Após escolher seus elementos na tabela abaixo, tudo que você precisa é codificá-los seguindo os padrões que já conhecemos.

Montar uma tela de formulário não é complicado. Estamos acostumados a fazer isso todos os dias. Porém existem mais coisas entre o céu e a terra do que pode imaginar a nossa vã filosofia. O tópico acima mostra algumas variáveis que as vezes podem passar desapercebido e podem ajudar – e muito na hora de montar o design da sua tela. Você consegue se imaginar trabalhando orientado ao Responsive Webdesign sem utilizar os conceitos básicos mostrados acima? Pode parecer óbvio, mas é importante manter isso em mente ao utilizar a tabela abaixo:

Elementos de controle em um formulário são divididos em:

1. Seleções e listas:

• Seleções binárias: sim/não, ativo/inativo, etc;
• Escolha de UM item para N com poucas e muitas opções;
• Escolha de N items para N com poucas e muitas opções;
• Listas não-ordenadas;
• Listas ordenadas.

2. Texto:

• uma linha de texto;
• múltiplas linhas de texto não formatados e formatados

3. Números:

• com qualquer formato;
• dentro de um range (limite);
• subrange (sublimite);

4. Data e hora.

Use a tabela acima para escolher os melhores elementos de tela de acordo com sua necessidade. Você perceberá que as opções cobrem todas as necessidades atuais, alinhadas ao HTML5.

Padrões para Elementos de Controle

Os elementos de controle acima necessitam de padrões de funcionamento. Estes padrões mostram:

1. Como combinar elementos;
2. definir relações estruturais entre elementos;
3. controlar mudanças de valores e como estes valores são alterados

Alguns elementos de controle possuem requisitos de funcionamento que já estão aplicados ao elemento em si (spinners ou datepickers já possuem seu comportamento nativo no elemento graças ao HTML5). Outros necessitam de programação no back-end, seja para validação, seja para a criação de ranges, seja para outras necessidades específicas. Quanto mais versátil o elemento, maior a possibilidade de usá-los. Um bom exemplo seriam input type=”text” que com frequência possuem funcionalidades específicas, alem de aceitar qualquer coisa textual.

• Máscaras:

Máscaras permitem texto em qualquer formato ou sintaxe, fazendo com que o input do usuário seja interpretado de maneira inteligente, a medida que é digitado no campo.

Máscaras são usadas quando sua interface necessita de dados que usuários podem inputar usando qualquer tipo específico de conteúdo, porém não possuem a obrigação de conhecer estes formatos automaticamente:

1. remover espaços,
2. inserir apenas números (ou texto),
3. texto sempre em caixa alta (ou caixa baixa),
4. abreviações, etc.

Usuários querem que a ação (submeter o formulário) aconteça, não querem (nem devem) se preocupar com formatos corretos e interfaces complexas. Jacob Nielsen já dizia que “Usabilidade na web passa pelo fato de que como desenvolvedores de interface, não podemos deixar o usuário pensar demais para fazer uma ação. Ele simplesmente tem que fazê-la de maneira cognitiva”. Máscaras podem inclusive remover a necessidade de dicas no input ou dicas no prompt.

• Formato estruturado:

Estruturar um campo de input significa quebrar um campo em vários outros, de modo a facilitar o entendimento do que é esperado que o usuário faça. Um bom exemplo seria quebrar um campo único de CEP por exemplo em dois campos, um para os primeiros 5 números, e outro campo para os 3 restantes. Outros exemplos podem ser mencionados: números de telefone, numeros de cartão de crédito (cartões AMEX tem um numero de caracteres diferente de cartões VISA por exemplo).

• Fill-in-the-blanks: Combine um ou mais campos de modo a permitir que o usuário possa categorizar o que está inputando, facilitando a ação do usuário. Um bom exemplo seria um formulário de pesquisa em uma loja virtual:

Usar esta abordagem faz com que a interface seja auto-explicável. Ajuda ao usuário entender o que está acontecendo e o que foi pedido para ele.

• Dicas no input: As dicas no input são importantes para fornecer um guideline ao usuário de como ele deve inputar valores dentro de um campo. O exemplo abaixo, retirado de um form do site dos correios para rastreamento de objetos ilustra bem isso.
  
• Placeholder no input: O placeholder é um texto adicionado dentro do input e que automaticamente desaparece quando o usuário posiciona o cursor da tela dentro do campo. Um bom exemplo pode ser visto no form de busca das páginas do portal globo.com.
  
• Auto complete: O nome é auto-explicativo. A medida que o usuário vai digitando caracteres, os termos são auto-completados, fazendo com que o input seja mais rápido caso o resultado esteja disponível no índice usado. Veja o form de search no site do google.com.br
  
• Dropdown chooser: Dropdowns podem ser usadas para acomodar seleções que podem utilizar um grande espaço na tela quando expandidas, porém não tem a necessidade direta de deixar todas as opções disponíveis (que usualmente são muitas). Um bom exemplo é a dropdown de seleção de cores no Google Docs.
  
• Seleção ilustrada: Em alguns casos descrever a opção não é suficiente. É necessário ilustrá-la com uma imagem para facilitar a seleção do usuário. Um bom exemplo é esta dropdown de seleção de papel de parede disponível no site do livro Designing with Progressive Enhancement.
  
• List Builder: Quando você precisa criar uma lista de items oriundos de uma outra lista, o listbuilder é o padrão ideal a ser usado. Duas textareas e programação fazem com que valores possam ser adicionados ou removidos, além de também poderem ser ordenados facilmente. Veja este exemplo de listbuilder para a configuração de uma toolbar:

• Mensagens de erro:
  Quando o usuário faz algo correto ele recebe um feedback de sucesso, informando que o formulario foi submetido sem problemas. Mas também é necessário informar de maneira clara quando algo dá errado. Mensagens de erro podem ser customizadas de modo a evitar deixar o usuário “no escuro” quando algum erro acontece. Campos obrigatórios precisam de validação (agora mais simples com o atributo required presente no HTML5), mas podem acontecer outros erros que necessitam de feedback claro para indicar quais os próximos passos a seguir.

Você pode usar o poster abaixo como referência para criar suas interfaces. Clique na imagem para vê-la em uma maior resolução.

Na próxima semana, com a Parte 2, a abstração dá o lugar ao código para saber como montar os items que você selecionou para montar seus formulários, transformando os dois posts em um toolkit para o dia-a-dia. Namastê!

Referências

1. Metawebdesign – Quando o Front-end se encontra com a experiência do usuário: http://www.slideshare.net/AlyssonFranklin/metawebdesign-frontend
2. O Metawebdesign – http://metawebdesign.org
3. Designing Interfaces – Second Edition (Jenifer Tidwell- O’Reilly books) http://designinginterfaces.com/
4. Top-down e bottom-up design:  http://en.wikipedia.org/wiki/Top%E2%80%93down_and_bottom%E2%80%93up_design
5. Everybody lies, uma frase do House: http://www.youtube.com/watch?v=nNOExDrsdbg
6. W3C sobre formulários: http://www.w3.org/TR/html4/interact/forms.html#h-17.1
7. http://www.mhavila.com.br/topicos/web/controles.html
8. Spinner: http://www.jgeppert.com/jquery-spinner/
9. A Form of madness: http://diveintohtml5.org/forms.html
10. Responsive webdesign: http://www.alistapart.com/articles/responsive-web-design/
11. Composição de um time multidisciplinar de UX - http://itweb.com.br/blogs/a-composicao-de-um-time-multidisciplinar-de-ux/
12. UX Team of One - http://www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one

Posts Relacionados

• Você sabe o que é a “nova usabilidade”? – parte II
• Usabilidade de interfaces para dispositivos móveis – parte II
• Estabelecendo uma metodologia ágil para avaliação de usabilidade

No caso de CSS, os frameworks constituem bibliotecas que visam permitir a codificação do CSS de modo mais fácil e compatível com padrões de estilos, agregando uma série de opções já prontas para projetar uma página web, como se fosse um esqueleto, reduzindo o tempo gasto com o desenvolvimento.

Os frameworks CSS geralmente apresentam definições de formatação os elementos mais comuns de uma página: formulários, cabeçalhos, estilos de textos e imagens. Alguns apresentar opções para a estruturação do conteúdo baseado em grids.

A utilização de frameworks HTML e/ou CSS ainda é um assunto que divide a opinião dos desenvolvedores, pois muitos consideram o framework como uma solução pronta e acreditam que ele tira o trabalho das mãos do designer/desenvolvedor e faz com que ele não aprimore os seus conhecimentos.

Será que você, sem perceber, nunca criou o seu próprio framework? Pense em um arquivo CSS padrão (além do reset) que você criou para melhorar a produtividade de seus projetos.

É importante esclarecer que o uso de frameworks não substitui a necessidade do designer/ desenvolvedor de desenvolver o CSS do site. Ele apenas fornece uma base para a formatação de elementos comuns e otimiza o trabalho repetitivo.

Para quem os frameworks são recomendados

Utilizar um framework CSS não é uma prática recomendada para quem está começando, principalmente por privar a pessoa da prática e do conhecimento sobre o funcionamento do CSS. Além disso, se ela não compreender bem CSS, poderá ter problemas para resolver problemas de layout causados por incompatibilidade entre o framework e um código CSS específico que ela inseriu.

Portanto, é recomendável que frameworks sejam utilizados por quem possui um nível razoável de conhecimento e compreensão do código, mas tem a intenção de otimizar parte do trabalho com o uso de um framework. E isto serve não apenas para quem pretende utilizar um framework CSS, mas também qualquer tipo de framework.

Quando é interessante utilizar?

• Prototipação rápida em HTML
• Sites de larga escala e com estruturas similares (como portais, blog/sites no estilo magazine)
• Sites construídos através de plataformas de CMS
• Projetos que tenham prazos curtos
• Projetos realizados em equipe onde há diversas pessoas trabalhando no mesmo CSS, podendo ter um conjunto consistente de padrões de codificação

Vantagens

• Padronização de código entre a equipe de desenvolvimento;
• Arquivos modularizados;
• Flexibilidade de estilos, classes genéricas que podem ser combinadas de diversas formas nos elementos da página;
• Geralmente já possuem uma documentação, que pode ser consultada pela equipe em caso de dúvida ou necessidade de solucionar algum problema;
• Compatibilidade cross-browser (na maioria dos casos);
• Você pode melhorar suas habilidades estudando o framework;
• Redução de tempo: o desenvolvedor/designer pode se concentrar mais nos aspectos particulares do site desenvolvido, pois a base está assegurada e não precisa desenvolvê-la do zero;
• Reduz futuros esforços de manutenção caso seja necessário resposicionar elementos ou alterar características de renderização (fonte, margens, etc) em diversos elementos.

Desvantagens

• Quantidade excessiva de modificações que devem ser feitas para adaptar o framework;
• O framework pode conter códigos irrelevantes que nunca serão utilizados no projeto e serão carregados sem necessidade, podendo diminuir o desempenho da página;
• Nem sempre o código é bem organizado;
• Muitos frameworks apresentam classes pouco semânticas (ex.: span-5).

Algumas dicas para melhorar o uso do framework

Como as classes geralmente não apresentam muita semântica, procure colocar IDs significativos nos elementos da página, quando possível.

Você também pode optar por utilizar somente uma parte do framework. Em projetos em que utilizei o Blueprint CSS, muitas vezes utilizava apenas algumas folhas de estilos do framework que se adequavam ao que eu necessitava.

Dica: evite usar vários frameworks CSS em um mesmo projeto. Isto quebra a ideia de consistência, uma vez que cada framework tem o seu padrão de estruturação.

Como escolher o framework?

• Verificar se é realmente necessário o uso de um framework CSS no projeto;
• Avaliar se o código do framework escolhido tem uma estrutura e organização;
• Avaliar se há código excessivo que nunca será utilizado;
• Conferir se há uma boa documentação;
• Verificar se os recursos do framework são adequados ao que você necessita para o projeto. Não adianta utilizar um framework CSS focado em renderização quando seria mais útil um framework de grid.

Frameworks CSS, se bem utilizados, podem trazer muitos benefícios para seus projetos, basta saber como explorar o potencial que eles possuem

Referências

Why you should NOT use a web framework - http://checkedexception.blogspot.com/2010/04/why-you-should-not-use-web-framework.html

To use a framework, or not to: that is the question - http://www.phparch.com/2010/04/to-use-a-framework-or-not-to-that-is-the-question/

Please do not Use CSS Frameworks - http://mondaybynoon.com/2007/08/27/please-do-not-use-css-frameworks/

Which CSS Grid Framework Should You Use for Web Design? - http://net.tutsplus.com/tutorials/html-css-techniques/which-css-grid-framework-should-you-use-for-web-design/

When to use CSS framework? - http://www.vcarrer.com/2008/08/when-to-use-css-framework.html

WHAT’S NOT TO LOVE ABOUT CSS FRAMEWORKS? - http://jeffcroft.com/blog/2007/nov/17/whats-not-love-about-css-frameworks/

Frameworks for Designers - http://www.alistapart.com/articles/frameworksfordesigners

Posts Relacionados

• Biblioteca CSS ou Framework?
• Escalabilidade client-side
• Digest 04/09: CSS, HTML e Layout
• Criando um Menu Horizontal com CSS
• CSS Frameworks ou como desaprender CSS

Estou feliz porque o mercado de client-side tem amadurecido de forma inteligente no Brasil. Empresas mais espertas entenderam a importância do código HTML/CSS/ JavaScript bem escrito. O problema é que grande parte das empresas, clientes e desenvolvedores acham que o trio HTML/CSS/JavaScript faz milagres. É certo pensar que um código bem escrito traz grandes vantagens para o projeto, mas ele sozinho não faz milages.

É errado pensar que apenas por que você escreveu código HTML semântico seu site aparecerá em primeiro no Google ou ficará mais acessível para deficientes visuais. O código client-side é apenas a porta de entrada para uma série de outras tarefas.

SEO

Para criar um projeto de SEO é preciso seguir uma série de etapas que formam um grande pacote e que só então é possível perceber as vantagens do trabalho do SEO.
O código client-side entrará como uma pequena parte do esforço. De forma bem simples, podemos listar alguns pontos importantes que precisamos tomar atenção além do HTML bem feito:

• Estudo de concorrentes;
• Definição de diagramação e quantidade de texto nas diversas partes do site;
• Estudo de palavras chave e termos de uso;
• Planejamento de landing pages, entradas e saídas;
• Criação de robot.txt e sitemap.xml;
• Monitoramento de palavras, visitação e buscadores;
• Estudo de funil e preparação de goals;

Eu não sou um especialista do Google nem nada do gênero, mas sei que estes tópicos são importantes ao manter ou criar um website otimizado. O HTML certamente faz parte destes tópicos, mas ele não invalida nenhum dos outros pontos.
Obviamente não adianta nada fazer um bom estudo de palavraschave e marcá-las de forma errada com HTML.

Acessibilidade

Como em projetos de SEO, o planejamento de Acessibilidade precisa de uma série de etapas funcionar corretamente. No caso da acessibilidade o HTML ocupa um grau de importância muito grande, contudo, há pequenos pontos que o HTML não pode resolver sozinho. Veja alguns exemplos:

• Contraste e cores do layout;
• Estudo de atalhos de teclado;
• Menu de navegação rápida;
• Textos em tooltips, titles, alts de imagens etc;
• Tamanho de botões e textos;
• Arquitetura de Informação sensata e simples;

Embora algumas das tarefas sejam resolvidas com HTML/CSS, as definições e metas são pensadas pelos desenvolvedores. Qual cor, tamanho de botões e etc são decididos pelo designer e não pelo HTML. Não é incomum acharmos que apenas porque o site tem um código bem estruturado e semântico ele será bem acessado por cegos com leitores de tela ou pessoas com outro tipo de necessidade. Há tópicos que se dependem meramente do bom senso.

Se analisarmos bem as disciplinas de Acessibilidade, Usabilidade e Arquitetura de Informação, perceberemos que elas comandam a forma com que o trio HTML/CSS/Javascript devem se comportar. Há várias etapas e decisões que tomamos antes de colocarmos a mão no código. Cada um tem sua importância. Muitos erros de HTML podem ser evitados com um planejamento de Arquitetura de Informação. Muito código CSS pode ser otimizado estudando os wireframes do projeto.

Lembre-se de que o HTML/CSS/Javascript serve o conteúdo e não contrário. Eles devem trabalhar para que a informação seja bem exibida, formatada e que chegue integralmente para o usuário.

Posts Relacionados

• Experiência cross-device
• Drops 5 – Responsabilidade Dev Front-end
• Performance do seu CSS
• Convertidos do Tableless
• Drops 3 – Duas formas de modular seu CSS

Quando não restringimos os cenários a aparelhos temos um horizonte muito maior e mais frutífero. Entenda que a informação publicada na web pode e é totalmente reutilizada a qualquer momento. O Google faz isso com seu robô todos os dias, a todo momento. O robô do Google ou o de qualquer outro sistema de busca é um meio de acesso. O leitor de tela do usuário deficiente visual também é um meio de acesso. O leitor de RSS utilizado pelo seu celular, por mais simples que seja, é um meio de acesso. Podemos dizer então que qualquer dispositivo que o usuário utilize para consumir informação na web é um meio de acesso. Esse “qualquer coisa” pode ser um robô ou um sistema manipulado pelos visitantes de seu site.

O que é Responsive Web Design

Responsive Web Design é acima de tudo um conceito. Nós nos responsabilizamos a apresentar a informação de forma acessível e confortável para diversos meios de acesso. Muitos websites restringem o conceito a aparelhos com telas de diversos tamanhos, mas o conceito é muito mais abrangente.

Mesmo assim irei restringir os primeiros exemplos a dispositivos que tenham telas e que estão mais presentes atualmente. Não irei me estender muito a meios de acesso como leitores de tela, robôs de busca ou outros dispositivos.

O problema de entregar conteúdo em diversos formatos

Para fazer um website que seja acessível por qualquer dispositivo você geralmente tenta detectar o aparelho que o usuário está utilizando. Se for um desktop ou um notebook, você redireciona o acesso para um código CSS que formata seu site para o design mais confortável em grandes monitores. Se você detectar que o usuário está utilizando um dispositivo móvel, você o redireciona para uma versão que formatará o site para um formato compatível para este dispositivo.
Essa ideia é simples e foi efetiva por algum tempo quando utilizávamos Media Types do CSS.
Com o advento dos novos aparelhos como tablets, smartphones e até mesmo as televisões LED e LCD, essa técnica se tornou muito obsoleta.
Entenda porque: os media types detectavam algumas características dos meios de acesso, por exemplo o valor handheld filtrava aparelhos com telas de tamanho pequeno e conexão com a internet limitada. O valor screen, filtrava aparelhos com telas coloridas, normalmente terminais com monitores.
Entende porque estas características estão obsoletas ou se confundem com a quantidade de aparelhos existentes? Hoje 100% dos smartphones suportam resoluções de tela maiores e com acesso a um número ilimitado de cores que os monitores antigos. Quase nenhum celular tem telas pequenas e conexão limitada com a internet. Logo, estes parâmetros ficaram totalmente inúteis.

Para termos uma ideia melhor, a tela do iPhone e do iPad suportam resoluções muito maiores do que os monitores antigos. Lembro que utilizava em meu antigo monitor de 13” resolução de 800×600. A resolução do iPad é de 1024×768 com 132ppp. Meu monitor de 13” até chegava nessa resolução, mas daquele jeito porco. Até o iPhone tem uma resolução melhor: 960×640.

Agora entenda a regra primordial, que deve guiar todo o planejamento de design para diversos dispositivos: O que importa é a resolução e não o tamanho da tela.

Sabendo dessa regra, entenda que você não faz um layout para um determinado tipo de dispositivo, mas para aparelhos que tem uma determinada resolução. Um exemplo clássico é o site do Itaú. Eles tem uma equipe sensacional e muito pioneira. Eu consigo acessar perfeitamente o bankline por disversos dispositivos. Mas há um problema. Troquei meu smartphone Android recentemente por um Windows Phone. Eles tem as mesmas características. Mas quando entrei no bankline do Itaú, curiosamente fui redirecionado para a versão WAP do bankline. Com um bom desenvolvedor que sou, não me conformei e peguei emprestado o iPhone da minha mulher, copiei o endereço que o site redireciona os usuários do iPhone e o utilizei no meu Windows Phone. Voilá! Mesma interface, mesma usabilidade, mesmo design.
Eles detectaram o tipo de aparelho e não as características do aparelho.

Para nos ajudar a detectar as características dos aparelhos, bem como a resolução, utilizamos as Media Queries em detrimento aos Media Types.

Media Queries

Media Queries é a utilização de Media Types com uma ou mais expressões envolvendo características de uma media para definir formatações para diversos dispositivos.

Em Media Types há um valor chamado SCREEN, como já vimos anteriormente. Este valor é utilizado quando queremos direcionar uma determinada formatação para aparelhos que tem telas coloridas. Bom, telas coloridas é algo muito genérico, qualquer coisa hoje em dia tem telas coloridas. É aí que as Media Queries nos ajudam: além de identificar aparelhos com telas coloridas, você consegue definir um range de tamanho de tela para que aquele CSS possa ser ativado.
Veja um código de exemplo abaixo:

Você já deve ter percebido o porque do QUERIES no nome. Você cria queries no valor do atributo media o elemento LINK.
Neste exemplo, estamos capturando terminais com montiores e coloridos. Você pode capturar outros terminais com alguma saída visual, mas pode ser que o usuário esteja utilizando algum aparelho com saída de monitor monocromático, por isso temos que especificar o COLOR no valor.

Outro exemplo, onde restringimos a largura máxima da tela:

Aqui estamos direcionando o código CSS para aparelhos que tenham uma largura máxima de tela de 480px. Ou seja, qualquer aparelho que tenha essa largura de tela, deverá utilizar o código CSS que está no arquivo especificado.

É aqui que a diversão começa: com essas queries você define uma série de ranges de larguras de tela, separando uma versão de CSS para cada grupo de aparelhos que se enquadradam nestas descrições. Você faz um formato para grandes telas, outro para telas de tablets e outro para telas de smartphones.

E lá vem uma pergunta para você: as telas dos Tablets hoje em dia utilizando uma resolução de 1024×768. Muitos usuários utilizam esta mesma resolução de tela em seus computadores, com monitores maiores que as tablets. Como faz?

Entenda: se você criou uma versão adaptável, confortável para resoluções de 1024×768, pensando em tablets, será que essa mesma versão não seria confortável para monitores com essa resolução? E vice-versa. Se você definiu que a versão desktop será carregada a partir de uma largura de tela de 1000px. As tablets também verão essa versão. Lembre-se o que realmente importa é o tamanho da tela dos aparelhos, não o aparelho em si. Quando você especifica o aparelho, você limita os usuários, quando você específica a resolução, você amplia o número possíveis de visitantes.

Além do mais, vendo estatísticas por aí, a resolução de 1024×768 está decaindo muito rápido. Com as novas TVs e novos monitores, as resoluções de tela tem aumentado bastante, levando todos a um novo patamar.
O que nos leva ao próximo assunto.

Outras decisões de interface

O primeiro passo foi identificar os aparelhos e usuários que utilizam determinadas resoluções para conseguirmos entregar um CSS específico.
O segundo passo é fazer com que o layout seja amigável. Para isso você precisa entender os dilemas dos seus layouts e resolvê-los sem que o design mude da água para o vinho, mantendo as mesmas características e histórias de uso. Para tanto você precisa estudar e aplicar algumas premissas em seu website. Vou mostrar alguns pontos aqui, mas cada projeto terá uma abordagem diferente.

Layout fluido

Layouts fluidos estão sendo utilizados desde os primórdios, mesmo assim de uma forma muito restrita porque dependendo do tamanho do site são bem difíceis de planejar. Veja o site da Amazon, ele ocupa todo o espaço do navegador e seu tamanho é adequado até uma determinada largura de tela.

O A List a Part tem um exemplo ótimo, por isso não vou fazê-lo perder tempo vendo outro exemplo. Veja este layout com a tela maximizada e vá diminuindo a janela do seu browser e veja os efeitos.

Perceba ele se encaixa em qualquer tipo de tela. Dessa forma você entregou uma boa experiência de design para todos os públicos. Este é um ótimo exemplo para entender exatamente o que é Responsive Web Design.
Quer outro ótimo exemplo? Neste caso o designer mostra uma mensagem para o usuário, o alertando de que o site é melhor visualizado em grandes resoluções.

Adaptando menus

Menus de websites são indispensáveis. É por lá que o usuário descobre todos os segredos do seu website, por onde ele se apaixona ou se perde. O menu é um dos principais elementos do seu website. É muito comum que usemos menus na horizontal. E como você sabe, menus na horizontal não são quase impossíveis em telas pequenas como as dos smarphones. Ainda mais se você tiver uma grande quantidade de opções. Logo, você precisa adaptar se menu para que ele continue usável e ao mesmo tempo não ocupe tanto espaço na tela.

Há diversos caminhos que você pode tomar: você pode transformar o menu em um selectbox (ou combobox, como preferir), sumir com alguns ítens que podem não ser interessantes para usuários de mobiles ou reformatar seu design para que ele caixa de forma funcional em telas pequenas.

Veja alguns exemplos abaixo. Entre no site e diminua a janela do browser para ver os efeitos. Se preferir ver na vida real, visite o site pelo seu smartphone:

• http://www.highwayhurricanes.com/
• http://www.citychoir.org.uk/
• http://leica-explorer.com/

Diminuindo ou trocando imagens

Não se preocupe se seu website trabalha utilizando grandes imagens, você trocar ou diminuir as imagens para que caibam em telas menores. Veja os exemplos abaixo:

• http://www.ciscolondon2012.com/
• http://www.cujo.jp/
• http://spartanrobotics.org/
• http://1pictureaday.com/

Media Queries – A Collection of sites using media queries

Todos os exemplos de website que mostrei acima, retirei deste website. A ideia é genial!
O http://mediaqueri.es/ tem uma coleção impressionante de websites que utilizam de forma responsável as Media Queries. Veja os exemplos e entenda como você pode fazer um website adaptável para diversos cenários de uso.

Cada meio de acesso tem sua característica

Conversamos bastante sobre o problema das resoluções e larguras de tela. Mas no começo deste post eu disse que o Responsive Web Design pode ir muito além das telas e Media Queries. Há usuários podem visitar seu site e não utilizar uma tela, tablet ou smartphone. Em vez de ler as informações ele pode ouvi-las, como é o caso dos usuários de leitores de tela.

CSS Aural

Quero que você abra sua mente e entenda que mesmo você não tenho deficiencia visual, você pode ser um grande candidato a utilizar leitores de tela. Enganam-se aqueles que acham que programas que leem a tela só podem ser usados por pessoas com problemas de visão. E se você estiver dirigindo ou em qualquer outra situação em que não pode ficar o tempo inteiro com o celular na mão, mas mesmo assim quer ler um determinado artigo, site etc, como você faz? Nunca pensou em ouvir o artigo? Pois é.

Eu sei que os sistemas de leitura de tela hoje em dia precisam de uma repaginada total. Mas empresas como Apple e Microsoft já estão fazendo isso para que seus sistemas mobiles e para desktops tenham a habilidade de ler bem as telas dos dispositivos. Isso é impressionante.

Se a informação vai ser consumida dessa forma ela precisa ser formatada também. Isso mesmo, formataremos o áudio! Como? Com CSS Aural.

O CSS Aural praticamente controla como o audio do leitor de tela irá se comportar. Você pode controlar volume, tipo da voz, qual caixa a voz sairá etc.
Imagine que você tenha um artigo sobre uma entrevista, onde há o entrevistador e o entrevistado. Você pode: especificar que a voz do entrevistador sairá na caixa da esquerda e a do entrevistado na caixa de som da direita. Que a voz do entrevistador será masculina e que voz do entrevistador será feminina.
Sensacional, não é?

Especificação Touchscreen

Já falei sobre a Específicação Touchscreen, abaixo segue um resumo, mas sugiro que você leia o artigo completo.

Estamos acostumados com a experiência de interação com a ajuda do mouse. Isso foi desde os primórdios e provavelmente ainda será por bastante tempo. Nós desenhamos interfaces para ações baseadas no mouse ou qualquer aparelho que controle a setinha da sua tela. Criar interfaces touch é algo relativamente novo. Nós trouxemos ideias da interação com mouse para os dispositivos touch, mas grande parte das interações precisaram ser reinventadas porque o modo, o ato, a forma de interagir com a informação é diferente. Na interface touch você não “coloca o mouse” em cima do elemento. Você não utiliza teclas de atalho para executar ações. Normalmente as ações importantes estão expostas na interface, facilitando o acesso rápido. Isso é muito importante porque nos ensina criar interfaces mais intuitivas, com a curva de aprendizado menor.

Há também o outro lado da moeda, onde detalhes das interfaces touch não podem ser portadas para interfaces baseadas em mouse. Lembre agora na forma de como você gira uma imagem em um dispositivo touch e como você gira essa mesma imagem utilizando um mouse. A interface muda, o seu comportamento muda.

Sabendo dessas limitações você deve entender que não podemos simplesmente portar o visual de um determinado site para um dispositivo touch. Você pode dizer que “hoje fazemos isso e até agora está funcionando muito bem”. Mas pense melhor… a grande maioria dos sites que você visita hoje no iPad ou qualquer outro tablet, por exemplo, são sites onde a sua interação é limitada. O que você faz em um site hoje em dia? Clica nos links e lê. Salvo às vezes quando você visita um site mais “animadinho” com mais ações para entreter o usuário. Mas e se você faz um site onde é preciso rotacionar uma imagem ou fazer um ZOOM? Você precisará manter as mesmas ações nos dois cenários. E como antigamente, para manter o cenário das interfaces touch você precisa da ajuda de muito script.

Concluindo

Responsive Web Design é um assunto muito extenso mas muito interessante. Nos faz pensar no futuro de forma diferente. Até 5 anos atrás não tínhamos preocupações com outro dispositivo a não ser um ou outro smartphone e os desktops. Hoje temos diversos aparelhos, com diversas limitações de tela, tamanhos, comportamentos… E isso não vai parar por aí. Todos os dias aparecerão mais e mais aparelhos e dispositivos que ajudarão os usuários a terem acesso a qualquer informação. É importante que nós possibilitemos que essas informações sejam entregues da melhor maneira possível.

Algumas referências que você pode querer dar uma olhada:

• Responsive Web Design
• Guidelines for Responsive Web Design
• Designing for a Responsive Web with Heuristic Methods
• The Big Web Show sobre Responsive Web Design

Posts Relacionados

• Mobile First – A arte de pensar com foco
• Especificação para touch screens
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• Experiência cross-device

Entender realmente como um navegador funciona é importante, e garante seu entendimento do real dos problemas que está enfrentando no código que está implementando. Tem mais! Criar um código que manipula o layout (leia-se DOM) fica mais fácil, é uma relação win-win.

Criado pelo W3C, O DOM é uma multi-plataforma que representa como as marcações em HTML, XHTML e XML são organizadas e lidas pelo navegador que você usa. Uma vez indexadas, estas marcações se transformam em elementos de uma árvore que você pode manipular via API – que é o que fazemos quando usamos programas ou scripts para alterar funcionalidades de uma página: conteudo, estrutura ou folha de estilo.

Um pouco de história

Não tem graça falar sobre o assunto sem mostrar como ele surgiu. Isso só reforça ainda mais a importância de conhecermos bem o assunto pois mostra sua relevância (e porque falar de browser wars é bem legal, apesar de evidenciar os cabelos brancos).

Netscape e Microsoft guerreavam com Netscape 2 e IE3.0 lá em 1996 e enquanto a Netscape lançava o Javascript a Microsoft lançava o JScript. A diferença entre um e outro não é nada mais além do nome – acredite! Por razões comerciais devido as “sangrentas” browser wars as empresas decidiram adotar nomes diferentes para a mesma coisa – que na verdade era (e continua sendo) o ECMAScript, a linguagem que comecou a ser criada em 1994 quando o W3C colocou na mesma mesa as duas empresas e várias outras para desenvolver um padrão para linguagens de script para os navegadores. Javascript, JScript e ActionScript não são nada mais que dialetos de ECMAScript.

O DOM em sua forma e como é reconhecido pelos navegadores

Representação de um documento HTML e sua árvore DOM

A figura acima mostra a estrutura de uma árvore DOM, a linearização  das marcações de modo que ela possa ser montada inicialmente por um navegador. Esta estrutura não será o que veremos no navegador – o layout em si. O DOM é a base para uma outra árvore que é o que realmente um browser monta na tela, a Árvore de Renderização - aka Render Tree.

A base para todos os nós da árvore DOM é o base class chamado Node.h. Ele possui várias categorias, e as relevantes para renderizarmos código no navegador são os nós de documentos, elementos e texto.

1. Documentos é o nó mais importante do DOM, com três classes diferentes: Document, que é usado por todos os documentos XML e outros que não sejam SVG (que também é um XML, porém com marcação já padronizada), HTMLDocument que como o nome diz, cuida de documentos HTML e SVGDocument, responsável pelos documentos SVG e tambem por outros documentos herdados da classe Document (Como o Document.h e o HTMLDocument.h).
2. Elementos são todas as tags que estão em arquivos HTML ou XML se transformam em elementos da árvore DOM. Considerando a renderização do navegador, um elemento é um nó com uma tag que pode ser usada para fazer subclasses específicas que podem ser processadas de acordo com as necessidades da Render Tree (Element.h).
3. Texto: É o texto que vai entre os elementos. Todo o conteúdo das tags (<p>Isto é um text node</p>). O nó de Texto guarda basicamente texto puro, que pode ser renderizado ou trabalhado via script.

A Render Tree

Como a render tree é montada

A Render Tree é a parte mais importante do processo de renderização. Bem parecida com a árvore DOM, cada objeto corresponde a nós de Documentos, Elementos ou Texto. A diferença é que q Render Tree possui tambem objetos que não possuem nós na árvore DOM, como scripts e folhas de estilos.

O processo de criação da Render Tree passa pelos seguintes passos:

1. Attachment: Após finalizar o parse do DOM e a criação de seus nós, os navegadores chamam um método chamado attach para começar a renderização. O attach adiciona primeiramente as folhas de estilo a árvore DOM e começa a estilização da página. Um bom exemplo é o uso das propriedades CSS display x visibility: Caso um elemento da árvore DOM tenha uma propriedade display:none, este elemento (e seus nós filhos) não será criado na Render Tree. Ao contrário do uso de visibility:hidden, que vai renderizar o elemento na árvore, porém  ele irá remover (ou adicionar quando visibility:visible) via Repaint as cores (ou propriedades) que formam este elemento. Vale lembrar também que este processo de attach é top down, criando sempre inicialmente os nós parent e depois seus descendentes (nós filhos). (Para saber mais sobre Repaint e Reflows, veja este outro artigo)
2. RenderStyle.h: Durante o processo de attach um método é criado, o RenderStyle.h que vai guardar objetos de referência com cada uma das propriedades CSS do documento. O nó criado no DOM é verificado no documento de CSS e caso existam propriedades que incidam naquele elemento, ela é aplicada. Esta propriedade fica salva dentro da Render Tree até que ela seja destruída ou que este valor seja alterado por algum script.
3. CSS Box Model: Após o método RenderStyle ser criado, ele é acessado via RenderObject. O Box model é usado para posicionar um elemento dentro da página, oferecendo suporte para o conteúdo, padding, bordas e margens que envolvem este elemento

Destruindo (ou atualizando) a Render Tree

A Render Tree é destruída quando nós da árvore DOM são removidos, causando a necessidade de um novo parse no DOM, ou quando uma tab do navegador com a árvore DOM usada é fechada. Após o refresh da árvore DOM, todo o processo acima é refeito, com attach chamando o RenderStyle, que montado chama o método style() do RenderObject que acessa o CSS BOX model.

Como os navegadores interpretam todos estes elementos criados por DOM e Render Tree antes de aplicar o estilo?

Todo navegador tem uma lista de elementos HTML suportados. Quando o seu markup possui tags presentes na lista, a árvore DOM é montada e o processo de attachment começa logo na sequência e os estilos são aplicados, dando continuidade a criação da Render tree.

O grande problema é que cada navegador tem a sua própria lista, que trata situações similares de maneiras diferentes. Obviamente já sabemos que o navegador que mais apresenta problemas para as situações acima é o Internet Explorer, mas acredite, todos os navegadores apresentam problemas quando um elemento não está em sua lista de elementos permitidos, e precisa de um trabalho para fazer tudo acontecer na Render Tree como deve ser feito.

Elementos fora desta lista são tratados como Elementos desconhecidos. E eles são uma grande fonte de problemas:

1. Como estilizar este elemento?Por exemplo, a tag <p> tem por padrão espacamento no topo e bottom, <blockquote> possui uma indentação automática adicionando uma margem à esquerda ou <h1> tem uma fonte maior que o <p> por ser um cabeçalho. Tudo isso esta padronizado, mas como cuidar de algo que não existe?
2. Como este elemento deve aparecer na árvore DOM?Os navegadores também possuem uma lista que mostra quais elementos podem ser filhos de outros elementos. Por exemplo, se você adiciona por engano no seu markup <p><p> o segundo paragrafo implicitamente fechará o primeiro <p>, fazendo que os dois elementos sejam irmãos (no mesmo nível na árvore DOM) e nao como nós filhos como de maneira linear pode parecer. Porém se vc adiciona um <p><span>, este paragrafo inicial não será fechado, porque o navegador permite que <span> seja filho de elementos de paragrafo, fazendo assim o <span> ser nó filho de <p>

Para elementos desconhecidos, a ideia é não estilizar. Caso queira algum estilo em elementos desconhecidos, você deve colocá-lo no nó acima (se necessário um wrapper), para fazer com que ele herde o estilo.

Perceba a sutileza de como isso funciona. Os dois diagramas mostram uma árvore DOM, montada por um navegador suporte HTML5 nativo e o Internet Explorer 8 (navegadores que não suportam HTML5 tem funcionamento semelhante):

Arvore DOM com suporte HTML5

Arvore DOM IE e outros navegadores sem suporte HTML5

É por essas e outras que a gente usa o modernizr, o HTML5shiv ou um simples document.create(“SECTION”) / document.create(“ARTICLE”). E é isso que acontece quando navegadores interpretam elementos desconhecidos. Eles desconsideram o nó real aonde o elemento está, e o reconhece como filho de <BODY>. E por favor, sem trocadilhos com o filho dos outros.

Ver como uma árvore DOM é montada  e como a Render tree é feita nos dá idéia do quão importante é ter um documento semântico. Realmente semântico. Uma vez entendidos os conceitos, a manipulação e a programação dos elementos fica mais fácil.

E você começa a entender como os navegadores funcionam.

Referências

Entendendo os Reflows por Alysson Franklin

Modernizr para suporte HTML5

HTML5shiv para suporte HTML5

Browser Wars pela Wikipedia

ECMAScript pela Wikipedia

Javascript pela Wikipedia

JScript pela Wikipedia

CSS Box model pelo W3C

DOM pela wikipedia 

Renderização no webkit, o básico pela webkit

W3C Overview do DOM

Declaração de atividades do DOM pelo W3C

Uma discussão sobre como Navegadores entendem elementos desconhecidos por Mark Pilgrim  

Traversing the DOM by Mike West

Progressive enhancement demystified by Aaron Gustafson

DOM, HTML5, CSS3 e Performance – Slides por Paul Irish

E também o @mariocaixa, esse cara tem o DOM!

Posts Relacionados

• Entendendo os Reflows
• Conteúdo, Flash e HTML
• Ah, o maravilhoso mundo real
• Agora é a vez dos desenvolvedores
• WebIntents – Framework para WebApps

Além de ser muito difícil de manter uma coleção de cores com seus nomes esquisitos, é quase impossível você criar um website tentando se adequar a quantidade limitada de cores disponíveis. Já tínhamos problemas sufientes com a quantidade limitada de fonts que poderíamos utilizar. Isso não poderia acontecer com as cores também. Com esse problemas vários padrões matemáticos foram estabelecidos para que criássemos as cores que gostaríamos de utilizar. Vou falar de dois padrões aqui: RGB e HSL. Vou ligá-los ao desenvolvimento web e não de uma forma geral. Caso contrário o artigo seria mais longo e envolveríamos outros assuntos mais extensos.

Você já deve ter lido algo sobre utilizar para web cores no formato RGB. Esse formato está ficando mais popular com o CSS3 por que agora podemos controlar o canal alpha, tendo uma combinação nova chamada RGBA. Há também outro formato que ganhou alguma atenção do workgroup no W3C que é o formato de cor chamado HSL. Como o RGB, o HSL também ganhou um canal de opacidade, ficando HSLA. Muitos desenvolvedores ainda tem dúvidas sobre as diferenças entre RGBA e HSLA e qual utilizar.

Tudo é muito simples de entender. RGB e HSL são dois formatos de composição de cores digitais. Você pode escolher qual dos dois utilizar, vai do seu gosto. Contudo como até hoje utilizamos o HEXADECIMAL como padrão de cores para web, minha sugestão é esperar para ver qual das duas específicações cairá no gosto do mercado para escolher um dos formatos para utilizá-la mais frenquentemente nos projetos. Entretanto os dois formatos tem flexibilidades diferentes e por isso pode ser muito difícil apenas uma delas se tornar mais popular que outra.

Abaixo vou introduzir brevemente as diferenças entre o formato HSL e RGB para que você entenda quais suas características.

O RGB

O processo é simples: como na vida real onde você mistura cores para obter uma outra cor como resultado, você faz a mesma coisa com o RGB: você mistura as cores para obter uma outra cor como resultado. Para tanto você utilizará a soma de 3 valores: Red, Green e Blue: rgba(red, green, blue);

Veja a sintaxe abaixo para entender melhor a aplicação:

Os três valores são ligados às três principais respectivamente vermelha, verde e azul. No caso acima inseri 100% de cor para Vermelho e Verde. Como bom aluno de educação artística, você deve saber que misturando vermelho e verde a cor resultante será amarelo.

Você pode ser mais específico controlando até mesmo a fração da porcentagem, por exemplo:

Assim você consegue exatamente a cor que precisa. Esse formato de porcentagem e controle de fração também é aplicado ao HSL.

O RGB pode ser configurado utilizando valores hexadecimais. A conta não é simples e você precisa ser um pouco nerd para entender. A explicação é meio longa. Sugiro que você leia no Wikipedia algo mais detalista.

O HSL

O HSL funciona um pouco diferente. A sintaxe é como abaixo:

A escolha de cores no HSL não é baseado na mistura mas sim em um esquema baseado em um cilindro. O primeiro número de valor na sintaxe é onde escolhemos a cor. Começamos no topo com vermelho, onde o valor é 0, e damos uma volta de 360 graus, retornando novamente no topo, na cor vermelha. Conforme aumentamos o valor vamos selecionando as cores. Por exemplo, se selecionarmos um valor por volta de 120 obtemos um verde.

Veja a imagem abaixo para entender melhor:

Embora possamos escolher qualquer cor misturando as cores com o RGB, é muito mais instintivo escolhermos uma cor específica e modificarmos sua luminosidade. Escolhemos o azul e modificamos sua luminosidade para obtermos o tom que você deseja.

Para escolhermos a luminosidade e a saturação da cor modificamos os dois outros valores, o segundo valor é a luminosidade e o terceiro valor é a saturação ou a quantidade de cinza que você colocará na cor. Modificar a saturação é como se você mudasse a quantidade de cor. Quanto menos cor, mais cinza. Se você quiser uma cor mais suja, mais apagada, você diminui este valor. Caso contrário você a mantém como 100% e utiliza a quantidade integral da cor. Normalmente esse será o padrão.

E o hexadecimal?

O hexadecimal, queridinho dos nossos corações, sempre estará ao nosso lado. A sintaxe é muito mais curta que as outras duas específicações. Não temos todas as vantagens que as outras especificações nos dão, começando pelo canal alpha. Com a grande maioria dos programas visuais dando suporte ao formato hexadecimal ele ainda perdurará durante muito tempo ainda em nossas vidas.

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• Experiência deve ter começo, meio e fim
• CSS3 – Módulo Template Layout
• ePub: Aprenda a criar um livro digital
• OOCSS ou CSS do jeito certo