Com a crescente popularização de tablets e leitores digitais não há dúvida de que os livros eletrônicos vieram para ficar. O formato ePub vem cada vez mais se consolidando como o padrão definitivo para eBooks. As editoras procuram profissionais especializados, mas, aqui no Brasil não existem muitos que de fato possuem o know-how necessário para desenvolver livros no padrão. Na verdade o que acontece é que as editoras estão alocando o tipo de profissional errado para a função. Um diagramador padrão, acostumado com editoração impressa via softwares visuais como Indesign vai ter problemas ao tentar lidar com linhas de código. Já um desenvolvedor front-end vai se sentir em casa já que criar e editar um livro digital é basicamente lidar com XHTML e folhas de estilo em CSS. Neste artigo vou comentar sobre as vantagens (e desvantagens) deste padrão e como com algumas poucas dicas você poderá editar um livro digital.

Por que não usar PDF?

O PDF tem muitas vantagens. Até a sua tia que te liga toda semana para perguntar de novo como faz para ler o resultado da Megasena na internet sabe como abrir um PDF. E do ponto de vista do design é ótimo. Hey, você tem muito mais controle do layout! Você pode colocar imagens e textos como quiser sem se preocupar com nada. Exceto… Você já tentou ler um PDF em um smartphone? É simplesmente agonizante. É necessário dar zoom in e out a cada frase diferente. Ou tentar ler tudo em um tamanho de letra absurdamente pequeno…

Isto acontece por que o PDF é baseado no suporte físico de uma folha, o que simplesmente não faz sentido no mundo digital. Vou explicar: um artista que pretende pintar uma nova obra de arte precisa saber o tamanho da tela. Da mesma maneira, ao editar um livro, ou qualquer outro tipo de documento para a impressão, é necessário saber o tamanho da folha para aí então fazermos toda a diagramação. O problema é que em um ambiente digital não existe uma folha. Existe um viewport (ou seja, área de visualização) que pode ser, bem, do tamanho que o usuário quiser! Se ele for ler o seu livro no browser pode aumentar e diminuir o tamanho da janela até a resolução máxima do monitor. Ou pode optar por ler em um tablet, smartphone, eReader… Enfim, a questão é que não temos como determinar a medida de altura e largura da mesma maneira que fazíamos com o papel. E o PDF, como foi pensado para ser impresso, precisa desta medida fixa.

Sobre o ePub

ePub é abreviação de Eletronic Publication, ou seja, Publicação Eletrônica. É um formato de livro aberto e gratuito criado pelo IDPF, um fórum internacional de publicação digital. Os livros deste formato são fluidos, o que permite que a experiência de leitura seja legal em qualquer tamanho da tela, sistema operacional ou dispositivo que você escolher. Desde que você tenha um app para isto, é claro. Mas isto não é muita preocupação. Existem leitores gratuitos para quase todos os aparelhos e sistemas operacionais (se você não conhece nenhum dê uma olhadinha no final do texto). Outro aspecto bacana do ePub é o controle que ele dá ao usuário. É possível realizar buscas, navegar através de links, aumentar e diminuir o tamanho da letra, trocar as fontes, a paleta de cores, etc. Sim, isto significa que se o cara quiser ler o livro inteiro em Comics Sans ele pode! Mas se isto deixar o usuário feliz quem somos nós para dizer não?

Como editar

Bem, agora que você já sabe como ler e por que usar, vamos descobrir como é um livro digital por dentro! Criei um livro de exemplo para utilizar neste tutorial. Você pode baixa-lo aqui. Mas qualquer outro livro que você tiver neste formato vai servir para o nosso experimento.

A extensão ePub é um formato de livros compactado. Faça um teste: renomeie o arquivo deste tutorial de meulivro.epub para meulivro.zip ou meulivro.rar que você poderá ver o conteúdo do pacote. No entanto, uma coisa importante de se ter em mente é que não são todos os softwares editores que estão preparados para salvar neste formato. Até dá para ler os arquivos XHTML separados, mas você teria que abrir manualmente, editar e recompactar a cada mudança de volta para ePub o que não seria nada prático. Felizmente existem alguns softwares como Sigil que são específicos para a edição de código de ePubs. Eles não tem um visual muito bonito mas cumprem com a função direitinho. Bem, vamos explorar os arquivos…

