Nós estamos no meio dos dois grupos. Nós nos relacionamos diretamente com os dois profissionais, fazendo uma ponte e tentando adequar as necessidades de cada um durante o projeto. E é aí que entra o problema.

Os dois mundos são totalmente diferentes. O designer se preocupa em deixar o sistema lindo, maravilhoso, fácil de usar, vendável e etc. O programador faz com que tudo funcione. O cliente tem que conseguir comprar quando clicar no botão. Nosso trabalho é fazer com que a beleza não estrague a funcionalidade. É fazer com que as necessidades do programador não entrem em conflito com as necessidades do designer. Nesse meio entra o seu trabalho. Sua obrigação é deixar o site acessível, com código de fácil indexação e escalonável ao mesmo tempo que você deixa o layout do designer fiel ao original do Photoshop.

Necessidades dos Designers

Os designers precisam de liberdade para criar. Isso sempre foi muito difícil na web e por isso o Flash ganhou tanta atenção. Se antes só podíamos fazer coisas básicas utilizando CSS, o Flash dava ao designer acesso a um mundo de possibilidades. Atualmente isso mudou muito graças ao Santo protetor dos desenvolvedores front-end.

Com a vinda das features do CSS3, boa parte das funcionalidades que antes tínhamos que fazer gambiarras com imagens, hoje podemos fazer com apenas uma propriedade. Quem nunca passou horas recortando imagens de bordas arredondadas, sombrinhas e degrades? Hoje resolvemos tudo diretamente pelo CSS, que roda mais rápido e é muito mais flexível.

A ideia é transportar fielmente a arte que o designer criou no editor gráfico, para código HTML/CSS. Nesse momento você precisa se preocupar com duas coisas: fidelidade de layout e semântica de código.

O código HTML irá refletir os elementos do layout, traduzindo a informação visual, para informação em código semântico de forma que os dispositivos, robôs de busca, scripts e afins acessem esse código e executem suas tarefas. O Google precisa saber o que é um link e um botão. Mesmo que eles tenham o mesmo design. O leitor de tela precisa entender o que é um título e um parágrafo. Isso tudo aliado com os detalhes visuais que o designer desenhou, como sombras, degrades, transparências, bordar arredondadas e etc.

Esse processo inicia a fase de código do projeto. Estamos criando uma estrutura que vai perdurar o projeto inteiro. Os programadores, posteriormente, irão produzir o sistema em cima deste código. Por isso é muito importante que sua base seja bem estruturada mas ao mesmo tempo super flexível para mantermos o layout da maneira correta.

Necessidades dos Programadores

Os programadores precisam automatizar coisas. O projeto precisa que as tarefas sejam automatizadas para que o projeto funcione de forma escalonável e sem a necessidade de replicação de código desnecessariamente. Essas tarefas vão desde a criação de formulários até comunicação com o servidor.

O problema é que a maioria das vezes essas tarefas automatizadas não são criadas pelos programadores da equipe. São plugins, scripts e etc que foram criados pela comunidade. Não estou dizendo aqui que isso é ruim, por favor. Na verdade, é o certo. Não tem sentido recriarmos algo que já existe e que funciona muito bem. Esses plugins, scripts e etc foram criados por outros programadores que um dia tiveram a mesma necessidade que os programadores do seu projeto e por isso, nada mais sensato do que criar um plugin para ajudar outros devs com a mesma necessidade. Acontece que programadores, são programadores. Eles não tratam o HTML com o mesmo carinho que nós.

Vamos pegar um exemplo de formulários. Os programadores aqui onde trabalho programam em RUBY, utilizando Rails. Há uma GEM que cria e gerencia formulários no projeto. O código que esta GEM gera por default não é legal e o pior, é totalmente diferente do código que você usaria ou usou no projeto – Por isso é interessante entender quais ferramentas os programadores utilizarão antes de iniciarmos nosso código HTML. Assim podemos adaptar o que for preciso para códigos que fujam do seu padrão pessoal.

Você não pode obrigar os programadores a fazerem tudo na mão. Se você conseguir, ótimo. Essa é sempre a minha primeira opção… Mas caso isso seja impossível, sugiro que sente e tente entender o maldito plugin. Converse com o programador e tente mostrar as desvantagens para o projeto caso continuem a utilizar o código default. Veja se não há a possibilidade de modificar esse código. Na maioria das vezes há. Caso não dê, estude a possibilidade de trocarem para um plugin que dê.

