Arquivo Mp3.

Posts Relacionados

• Drops 6 – Acessibilidade
• Drops 5 – Responsabilidade Dev Front-end
• Drops 2 – A palavra Marcação do HTML
• Adobe e os Padrões Web
• Drops 8 – O que o dev client-side deve saber

O pessoal da Apple fez isso com o Webkit. Eles tomaram emprestado o motor de renderização criado pelo pessoal do KDE – com o motor chamado KHTML – e fuçaram, mexeram, arrumaram, criaram e devolveram o resultado para a comunidade como um dos melhores motores de renderização que já existiu, o Webkit.

Em vez de criarem um motor novo, eles resolveram começar de uma base que já estava bem feita, pronta e organizada por uma comunidade forte. O KHTML e o KJS (motor de Javascript do KDE) permitiam o desenvolvimento mais fácil que as outras tecnologias do mercado e detalhe, tinha apenas 140.000 linhas de código! Era limpo e principalmente tinha um bom suporte com os padrões web.

A Adobe Macromedia, sem dúvida, revolucionou a web com a criação do Flash. Eu fui um dos doidos eufóricos quando eles mostraram uma linha se transformando em um circulo. Chorei sangue quando aprendi a manipular a timeline e fiz minha primeira animação. Não estou dizendo que o Flash é um lixo. Estou dizendo que o Flash fez o seu papel. Todo mundo achou que a Apple desistiria da decisão, mas não foi o que aconteceu. Eles se mantiveram firmes e isso, felizmente, agitou o mercado. Ajudou na divulgação da importância dos Padrões Web e impulsionou muito o HTML5 e o CSS3, que até então apenas o W3C e a comunidade estavam incentivando a sua utilização.

Depois da atitude da Apple de barrar o Flash de seus aparelhos, o que a Adobe faria? Quando a Adobe percebeu que seu software não teria vez, ela foi obrigada a seguir outro caminho. Graças ao grande senhor das montanhas indígenas extraterrestres, eles tomaram o caminho correto. A Adobe tem tido algumas iniciativas para ajudar os desenvolvedores a criarem websites melhores. Se não pode com eles, junte-se a eles.

Para você entender o que eu quero dizer, a Adobe criou um http://html.adobe.com para divulgar suas iniciativas para com a comunidade de desenvolvedores. As ideias expostas no site são sensacionais e eu, particularmente, quero muito que tudo se torne verdade. Separe um tempo e visite esse site. Você não vai perder nada.

Eles tem um software interessante que te ajuda a testar a responsividade do seu layout em diversos aparelhos e tem algumas sugestões de novos padrões que poderão nos ajudar demais em desenvolvimentos específicos. Leia sobre o CSS Regions e o CSS Shaders. Tem também o PhoneGap.

Parabéns para Adobe.

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• ePub: Aprenda a criar um livro digital
• Um pensamento sobre design para web
• Experiência cross-device
• Dicas de sobrevivência em uma era pós o IE6

Por isso, aqui vão algumas dicas de propriedades que você já deve conhecer, mas que não usa ainda por que acha que todos os IEs são iguais ao maldito IE6.

:after

Você deve usar alguma técnica de clearfix que você criou ou que você pegou de algum lugar. Eu usava muito jquery para criar um elemento vazio dinamicamente no final do elemento que necessita do clearfix para fazê-lo parar de sofrer influência dos floats dos elementos. Essa técnica aqui pode salvar sua vida:

O content pode ser usado para uma série de outras coisas, como por exemplo inserir um ícone, objeto ou até texto depois de um determinado elemento.

Nesse caso o IE7 fica de fora.

first-child

Sim. O First-child funciona no IE7 ou superior. Mas o last-child não. Sem chance.
Isso já acaba com aqueles problemas de alinhamento de elementos em linha, onde você precisa tirar a margin, padding ou border do último (ou o primeiro) elemento para que eles fiquem alinhados corretamente.

Seletores complexos

Olha só que maravilha, o IE7+ já suporta alguns seletores complexos como os descritos abaixo:

Todos eles funcionam no IE7 ou superior. Só com estes seletores já economizamos uma penca de código Javascript.

:first-letter e :first-line

Formatar a primeira letra do parágrafo ou a primeira linha. Coisa linda.

word-wrap

Essa propriedade é utilíssima. Você já deve ter escrito uma palavra muito grande ou uma URL, que geralmente não tem espaços, o que ocasionou da string ultrapassar a largura do objeto. A propriedade word-wrap faz com que essas strings muito grandes quebrem de linha assim que atingirem o limite do objeto.

Essa propriedade funciona desde o IE5. O.o

max-height/width e min-height/width

Essas aqui são essências para produzirmos layouts fluidos e responsivos. Funcionam a partir do IE7.

Tabela de referência