Obs. Existem outras especificações opcionais, mas vou me manter dentro do fundamental.
Obs.2 Os nomes dos arquivos são case sensitive.

A Estrutura

Vamos voltar ao nosso ePub! Ao descompactar a pasta você vai ter o seguinte:

arquivo mimetype
pasta META-INF

• container.xml

pasta OEBPS

• content.opf
• toc.ncx
• style.css
• titulo.html
• capitulo1.html
• capitulo2.html

Para que serve tudo isso e como eu crio sozinho?

Mimetype

A função do mimetype é informar ao sistema operacional qual é o tipo do arquivo. O mimetype é um simples arquivo de texto ASCII.  Para criar um mimetype basta abrir qualquer editor (ou até mesmo o bloco de notas) e escrever esta linha de código:

Salve como mimetype (sem nenhuma extensão) e pronto. Está feito! O mimetype é igual para qualquer ePub. Então copiar de um outro ePub da certo também.

Container.xml

Deve ficar dentro da pasta  META-INF. A função deste arquivo é agregar todos os outros. Bora criar um!

Content.opf

Descreve o conteúdo de todos os arquivos. Apesar da extensão esquisita é só criar um xml e depois salvar como .opf É composto das seguintes partes: metadata, manifest e spine. O esqueleto dele é assim:

Metadata

Não tem muito segredo aqui. São as informações do seu livro.

Itens obrigatórios:

• title - O título do seu livro.
• language - A Lingua utilizada. Como o livro está em português eu escolhi pt-br.
• identifier - Um código único para o seu livro. Pode ser o ISBN, por exemplo.

Itens opcionais:

• creator – O criador. No caso, você.
• contributor – Contribuidor
• publisher - Editora
• subject - Assunto
• description – Descrição do livro
• date - Data
• type - Tipo
• format – Formato
• source – Fonte
• relation – Relação
• coverage – Cobertura
• rights – O tipo de licença. Creative Commons, por exemplo.

Bem, vamos preencher nossas metadatas. Eu inseri o seguinte entre as tags package:

Manifest

É um manifesto mesmo. Deve conter (em qualquer ordem) a lista de todos os arquivos da sua publicação. Exceto mimetype, container.xml e content.opf É necessário especificar uma ID única para cada arquivo. Você pode nserir estas informações antes ou depois da metadata. O importante é que esteja também dentro da tag package. No caso do nosso livro-tutorial ficou assim:

Spine

A espinha do livro, ou seja, a ordem de leitura. Aqui você deve colocar apenas os arquivos tipo HTML na ordem que você deseja que apareça no livro, chamando cada um pelo ID que você definiu no manifesto. Tome cuidado para não duplicar nenhum arquivo ou ID. Como você já adivinhou, deve ser inserido entre as tags package também.

toc.ncx

TOC é uma sigla para Table of Contents, ou seja, o indice do livro. Também é um arquivo xml salvo com a terminação .ncx Possui a seguinte estrutura:

#head

• uid — o identificador único em content.opf
• depth — níveis do sumário >= 1
• totalPageCount — to 0
• maxPageNumber — to 0

#navMap

O sumário em si

#navPoint

• id — único do arquivo
• playOrder —ordem de navegação (iniciando em 1)

O nosso índice ficou assim então:

Os capítulos

É aqui que entra o livro em si. Cada capitulo deve ficar em um HTML separado. Estes arquivos não são nada diferentes de HTMLs comuns:

Outros tipos de arquivos:

CSS – Uma folha de estilos normal.
Pasta images – Aqui devem ficar as imagens do livro. Formatos permitidos: jpeg, png, gif e svg+xml
Pasta fonts – Utilize esta pasta se você quiser embedar algum arquivo de fonte no seu documento. Lembre-se de utilizar sempre o formato Open Type pois alguns aplicativos de leitura não suportam True Type.

E agora basta compactar!