Existem frameworks – como o Web2Py – que ainda utilizam tabelas para exibir formulários. Chorei sangue quando eu vi pela primeira vez e chorei mais ainda ao descobrir que não é algo muito fácil customizar eses código para que ele entregasse o HTML que eu queria. Paciência.

Sincronizando as necessidades

O encontro de dois mundos gera o problema. Sincronizar as necessidades visuais dos designers com as necessidades de código dos programadores é algo que geralmente deixa traumas em qualquer dev front-end.

O programador precisa usar ferramentas que os ajudam a executar tarefas complexas, mas que adulteram demais o código. O designer precisa que seu layout seja fielmente seguido, ou seja, todas as firulas visuais como sombras, degrades, bordas, backgrounds e etc permaneçam intactas. Como você pode manter o padrão de qualidade se o código manipulado não é o seu, mas o do plugin? É aqui que os front-ends maricas pedem arrego.

Cada efeito visual, cada estrutura, cada necessidade de layout determinam com que o HTML será escrito. Se o HTML é criado automaticamente por um plugin ou algo parecido, como você faz? Entende a questão?
Você até faz o layout ficar igual ao planejado, mas e a semântica? O design, a funcionalidade e a semântica precisam coexistir. Essa é a essência da responsabilidade do profissional client-side.

Não há mágica que faça isso tudo acontecer. Você precisa sentar e conversar. Eu costumo chamar o designer e o programador e explicar minhas limitações. Eles entendem e cada um abre mão de algo que pode me ajudar. O designer tira aquele efeito visual desnecessário e o programador tenta colocar aquela classe importante e retirar um ou outro código automático. A opção de conversar com os dois é melhor do que você criar uma solução com Javascript. Para retirar ou inserir as tags ou classes que você precisa. O código fica mais feio e seu site perde performance. Sem contar que para resolver suas pendências manipulando o DOM com Javascript, é pior para o Google, para os leitores de telas e para os robôs em geral.

Padronizando tudo

Uma outra solução que eu cheguei é mais complicada, mas sem dúvida a mais duradoura. Começamos a criar dentro da empresa uma biblioteca que une código HTML/CSS semântico com o visual predefinido dos designers e que contemple as necessidades de funcionalidades dos programadores.

Assim, começamos a criar uma cultura de padronização de código que vai perdurar por várias gerações de serviços e acima de tudo, não quebra a linearidade dos produtos em si. Manteremos a uniformidade de código com a a uniformidade de identidade visual dos sistemas. Não estamos engessando a criação, pelo contrário, estamos criando uma base sólida que poderá ser reutilizada em toda a empresa, em larga escala e independente.

Posts Relacionados

• Drops 5 – Responsabilidade Dev Front-end
• Adobe: The Expressive Web
• Drops 9 – Préprocessadores, frameworks e bibliotecas
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• O dev front-end – Podcast #1

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

Préprocessadores

Préprocessadores são ferramentas onde você escreve CSS de uma determinada forma, modificando sua sintaxe, fazendo com que na hora de sua utilização o código CSS precise ser préprocessado para que o código escrito seja transformado em código CSS puro e assim então os browsers consigam entender.

Existem muitos préprocessadores no mercado como Less, Sass, Turbine, Switch CSS e outros.

Particularmente eu não gosto de usar préprocessadores. Para começar é necessário que você aprenda a linguagem de cada um e a ideia de que seu CSS precisa ser compilado para poder funcionar não me agrada muito. O CSS é simples demais para complicarmos desse jeito. Entretanto, há uma série de coisas interessantes que podemos fazer com os préprocessadores como variáveis, funções, operações e etc que demorarão um pouco (ou não) para fazerem parte do core definitivo da linguagem. Mesmo assim, pessoalmente, para a maioria dos projetos, não vale a pena.

Frameworks

Frameworks são diferentes de préprocessadores mas são muito parecidos com Bibliotecas. Um Framework disponibiliza para o dev um conjunto de estilos e estruturas prontas para a utilização em projetos de forma escalável e uniforme. Normalmente os frameworks te dão uma coleção de componentes para que sejam usadas por todo o projeto. Esses componentes na maioria das vezes já vem com estilos visuais aplicados, bem como a estrutura. Veja por exemplo o Bootstrap ou o Blueprint.