O MSDN guarda uma tabela de compatibilidade muito completa com propriedades do CSS que os IEs suportam ou não. Vale a pena dar uma olhada e entender melhor o que você já pode usar nativamente do CSS em vez de sair escrevendo loucamente soluções JQuery.

Posts Relacionados

• Ferramentas de diagnóstico
• Desenvolvendo para IE6
• Ah, o maravilhoso mundo real
• IE8 – O sonho não acabou
• Sobre Internet Explorer para Mobile – Breve impressão

A combinação da grande variação de browsers no mercado com as mais as novas features do CSS resultam em problemas de compatibilidade. Você quer utilizar uma feature que ainda está sendo estudada, e que somente o Firefox, por exemplo, suporta. Se você simplesmente utilizar a propriedade no seu CSS, os browsers que não suportam essa propriedade, ou que suportam mas com uma sintaxe diferente, podem dar problemas. Aí é que entra os prefixos de browsers.

O prefixo é muito útil para podermos experimentar features que ainda estão sendo estudadas e que são rascunhos nos documentos do W3C. Prefixos são úteis por que nos direcionam para um caminho seguro sob as inconsistências entre propriedades e browsers.

Como utilizar um prefixo

Não se assuste, se você utilizará uma propriedade de CSS que ainda está sendo planejada mas ainda assim quer aplicar em seu projeto para que os usuários de novos browsers possam usufruir com uma melhor experiência ao acessar seu site, seu código pode ficar um pouco confuso. Por isso, organize-se melhor ao decidir quais propriedades você gostará de experimentar.
Para exemplo vamos utilizar a propriedade border-radius. Se quisessemos fazer uma borda arredondada com 10px, faríamos assim:

Note que colocamos por último a propriedade verdadeira, sem nenhum prefixo, essa propriedade cobrirá os browsers que não precisam da utilização de prefixos para renderizar a propriedade, por exemplo o Opera e o Internet Explorer 9.

O problema

Atualmente estamos beirando a mesma situação citada no início do artigo. O Firefox, Opera e Microsoft estão pensando em suportar o prefixo -webkit-. O problema é que os desenvolvedores estão utilizando em seus projetos apenas o prefixo -webkit- para algumas propriedades do CSS3. Isto é muito ruim.

Se todos os browsers suportarem um mesmo prefixo o mercado será “controlado” por apenas um fabricante de browser que poderá ditar as regras sobre quais propriedades do CSS poderão ser implementadas primeiro. Ok, ok, meu sonho era que um browser sob o engine webkit dominasse mesmo. Mas isso foi quando o IE era o browser mais utilizado e a Microsoft não havia aberto os olhos ainda. Mas concorrência é ótimo em qualquer lugar, até na web.

O pessoal está conversando sobre algumas possibilidades de soluções. Uma interessante e na minha opinião mais inteligente, é a criação de um prefixo neutro, utilizado por todos os browsers para indicar novas features. Algo como -alpha- ou -beta- e assim por diante.

Todos os grandes nomes da web estão se mobilizando para que a web não fique em volta de um único browser. Tenha em mente que o pessoal do -webkit- não está fazendo nada de errado, nós estamos.

Daniel Glazman, Co-chairman do W3C CSS Working Group escreveu um post, muito preocupado e chamando toda a comunidade de desenvolvedores a adequarem seus sites e a entenderem o grande problema que isso pode ser tornar. Veja uma parte do post:

Without your help, without a strong reaction, this can lead to one thing only and we’re dangerously not far from there: other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That’s not a question of if, that’s a question of when.

Veja o post completo aqui.

O Web Standards Project também se mobilizou.

E aí? Vai mudar sua atitude? O que você pensa sobre isso?
Como você pode ajudar?

Assine essa petição para os fabricantes de browsers não suportarem o prefixo webkit e espalhe para seus colegas a notícia. E claro, ao usar os prefixos para os browsers, utilize todos e não apenas um.

Foto do post

Posts Relacionados

• Dicas de sobrevivência em uma era pós o IE6
• Drops 9 – Préprocessadores, frameworks e bibliotecas
• Adobe e os Padrões Web
• Schema – Marcação de dados estruturados
• O browser que você amou odiar

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

• Qualidade de Imagens e densidade de pixels
• GoMo – Teste seu site mobile
• Introdução ao CSS 3D – Flip Card
• Experiência deve ter começo, meio e fim
• Vote no Especialista em Usabilidade para Presidente

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
• Adobe e os Padrões Web

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

• Drops 9 – Préprocessadores, frameworks e bibliotecas
• Adobe e os Padrões Web
• Dicas de sobrevivência em uma era pós o IE6
• Prefixos dos browsers: A web precisa de você
• ePub: Aprenda a criar um livro digital

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

• Dicas de sobrevivência em uma era pós o IE6
• Experiência cross-device
• Introdução ao CSS 3D – Flip Card
• OOCSS ou CSS do jeito certo
• CSS3 – Animation e regra keyframe