Selecione todos os arquivos e crie um arquivo compactado (pode ser .zip ou .rar). Depois é só renomear para .epub e ler no seu dispositivo favorito. Pronto! Você tem um livro digital!

Dicas importantes para editar um ePub

Semântica é sua amiga

Bem, se você é leitor do Tableless provavelmente não preciso dizer isso, mas vou dizer mesmo assim! É muito importante utilizar uma estrutura semântica aqui. Tags h1 a h6 para títulos, p para parágrafos… O que você já está mais do que cansado de saber a esta altura. Evite usar br para quebrar a linhas por que sem ter o tamanho de um container é difícil determinar quando de fato vai ser necessário quebrar a linha.

Evite seletores complexos

Leitores digitais não são tão sofisticados quanto browsers. Mantenha o seu CSS o mais simples possível.

Use tamanhos relativos

Como as “páginas” do seu livro vão aumentar e diminuir de acordo com o tamanho da tela do dispositivo não utilize pixels como medida para nada. Lembre-se: EM para texto e margens, porcentagens para figura. Isto vai garantir que o seu livro continue proporcional e escalável. E o seu leitor feliz!

Tamanho é Documento

Não use apenas um documento XHTML para o livro todo. A recomendação é que os capítulos tenham menos de 300k cada. Mais do que isto pode deixar alguns leitores, como o iBooks por exemplo, muito lentos! A razão é que estes apps consideram cada capítulo como um bloco de texto diferente. Se você colocar tudo em um documento só o aplicativo vai carregar tudo de uma vez a cada acesso.

Outra dica é tentar usar sempre imagens otimizadas para a web e com uma resolução não maior do que 1200 x 1600px.

Não pire muito na escolha de fontes

Evite usar fontes fora do padrão websafe. Você pode embedar fontes Open Type utilizando a propriedade @font-face mas isto não significa que voce deve. Para começar não são todos os leitores que aceitam isto e no final o seu arquivo pode ficar pesado demais e travar. E muitas vezes pode ser um trabalho extra inútil já que o seu usuário pode muito facilmente trocar de fonte. Se mesmo assim você quiser usar não escolha mais do que dois ou três tipos.

Edição visual

Sim. Existem alguns softwares que podem gerar o livro para você. O Adobe InDesign faz isto, o Pages do Mac… Mas falando sério: não vale a pena. O código vai ficar sujo e no final você vai ter que corrigir vários bugs. É como se você estivesse utilizando um editor “What you see is what you get” para fazer um site. Acho que vocês entendem o drama. Mas… se você for realmente caminhar por esta estrada escura tenha algumas coisas em mente:

• Se você está acostumado com editoração nestes programas é preciso mudar alguns paradigmas. Esqueça páginas mestras, hifenização, numeração, pé de página… você não precisa se preocupar mais com estas coisas em um formato digital.
• Crie estilos específicos para o que é título, parágrafo, etc e não esqueça de importa-los na hora de salvar o arquivo.
• Cuidado ao gerar o TOC (table of contents, ou seja, o índice). Se você colocar mais de dois subniveis pode dar problemas de compatibilidade com alguns programas e o seu livro simplesmente não abrir.
• Lembre-se que todas as imagens precisam estar ancoradas para que fluam juntamente com o texto.
• Determine quebras de capítulos. No caso do InDesign, salve cada parte do livro em um arquivo diferente. Depois junte todos os arquivos em um formato “book”.

E quanto ao formato iBook da Apple?

A Apple lançou recentemente um software gratuito chamado iBooks Autor para a criação visual de livros digitais. Os livros no formato iBook são bem interativos, permitindo a implementação de elementos multimidia como videos (coisa que ainda está engatinhando no formato ePub). Com um “pequeno” porém. Sem muito alarde nos termos de serviço a Apple colocou uma clausula de exclusividade para livros comerciais. Ou seja, se você utilizar o software e vender o seu livro através da iBook Store não poderá vender em mais nenhum lugar. Sem contar que o programa é exclusivo para Mac.

Fique longe dos conversores automáticos!