Com o Bootstrap você consegue, rapidamente, fazer um protótipo simples ou uma estrutura básica de sistema. É o preferido dos programadores. Os elementos visuais já foram criados e desenhados. Talvez não seja uma boa ideia você utilizar um framework em um projeto cujo design já esteja aprovado. Você teria muito retrabalho para “zerar” o estilo visual de cada elemento para depois reconstruí-lo utilizando o seu design.

É muito importante que o uso de um framework CSS/Javascript seja aprovado no início de um grande projeto. Mesmo que você planeje criar um framework do zero, específico para seu projeto. O que na maioria das vezes não vale a pena.

Bibliotecas

Bibliotecas CSS geralmente não modificam o visual como os Frameworks fazem, mas eles disponibilizam uma coleção de classes, reutilizáveis e o melhor, combinatórias, para que se adeque a diversos cenários do seu projeto. Como essas classes não estão ligadas a nenhuma formatação visual, você consegue combinar sem grandes problemas com suas classes e IDs, modificando a hora que quiser a formatação visual dos elementos.

As bibliotecas são indicadas para projetos mais simples, sem grandes apetrechos técnicos, como um site ou algo parecido. Para fazer um sistema, as bibliotecas irão reforçar os Frameworks, facilitando a organização e formatação da estrutura do site. A biblioteca também ajuda na manipulação dos elementos via Javascript se baseando por estas classes prontas.

A verdade é que hoje é muito difícil diferenciar uma biblioteca de um framework.

Como todos eles trabalham juntos?

Você pode usar todos os três ao mesmo tempo em um projeto. Mas não é muito inteligente, já que se você estiver utilizando um framework, muito provavelmente ele terá uma “biblioteca” em sua base. Imagine que a biblioteca pode ser específica de estrutura ou formatação visual. O Framework, basicamente, junta os dois. Obviamente há mais coisas envolvidas. Mas para simplificarmos a explicação, imagine que um Framework é a mistura dessas duas bibliotecas.

O Preprocessador é independente do Framework e da Biblioteca. O seu ganho está ao escrever um código mais escalável, muitas vezes melhorando ou piorando a sintaxe do código. É pura sintaxe, não são classes prédefinidas. Mesmo assim você pode basear seu Framework/Biblioteca em um Préprocessador. O Bootstrap faz isso para facilitar features dinâmicas como grids, cores e etc.

Como eu disse, eu não gosto de misturar as coisas. Prefiro utilizar o Bootstrap puro, sem a interferência de nenhum préprocessador. Mas, há gosto para tudo.

Qual deles é melhor para o meu projeto

Eu não sugiro que você utilize um framework para criar websites institucionais. Websites geralmente não usam os mesmos elementos, nem as mesmas estruturas, nem o mesmo design. Logo, se você utilizasse um framework como o Bootstrap, ou o JQuery UI, você acabaria gastando mais tempo reestilizando e brigando com o CSS já criado dos frameworks do que fazendo o que realmente importa: o seu trabalho.
Logo, para projetos de pequeno porte eu sugiro que você utilize uma biblioteca simples. Sugiro ainda que essa biblioteca seja criada por você.

Não precisa de muito. Em uma biblioteca você só precisa ter algumas propriedades que fazem tarefas básicas, como fazer o elemento flutuar para a esquerda, para direita, clear, retirar margens e etc. Normalmente eu utilizo um reset chamado Normalize. Ele já reseta meu CSS inteiro e então eu me foco apenas nas propriedades que eu reutilizarei no resto do projeto.

Se seu projeto for médio ou grande, você já pode pensar em utilizar um Framework. Principalmente se seu projeto for um sistema. Você já vai ter à disposição estilos para formulários (que são um saco pra fazer), botões, grids, reset CSS e outras coisas. O trabalho fica mais fácil por que você tem menos arestas para acertar. Ainda mais se o designer aceitar utilizar alguns dos estilos já prontos do Framework, assim você não precisa reconfigurar formatações visuais e etc.

A utilização do Préprocessadores é totalmente opcional. Mas se você decidir utilizá-lo juntamente com algum Framework, procure saber se o Framework escolhido suporta algum tipo de préprocessador. O Bootstrap, por exemplo, tem uma versão para LESS.