Existem alguns softwares ainda que prometem converter de PDF para ePub. Fique longe deles! Sério. Eles são ainda piores que os editores visuais. Um software não consegue interpretar um livro da mesma maneira que um ser humano a menos que você diga a ele o que fazer. Se você não determinar “ei, isto é um título” ele não tem como fazer este tipo de decisão por você.

Os PDFs estão presos a um tamanho fixo, lembra? O que significa que as palavras precisam ser hifenizadas. Se você converter automaticamente (além do seu código ser a coisa menos semântica desde os sites feitos em tabelas) os hífens vão continuar lá, criando divisões no me-io das pala-vras on-de não pre-cisava! Pense nos números das páginas… se o texto flui isso significa que um mesmo livro pode (e vai) ter uma numeração diferente de acordo com o aparelho utilizado. Mas no caso da conversão automática os números no pdf vão continuar lá. Os títulos provavelmente vão estar errados também. Fora que muitos deixam marcas como “convertido pelo programa XYZ” em todas as páginas do livro.

Links úteis

• IDPF - A organização responsável pela criação do ePub. O site deles é meio confuso, mas contém bastante informação a respeito do formato.
• ePub Chech – Validação de ePub
• Epub Format Construction Guide – Um meta-livro bem completo sobre o assunto.

Bibliotecas gratuitas

• Google Books
• ePub Bud

Aplicativos para a Leitura

Mac & PC

• Adobe Digital Editions
• Nook

Linux

• FB Reader

iOS

• iBooks
• Stanza

Android

• Aldiko

Leitura no Browser

• Magic Scroll - Google Chrome
• ePub Read – Firefox

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• Experiência deve ter começo, meio e fim
• Vote no Especialista em Usabilidade para Presidente
• O que são Media Types do CSS?
• Agora é a vez dos desenvolvedores

O artigo do Scott Jenson começa dizendo que a popularização dos smartphones são apenas o começo. Juntando o barateamento das peças para a produção destes aparelhos com a criação sistemas de baixo custo e acessíveis como o Android, não só estão surgindo dispositivos baratos capazes de fazer tarefas que antes eram possíveis apenas em computadores, mas dispositivos baratos baseados na web, trazendo uma experiência cross-device nunca antes experimentada. Um exemplo disso é quando utilizamos estes dispositivos integrados com aplicações como o sistema de som Sonos. O Scott Jenson chamada de Zombie Apocalypse dos eletrônicos.

O paradigma dos computadores desktops estão nos impedindo de enxergar novos caminhos não tão longes assim. Isso é totalmente evidente quando falamos sobre smartphones, no qual nós sabemos que não são computadores desktops e tão somente por isso nós temos outras experiências e outras abordargens quando estamos usando aparelhos deste tipo. Perceba que diversos serviços e aplicações estão sendo portados para os dispositivos móveis porque fazem mais sentido nesse meio. O Twitter mesmo foi criado inicialmente para publicações vindas apenas pelos smartphones. Foi um processo reverso.

Me lembro que aqui no Brasil o recebimento de SMS internacional era um problema em algumas operadoras. Muitos queriam utilizar o Twitter, mas não podiam atualizar suas timelines ou receber as atualizações dos seus colegas porque o Twitter, naquela época, era baseado em SMS. Foi aí que a plataforma se popularizou mais lá fora e então a possibilidade de atualizar sua timeline por outros meios surgiu.

Há uma frase interessantíssima no artigo de Scott Jenson onde ele diz assim:

This problem is simple, but pernicious: designers think of new technologies in terms of yesterday’s tasks, failing to clearly see the real potential of the new technologies.

Minha tradução livre: “O problema é simples mas pernicioso: os designers pensam nas novas tecnologias baseando-se nas tarefas de ontem, falhando em ver claramente o real potencial das novas tecnologias.”

Muito óbvio. É por isso que o Windows Mobile falhou! A Microsoft durante muito tempo liderou o mercado de sistemas para mobiles com um sistema ruim, bugado e muito, mas muito inútil, simplesmente porque eles eram praticamente os únicos. O problema com o sistema deles foi a tentiva de portar os conceitos, experiências, comportamentos e tarefas do sistema dos desktops para os mobiles. Claramente um grande erro. Com o Windows Phone eles mudaram (tarde) o cenário. Eles criaram o Windows Phone levando em consideração os atos e comportamentos do usuário em aparelhos deste tipo. Não há nenhuma analogia aos desktops. E mais uma vez, algo que foi criado primeiramente para aparelhos móveis será portado para os desktops, que é o caso da interface Metro levada para o Windows 8.

Os PCs de hoje serão apenas hubs num futuro próximo. No cenário de hoje você escolhe entre Mac ou PC e baixa aplicativos que muito provavelmente funcionarão apenas para um destes sistemas. O modelo ideal, que já é mais real do que imaginamos, é que cada pessoa possa usar múltiplos dispositivos acessando um mesmo dado, uma mesma informação, normalmente pela núvem.

O exemplo do serviço de música via streaming Pandora é perfeito. Ele permite que nós possamos utilizar seus serviços em uma variedade gigante de dispositivos. Sempre sincronizando suas músicas via internet. Tudo sempre integrado. Aqui no Brasil, como o Pandora não funciona, talvez não seja a sua realidade… Entretanto estamos vivendo em um mundo onde o software, a aplicação, o serviço, define qual aparelho você vai comprar.

O Sonos é um aparelho de som Wi-Fi. Além do Pandora você pode sincronizar sua biblioteca de músicas de diversos outros serviços como iTunes ou o Spotify. Quando o conheci eu o quis sem pensar. Nada de iPod ou iPhone plugado no aparelho de som. Nada de fio p2-p2 para ligar meu celular ao aparelho de som… Eu quero ouvir minhas músicas livremente pelo serviço que eu mais gosto no sistema de som da minha casa. Mas quando eu for pra rua e quero continuar ouvindo a mesma biblioteca de música, só que agora no meu fone de ouvido. Essa integração entre dispositivos e softwares é incrível. Perceba que não estamos falando sobre um ecosistema fechado como o da Apple. Estamos falando de hardware e software de fabricantes diferentes, que prestam diferentes serviços, mas que se integram.

Entende o que é a experiência do usuário nesse cenário?

Posts Relacionados

• Um pensamento sobre design para web
• Vote no Especialista em Usabilidade para Presidente
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• ePub: Aprenda a criar um livro digital

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?

Framework é um conjunto de componentes que provêm uma estrutura básica de elementos reutilizáveis, tendo uma arquitetura consistente de funcionalidade genérica sob a qual a aplicação será construída.

O uso de uma Biblioteca (CSS, Javascript, etc) é bastante parecido com a utilização de um framework. Eu prefiro a utilização de uma biblioteca por ser menos instrusiva e muito mais personalizável. Existem algumas diferenças que você deve prestar sua atenção para entender qual das duas formas é melhor para o projeto.

Modificação visual

Enquanto o framework modifica as características visuais, a biblioteca se restringe manipulando a diagramação ou a posição dos elementos.

Na grande maioria, os frameworks modificam automaticamente o visual de alguns elementos, gerando um certo retrabalho, porque geralmente o design aplicado não é o design aprovado pelo cliente ou pelo designer do projeto. Veja por exemplo o Bootstrap feito pelo pessoal do Twitter. Assim que linkado em seu código, os elementos como os campos de formulários e parágrafos tem suas características visuais modificadas para seguir um design pré definido pelos donos do framework – diga-se de passagem, o trabalho de design feito pelo pessoal do Bootstrap é muito bacana. Já as bibliotecas, na maioria das vezes, não faz nenhuma modificação no design ou na posição dos elementos sem a inserção de Classe ou ID. Geralmente as bibliotecas são restritas para manipular a posição e as dimensões dos elementos, facilitando a diagramação de layouts, sem modificar as características visuais, já que os layouts de cada site tem o design diferente. É por isso que eu gosto de definir que frameworks são ótimos para construir sistemas, já as bibliotecas ajudam muito mais ao construir websites. Sistemas tem muitos formulários, botões de ação, pouco texto e etc. A utilização de um framework é muito interessante nesse caso porque não perdemos tempo manipulando e definindo um padrão visual para estes elementos – como os tamanhos dos campos de formulário de texto.