No próximo artigo vou contar como estamos fazendo aqui na Locaweb. Estamos criando uma grande biblioteca visual e de front-end que será utilizado por todos os serviços. Os programadores conseguem subir um sistema sem precisar esperar um código HTML definitivo, utilizando os módulos dessa biblioteca. A galera de design faz todos os layouts padronizados visualmente, garantindo a uniformidade de todos os sistemas. E o pessoal de front? Bom o pessoal de front cuida para que tudo isso funcione.

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação

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

Este ano eu estou trabalhando a maior parte do tempo em um monitor fullHD. Notei uma diferença gritante ao digitar código pela primeira vez em um monitor desses. E não são apenas os monitores que estão mudando para uma resolução decente. Também, seguindo o ciclo natural, dispositivos menores estão recebendo a dádiva de ter a alta resolução em suas telas. E isso, meu caro, é uma dádiva para o usuário, para você é mais trabalho.

Pixels não são mais como eram antigamente

Na minha época de escola – nem tanto tempo assim – os professores me ensinaram que o átomo era indivisível. Era incrível por que eu, como criança, me divertia tentando entender como algo poderia ser tão pequeno que não pudesse ser partido ao meio, ficando menor… Mas aí eu descobri que os prótons, os elentrons e outras partículas subatomicas existiam também…

A mesma coisa aconteceu com o pixel. O pixel sempre representou a menor unidade da sua tela. Para os designers, o pixel é a unidade central. É onde tudo se baseia: medidas, tamanhos, alinhamentos etc… Mas o pixel não é mais como era antigamente.

Com o advento das telas HD em aparelhos móveis, o conceito de pixel mudou um pouco muito. Quando a tela retina display do iPhone 4 foi lançada o queixo de todo mundo caiu. A Apple conseguiu apertar quatro pixels onde apenas caberia um. Logo o pixel pode ser definido como a menor unidade na tela, como você já conhece ou pode ser baseada em uma unidade chamada hoje em dia de “pixel referência” ou do inglês reference pixel: que significa que esse novo “pixel” é uma referência ótica de unidade.

Para entrar em detalhes, leia o que é um pixel. Vai te ajudar a entender melhor.

Densidade de pixels

A sigla DPI significa Dots Per Inch, ou seja, é o número de pixels que seu dispositivo pode conter em uma polegada. Quanto mais pixels em uma polegada, mais nítida a imagem é.

Os aparelhos como o iPhone 4 e outros que carregam Android tem uma densidade de pixels muito alta. Ou seja, eles conseguem comprimir um grande número de pixels em suas telas, tornando as imagens melhores. O problema é que as imagens que criamos hoje podem parecer ruins nesses dispositivos. Algo parecido como aumentar uma imagem pequena no Photoshop, entende? Ela fica toda pixelada, sem qualidade nenhuma. Isso por que você está aumentando o tamanho de uma imagem que é pequena e não tem pixels suficientes para dividir pelo tamanho que você definiu.

Entenda fazendo um teste: Vá até o site da Apple utilizando SAFARI. Agora, dê um zoom em alguma imagem. Veja como ela parece pixelada por causa do zoom. Agora abra o Inspector do seu navegador, vá até o console e coloque as duas linhas abaixo:

A imagem foi trocada para uma imagem com o dobro de tamanho da imagem original para que ela ficasse melhor em telas com alta densidade de pixels… Veja a diferença. Eu vi esse truque aqui.

Ações para otimizar

Existem algumas atitudes que vocês já pode tomar agora para poder chavear estes aparelhos e entregar uma experiência melhor para seus usuários.

Utilize media queries

Media Queries são um chuchuzinho. Você pode utilizar uma regra chamada device-pixel-ratio para detectar qual CSS servir dependendo do pixel-ratio do dispositivo. Não precisa ser maníaco e servir vários CSS para vários pixel-ratios… Você vai ficar doido se fizer isso.

Abaixo veja uma tabela de exemplos de aparelhos com seus valores de pixel-ratios:

Agora, como seria o CSS:

Eu sugiro que você se limite apenas para o pixel-ratio 2. Do jeito que as coisas estão andando, os aparelhos de pixel-ratio menor do que 2 desaparecerão logo e os aparelhos com pixel-ratio igual a 1 são maioria e você já faz versões para eles, já que não precisam de fallbacks.

Considere chavear versões de imagens