Já a biblioteca é muito útil para definir quando os elementos terão float, position, largura variável e etc. São características de posição e diagramação, que não afetam a questão do design.

Quantidade de código não utilizado

Geralmente ao utilizar uma biblioteca, talvez você estará linkando mais código do que o necessário para o seu projeto. Você pode não utilizar todas essas classes/ids pré definidos pelo autor da biblioteca, o que é normal dependendo do projeto e do design criado. Este risco diminui quando utilizamos frameworks, já que eles modificam as características de todos os elementos principais do projeto. Praticamente todo o código estará do framework estará sendo usado porque eles são aplicados nos elementos assim que o framework é linkado no código. Porém, com a biblioteca, é fácil mapearmos quais as classes utilizadas e excluir o código que não está sendo usado para diminuir o tamanho dos arquivos e do código.

Personalização e criação

A personalização ou criação de uma biblioteca CSS é muito mais fácil do que se resolvermos criar do zero um framework. Você consegue facilmente criar uma biblioteca de CSS contendo algumas classes úteis para qualquer projeto, por exemplo:

O código acima é um bom começo para uma biblioteca CSS personalizada. Contém ali classes básicas que se combinadas dão diferentes características para um determinado elemento. Essas classes também se mostram muito úteis se reutilizarmos no código javascript do projeto.

Sistema e Site

Design de sistemas são sempre parecidos. Todos eles tem muitos campus de formulário, checkboxes, combos, radio buttons e etc. É basicamente manipulação de formulários, alertas de erro e mensagens para o usuário, manipulação de botões de ação e etc. Não foge muito disso.
Já o design de sites são todos bem diferentes. Por isso que a manipulação visual dos frameworks se torna inútil e gera muito retrabalho.

Eu prefiro utilizar bibliotecas para a criação de sites. Para o desenvolvimento de sistemas, prefiro utilizar framworks.

Mas tenha em mente: se for decidir utilizar qualquer um dos dois, é bom que essa decisão seja feita logo no começo do projeto. Aplicar um framework no meio de um projeto pode dar muitos problemas e tomar muito tempo. Por isso é importante que essa decisão seja feita no início do projeto.

Concluindo

Entenda que um framework pode ter uma biblioteca de CSS embutida em seu core. Tendo também a possibilidade de manipular o visual dos elementos, o framework se mostra muito mais completo que uma biblioteca CSS, embora a bilioteca ganhe por ser mais fácil de personalizar e por não manipular o visual dos elementos, te deixando livre para formatar da forma que você bem entender.

Posts Relacionados

• Experiência cross-device
• Introdução ao CSS 3D – Flip Card
• OOCSS ou CSS do jeito certo
• CSS3 – Animation e regra keyframe
• CSS 3 – O valor currentColor

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

Graciosamente retroceder ou progressivamente evoluir?

A melhor análise antes de decidir qual caminho tomar e a qual evolução recorrer vem do planejamento de seu projeto. Estudo de estatísticas de navegadores, perfil do usuário, resolução de tela, dispositivos, etc; são alguns dos pontos a serem levados em consideração, criando material suficiente para você decidir qual caminho seguir: considerar o retrocesso [ por exemplo: desenvolver seu website para IE6 ] ou expor a evolução de forma progressiva [ por exemplo: utilizar bordas arredondadas e novas características via CSS3 ].
Determinar os fins do projeto vão estabelecer o melhor caminho a seguir durante toda a sua execução pois, em época de transição, os riscos de utilizar algo que não dê certo e a presença de retrabalho são quase inevitáveis. Assim, considere todas as possibilidades.

Graciosamente retroceder