Este é um problema que ainda não existe uma solução inteligente e definitiva.
A ideia é tentar evitar que o usuário baixe duas imagens iguais, mas de tamanhos diferentes para cada tipo de necessidade. Logo, existem vários fallbacks, em Javascript ou linguagens server-side para servir apenas a imagem necessária.

O pessoal da Clound Four escreveu um artigo muito interessante sobre isso.

Há outros artigos bons por aí. Eu estou dando uma lida em vários para tentar escrever um artigo mais simples aqui no Tableless. Mas o assunto é muito vasto e ninguém tem uma opinião definida ainda. Isso não é útil apenas para a situação dos aparelhos hires, mas também para encontrarmos maneiras de servir imagens menores para versões de sites mobiles.

Text rendering

Você consegue melhorar muito a leitura dos usuários utilizando a propriedade text-rendering.

Esta propriedade melhora muito a leitura quando o usuário dá o zoom nos aparelhos móveis e também corrige suporte de ligaduras e kerning. Coisa linda.

Text Smoothing

A propriedade font-smoothing é útil agora! A leitura melhora demais em monitores normais e previne serrilhamentos ocasionais quando utilizandos @font-face.

Tente usar CSS3

Tente usar e abusar dos efeitos do CSS como sombras, gradientes, bordas arredondadas e etc. Além de facilitarem sua vida evitando a criação de imagens desnecessárias, elas ajudam na velocidade de carregamento do site.

Considere utilizar SVG

Já tem alguns que estão começando a utilizar SVG para facilitar a vida. Para ícones, SVG é ótimo. Você consegue reutilizá-los em diversos tamanhos, aumentando o diminuindo de acordo com a sua necessidade e também do aparelho. Veja um exemplo que a Smashing Magazine escreveu.

Novo elemento HTML

O W3C já criou um grupo chamado Responsive Images Community Group para a criação de elementos do HTML que facilitam a entrega de assets dependendo do contexto. Eles estão propondo um novo elemento que identifica as dimensões do dispositivo, velocidade de rede, densidade de pixels e outros pontos para servir melhor imagens e outros assets dependendo do contexto.

Muitos artigos para ler

• How to make your web content look stunning on the iPhone 4′s new Retina Display
• Retina Display and CSS Background Images
• Designing for the Retina Display (326ppi)
• How to use hi-res images in web apps for iPhone4
• Targeting High Screen Densities with CSS Media Queries
• A Pixel Identity Crisis
• optimizing web experiences for high resolution screens

Posts Relacionados

• ePub: Aprenda a criar um livro digital
• Boas práticas de Acessibilidade
• Experiência deve ter começo, meio e fim
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Adobe e os Padrões Web

Agora, a bola da vez é criar designs responsivos como se não houvesse o amanhã. É aí que entra a pergunta: você precisa de um design responsivo?

A maioria dos browsers para dispositivos móveis fazem um bom trabalho em websites que não tem versão específica para mobiles. Desde a vinda do iPhone, todos os browsers para mobiles se adequaram de uma forma que antes apenas o Opera abordava. Hoje, quando navegamos em qualquer website, tendo ou não versão para mobile, temos uma boa experiência. Aí vem o ponto: será que criar um site responsivo é o mais importante para o negócio do seu cliente? Produzir um website mobile friendly não é apenas modificar sua carinha, colocar ícones bonitinhos e pronto. Há outros pontos a serem abordados que são tão ou mais importantes que este.

Veja um comentário do Brad Frost em seu artigo:

Your visitors don’t give a shit if your site is responsive. They don’t care if it’s a separate mobile site. They don’t care if it’s just a plain ol’ desktop site. They do give a shit if they can’t get done what they need to get done. They do give a shit when your site takes 20 seconds to load. They do care when interactions are awkward and broken.

Entende o que eu quero dizer? Um dispositivo móvel já é mais dinâmico por natureza que os desktops. Os aparelhos móveis de hoje em dia nos fazem querer os resultados mais rapidamente. Se você tiver um website desenhado apenas para desktops, mas mesmo assim ele é rápido, os usuários de mobile vão agradecer. Já vi muitos websites mobiles que foram apenas adequados… Isso não é produzir um site mobile. Se seu site é bem desenhado e sua usabilidade impecável, ter um design responsivo passa a ser secundário e você passa a dar atenção coisas mais importantes, por que mesmo sendo uma versão desktop, o usuário conseguirá navegar sem muitos problemas.

Mas você quer dizer que sites mobile não importam?

Não, não quero dizer isso. Pelo contrário, eles importam e muito. A experiência do usuário é muito melhor se houver uma versão mobile, sem sombra de dúvida. Mas do que adianta ter uma versão mobile se o site demora 20 segundos para carregar? O dev cria a versão mobile, mas ele não faz adaptação nenhuma nas imagens (e não estou falando apenas de mudar a dimensão dela), não usa com inteligência o font-face, que embora seja maravilhoso, come muita banda… Acontece que ter carinha bonita não quer dizer que é fácil de usar.

Experiência de usuário é o foco

O foco é buscar a melhor experiência possível que o usuário pode ter em seu dispositivo. Nós usamos responsive web design para levar a experiência do usuário para outro nível. Não apenas por que está todo mundo fazendo. Você não precisa fazer seu site se adequar ao redimensionar a janela. É bonito? Sim, claro, mas só pra impressionar, porque não é muito útil se você parar para pensar.

No front-end, a experiência do usuário vai muito além do design. Responsive web design não é uma modinha é mais uma ferramenta para usarmos em pról da boa experiência do usuário. É por isso que na construção dos nossos projetos, podemos iniciar o trabalho pensando primeiramente nos mobiles e depois nos desktops. Isso nos faz mirar em objetivos mais importantes, não apenas para mobiles, mas para os desktops também, bem como tablets, tvs e todo o resto que vem por aí.

Alguns artigos para você dar uma olhada:

• Why is Responsive Web Design Such A Big Deal? Seriously…You Tell Me
• responsive web design: missing the point
• Which One: Responsive Design, Device Experiences, or RESS?
• Mobile First – A arte de pensar com foco
• A usabilidade deve ser pensada por todos

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• Utilizando APPs em vez de browsers
• Mobile First – A arte de pensar com foco
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão

A exemplo de mais uma das vantagens do CSS3, vamos conhecer melhor como aplicar uma imagem de textura ao preenchimento de um texto, utilizando apenas declarações “fonts” na folha de estilo.

Vale ressaltar que o exemplo abaixo funcionará, neste momento, exclusivamente no Chrome e no Safari em suas últimas versões. E antes que você pense: “então, não poderei aplicar aos meus projetos…”, te tranquilizo; talvez você não possa aplicar aos projetos para web em desktop e diversos tipos de outros navegadores, mas você poderá aplicar a seus projetos mobile ou para tablets.  Pense nisso!

Então, vamos lá!

Crie um novo documento html com a seguinte marcação:

Após, adicione as características de estilo (uso aqui a aplicação incorporada para facilitar os testes):

A princípio, seu texto está assim:

Agora, vamos abrir um dos editores de imagem – Photoshop ou Fireworks – e criar uma imagem PNG com a nossa textura. Em meu teste inicial, eu utilizei uma imagem de textura pronta, mas o resultado não ficou como esperado, então aconselho colocar seus dotes de criação em atividade e realmente criar a textura.
Abaixo uma breve explicação da textura que criei no Fireworks.

Utilizando o Fireworks, crie um novo documento (1900×200), selecione a ferramenta pincel, depois aplique as seguintes características (barra de ferramentas inferior): Tip size – 300 | Stroke Category – Pencil Pixel Soft | Texture – Line vertical e Burlap.

Na hora de escolher a melhor forma de exportar sua imagem, o cuidado com o peso em kb continua valendo. Em se tratando de PNG, é muito fácil um simples arquivo ficar com mais de 500kb, por isso, em meus testes observei que exportando em PNG8 você vai ter um arquivo de 52kb com uma qualidade visual menor, mas que dependendo do estilo de textura é perfeitamente aplicável, ou exportando em PNG32 você preza por uma qualidade visual melhor, mas ao custo de um arquivo de 200kb. A escolha vai depender da velocidade de conexão ao qual você vai estabelecer para esta aplicação e do resultado visual que você julgar aceitável.

Criada a imagem, vamos incluir ao style do texto o atributo “mask-image” que definem a textura no texto.

Reload no navegador… e voilá! Um texto com um preenchimento texturizado.

Daí para frente você pode incrementar utilizando font-face, text-shadow ou outras texturas. Fica a critério da sua criatividade.

Até a próxima!

Posts Relacionados

• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Propriedade background-clip
• Cut the Rope
• Qualidade de Imagens e densidade de pixels
• Seu lugar ao sol

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

Acabei descobrindo que este tópico ficaria enorme e, por isso, preferi escrever sobre o assunto em um artigo próprio.

Com vocês, alguns dos métodos menos populares do jQuery!

proxy()

O método proxy() permite executar um outros método forçando um determinado contexto. Seu objetivo principal é evitar a confusão do ‘this’ causada quando um objeto é utilizado dentro de um método de outro objeto.

Por exemplo:

É possível utilizar o proxy() através de duas assinaturas. A primeira recebe como parâmetros uma função e o escopo. A segunda funciona passando o escopo e o nome do método como uma string.

Quem sabe agora você para de usar o truque do ‘var that = this’, hein?

isArray() e isFunction()

Esses dois métodos fazem parte da família de utilitários do jQuery. Como seus nomes sugerem, o primeiro verifica se o objeto é um array JavaScript e o segundo se o objeto é uma função.

Uma observação: a função isArray retorna true apenas para verdadeiros Arrays (e não objetos “tipo array”, como um objeto jQuery, por exemplo).

A lista de utilitários possui outros métodos interessantes, tais como grep(), map(), merge() etc.

queue() e dequeue()

Apesar de terem sido desenvolvidos originalmente para o uso de animações, os métodos queue() e dequeue() podem ser utilizados para qualquer tipo de fila.

A fila padrão é chamada de ‘fx’: essa é a fila das animações. Ela será utilziada caso não seja passado nos parâmetros o nome de uma fila. No exemplo abaixo, estamos criando a fila ‘ajaxRequests’.

Para dar sequência no andamento da fila, você precisa utilizar o método dequeue(). Ele deve ser chamado no final da execução de um processo da fila (e como essa é uma fila de processos AJAX, utilizamos o dequeue no evento complete).

Outro recurso interessante é a possibilidade de saber o tamanho da fila, ou seja, quantos eventos ainda serão executados. Para isso, basta utilizar a propriedade length após o método queue().

detach()

Assim como o remove(), o detach() retira um elemento do DOM. No entanto, esse método guarda as referências, eventos e dados associados ao elemento retornando um objeto jQuery que pode ser re-inserido no DOM.

ajaxSetup() e afins

Talvez esses sejam os métodos mais injustiçados do jQuery. É muito comum a repetição de chamadas AJAX, incluindo seus parâmetros. Esses métodos de configuração permitem definir valores padrão para qualquer evento AJAX em sua aplicação.

Com o ajaxSetup() é possível, por exemplo, habilitar ou desabilitar o cache e definir o tipo de requisição: POST ou GET.

Você ainda pode configurar uma URL padrão e também parâmetros passados durante a chamada:

Para conferir uma lista completa das propriedades configuráveis, visite a página do método AJAX na API do jQuery.

Os callbacks e eventos relacionados à execução de métodos AJAX também podem ser configurados. No entanto, essa configuração deve ser feita através dos seguintes métodos específicos: ajaxStart(), ajaxStop(), ajaxComplete(), ajaxError(), ajaxSuccess() e ajaxSend().

Por exemplo, você poderia utilizar a configuração abaixo para exibir um indicador de carregamento no início da execução de um método AJAX.

Você pode associar os eventos a qualquer elemento e o jQuery se encarregará de encontrar e executar todos os métodos associados.

delay()

O método delay() serve para adiar a execução de uma função, método ou animação. Ele é especialmente útil para controlar o tempo de animações.

No exemplo acima, o elemento com a classe “alerta” é exibido através de uma transição fade e, um segundo depois, ocultado através do método slideUp().

replaceWith() e replaceAll()

Imagine que você queira substituir todos os elementos que tenham a classe “pontos”. Com o método replaceWith() fica fácil. O que ele faz é buscar todos os objetos que se encaixem no seletor indicado e substituir seu conteúdo.

O replaceWith() também funciona com elementos que não estejam presentes no DOM, ou seja, você pode criar um objeto jQuery e substituir/manipular seu conteúdo antes de inserí-lo no DOM.

Da mesma forma, o método replaceAll() também substiui o conteúdo de elementos, mas a origem e o destino são invertidos. Você também pode passar seletores como conteúdo. Nesse caso o funcionamento é um pouco diferente já que o elemento não é clonado e sim movido no DOM.