Quando pensamos em retrocesso, no caso do desenvolvimento web, o utilizamos para conceituar uma codificação baseada em X-HTML/CSS 2 e Crossbrowser [ com browsers de mercado incluindo o IE6 ], de qualquer forma, a ideia não é pensar que esteja errado ou que seja um método fora de uso, mas sim uma segurança em utilizar o que já está regulamentado, validado pela W3C e igualmente embutido na renderização padrão dos browsers mais utilizados.
Inúmeras são as dicas aqui no Tableles relacionadas à esta frente de desenvolvimento, mas o que podemos levar em consideração quando pensamos em desenvolver um website dentro dessas diretrizes é que: IE 6 e IE7 ainda devem fazer parte dos browsers em testes e que ainda utilizaremos imagens para criação de bordas arredondadas e sombras. Além claro, de nos encontrar em momentos que utilizaremos diversos elementos em nosso código html apenas para assegurar que algum efeito visual seja renderizado na tela [ as vezes dependente do uso de Javascript para tanto ]. Considerando estes pontos e pensando nos fins do projeto, basta iniciar o desenvolvimento.
Algumas dicas que podem ajudar nesta escolha estão em: http://tableless.com.br/categoria/client-side/html-css/page/2

Progressivamente evoluir

Como falamos acima, estamos num momento de transição que significa acima de tudo – escolha. Utilizar novas possibilidades na criação de websites é uma escolha que deve ser igualmente planejada pois, o risco não vem do que já conhecemos e do que já sabemos que vai exigir maior cuidado, mas sim do que desconhecemos – a renderização de novos parâmetros em folhas de estilo e a interpretação de uma nova tag html, por exemplo.
Pouco ainda consegue-se definir a respeito das novas possibilidades, mas é fato que muitos desenvolvedores estão aprendendo como utilizar o novo, testando e reportando erros e acertos e este comportamento deve estender-se por anos, até que as diretrizes sejam regulamentadas pela W3C e os browsers tenham o mesmo número de usuários que suas versões de mercado tem hoje.
Com isso, os testes geralmente giram em torno dos novos browsers, mas eventualmente necessitamos também direcionar o desenvolvimento à navegadores mais antigos, encontrando assim, a dificuldade em visualizar a mesma coisa em todos eles. Para ajudar, pensando em HTML 5 e CSS3, abaixo uma lista de algumas ferramentas que podem ajudar na implementação das novas técnicas em browsers e possibilidades atuais:

• Modernizr: http://www.modernizr.com/ – uma ferramenta JavaScript que suporta propriedades CSS3 em diferentes navegadores.
• CSS3 Pie: http://css3pie.com/ – já comentada em outro artigo, o CSS3 Pie é uma ferramenta JavaScript que permite renderizar bordas arredondadas, background-gradient e box-shadow nas versões anteriores de IE.
• Selectivizr: http://selectivizr.com/ – ferramenta JavaScript que emula seletores CSS3 e pseudo-classes, como por exemplo :focus em diferentes browsers.

Além das ferramentas, conheça no link ao lado também, algumas das melhorias trazidas para as folhas de estilo em sua nova versão e para a evolução da linguagem de marcação – o HTML5: http://tableless.com.br/categoria/client-side/html-css

Testar o novo ou trabalhar com o conhecido? Esta pergunta não podemos responder, mas analisadas as características do seu projeto, você mesmo poderá tomar esta decisão consciente de um trabalho profissional e determinado ao sucesso.

Boas escolhas e até a próxima.

Posts Relacionados

• Experiência cross-device
• Agora é a vez dos desenvolvedores
• Introdução ao CSS 3D – Flip Card
• Command & Conquer: Tiberium Alliances
• Experiência deve ter começo, meio e fim

Basicamente você consegue controlar as características do objeto e suas diversas transformações definindo fases da animação. Observe o código abaixo e veja seu funcionamento:

O código acima define um valor inicial e um valor final. Agora vamos aplicar esse código a um elemento. Minha ideia é fazer um DIV girar.

O código HTML até agora é este. Fiz apenas um div e defini este keyframe:

Primeiro você define a função de animação, no caso é o nosso código que define um valor inicial de 0 graus e um valor final de 360 graus. Agora vamos definir as características deste DIV.

Nas primeiras linhas defini qual será o estilo do div. Ele terá uma largura e uma altura de 50px. A margin de 30% do topo garantirá um espaço entre o objeto e o topo do documento, e background preto.

A propriedade animation tem uma série de propriedades que podem ser resumidas em um shortcode bem simples. Veja a tabela logo a seguir para entender o que cada propriedade signifca:

animation-name