Note que a diferença dos métodos acima para os métodos tradiconais html() e text() é que o próprio elemento também é substituído e não só o seu conteúdo.

Estes foram alguns métodos que pouca gente conhece ou utiliza. Pode até ser que você nunca tenha sentido falta deles, mas é sempre bom ter umas cartas extras na manga.

E se você gostou, garanto que ao consultar a API do jQuery você descobrirá vários outros métodos desconhecidos, mas que podem ser úteis em algum momento do desenvolvimento dos seus projetos.

Posts Relacionados

• Manipulação de classes com JQuery
• JavaScript com café
• Cut the Rope
• jQuery: conheça os métodos on() e off()
• Introdução aos padrões de codificação

Os desenvolvedores do mundo inteiro juntamente com os fabricantes de browsers e outros interessados, querem ter certeza que os navegadores, robôs de busca, leitores de tela e outros sistemas detectem da forma ideal o idioma correto.

A declaração do idioma no código HTML não determina a informação no encoding de caractére do texto nem a direção de leitura do texto em outros idiomas. Essas definições precisam ser declaradas separadamente.

Nós precisamos definir o idioma por alguns motivos:

• Melhor pronunciação do texto em leitores de tela.
• Para que os buscadores possam indexar o website no buscador do respectivo idioma. Por exemplo: não tem sentido o Google ranqueear muito bem um site em português no Google americano.
• Selecionar as fonts corretas para mostrar na tela. Nesse caso para idiomas como Chinês.
• Para que os browsers escolham o dicionário correto para a correção gramatical nativa em textos e formulários.
• Renderizar a página rapidamente – o browser carrega o documento mais rápido quando o browser sabe qual o idioma nativo.

Definindo o idioma padrão do documento

Existem algumas maneiras que você pode definir o idioma padrão no documento exibido ou em partes do texto para aqueles termos em idiomas diferentes.

Podemos definir diretamente via metatag nativa:

Pela Metatag podemos definir vários valores no atributo content:

Via HTTP Header:

Via atributo lang nos elementos do HTML.

Assim indicamos, principalmente para os leitores de tela, quais termos ele deve ler com o idioma nativo do termo.

Temos o costume de indicar o atributo lang no elemento html logo no início do documento para indicar que todo o conteúdo contido dentro do html está escrito em um determinado idioma.

Ordem de herança

Os meios de acesso, normalmente browsers, seguem esses passos de verificação para identificar o idioma:

1. Verifica se elemento HTML que tem o atributo lang, se não,
2. Verifica se pai mais próximo ao termo que tenha o atributo lang, se não,
3. Verifica se o documento tem a metatag definida <meta http-equiv=”content-language” content=”pt-br”>, se não,
4. Verifica se o HTTP Header Content-Language tem uma tag de idioma definido. Se não,
5. O idioma é tratado como não reconhecido.

O W3C recomenda que você sempre utilize o lang no elemento html para definir o idioma padrão de todo o conteúdo e também em todo o termo encontrado no texto com idioma diferente do definido como padrão.

Declarações de idioma baseados nestes atributos são importantes para a maioria das aplicações web hoje, que vão desde as corretores ortográficos embutidos diretamente nos browsers até leitores de telas que interpretam as páginas web, etc etc.

Estas possibilidades são interessantes para que possamos globalizar ainda mais nossos projetos. Imagine por exemplo um website que ensina Russo para Chineses. É interessante que possamos marcar os termos dos dois idiomas de forma que os mecanismos trabalhem adequadamente em diversos meios de acesso. Os browsers precisam identificar quando o texto está em Russo ou quando está em Chinês. Os buscadores também precisam entender essa diferença, bem como os leitores de tela.

Aos poucos vamos padronizando características que antes eram ignoradas no desenvolvimento web. Não são ações muito difíceis de aplicar. Para começar, basta colocar o atributo lang no elemento html dos seus documentos e pronto.

Referências

Artigo que explica os Charsets, encodes e tabelas de caractéres no HTML.

Veja aqui a documentação oficial do W3C que fala sobre este assunto.

O W3Schools tem aqui uma listagem dos códigos de idioma que podem usados.

Posts Relacionados

• Guia de Referência de HTML5
• Ah, o maravilhoso mundo real
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Qualidade de Imagens e densidade de pixels
• Experiência deve ter começo, meio e fim