Especificamos o nome da função de animação

animation-duration

Define a duração da animação. O valor é declarado em segundos.

animation-timing-function

Descreve qual será a progressão da animação a cada ciclo de duração. Existem uma série de valores possíveis e que pode ser que o seu navegador ainda não suporte, mas são eles: ease, linear, ease-in, ease-out, ease-in-out, cubic-bezier(, , , ) [, ease, linear, ease-in, ease-out, ease-in-out, cubic-bezier(, , , )]*. O valor padrão é ease.

animation-interation-count

Define o número de vezes que o ciclo deve acontecer. O padrão é um, ou seja, a animação acontece uma vez e pára. Pode ser também infinito definindo o valor infinite no valor.

animation-direction

Define se a animação irá acontecer ou não no sentido inverso em ciclos alternados. Ou seja, se a animação está acontecendo no sentido horário, ao acabar a animação, o browser faz a mesma animação no elemento, mas no sentido antihorário. Os valores são alternate ou normal.

animation-play-state

Define se a animação está acontecendo ou se está pausada. Você poderá por exemplo, via script, pausar a animação se ela estiver acontecendo. Os valores são running ou paused.

animation-delay

Define quando a animação irá começar. Ou seja, você define um tempo para que a animação inicie. O valor 0, significa que a animação começará imediatamente.

Voltando para o nosso código, vamos aplicar algumas dessas propriedades:

Veja que na propriedade animation-name chamamos o mesmo nome que demos na nossa função de keyframe logo no começo da explicação. Depois definimos uma duração de ciclo de meio segundo. Definimos que o comportamento da animação será linear, e com a propriedade animation-iteration-count definimos que ele girará infinitamente. E por último definimos pelo animation-direction que a animação deverá ser alternada, ou seja, o DIV girará para um lado, e quando alcançar o final da animação, o browser deverá alternar essa animação.

Podemos melhorar esse código utilizando a versão shortcode, que é mais recomendado. Veja a ordem que devemos escrever as propriedades animation em forma de shortcode:

animation: animation-name, animation-duration, animation-timing-function, animation-delay, animation-iteration-count, animation-direction] , animation-name, animation-duration, animation-timing-function, animation-delay, animation-iteration-count, animation-direction

Aplicando isso ao nosso código:

Pronto. Agora temos um elemento que gira sem parar, hora para direita hora para esquerda.

Definindo ciclos

Nós definimos no keyframe do nosso último exemplo apenas um início e um fim. Mas e se quiséssemos que ao chegar na metade da animação o nosso elemento ficasse com o background vermelho? Ou que ele mudasse de tamanho, posição e etc? É aí onde podemos flexibilizar melhor nosso keyframe definindo as fases da animação. Por exemplo, podemos dizer para o elemento ter uma cor de background diferente quando a animação chegar aos 10% do ciclo, e assim por diante.

Veja o exemplo:

Definimos acima que o início da animação o elemento começará na posição normal, 0 graus.
Quando a animação chegar aos 50% do ciclo, o elemento deverá ter girado para 180 graus e o background dele deve ser vermelho. E quando a animação chegar a 100% o elemento deve ter girado ao todo 360 graus e o background, como não está sendo definido, volta ao valor padrão, no nosso caso black, que foi definido no CSS onde formatamos este DIV.

Logo nosso elemento girará pra sempre e ficará alternando a cor de fundo de preto para vermelho. Fiz um exemplo bem simples modificando apenas o background, mas você pode muito bem definir um position e modificar os valores de left e top para fazer o elemento se movimentar.
No exemplo também defini apenas 3 estágios (0%, 50% e 100%) você pode definir um maior número de estágios: 5%, 10%, 12%, 16% e etc… Adequando as fases da animação às suas necessidades.

Há exemplos muito interessantes na internet onde podemos ver todo o poder das animações feitas pela CSS. Veja o exemplo que fizemos aqui neste texto no endereço: http://migre.me/4ubym

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• OOCSS ou CSS do jeito certo
• CSS3 – Sombras em textos e elementos
• CSS3 – Módulo Template Layout
• CSS3 – Breve introdução ao RGBA