Baixe A Web Mobile Programe para um Mundo de Muitos Dispositivos e outras Notas de estudo em PDF para Engenharia Elétrica, somente na Docsity! A Web Mobile Programe para um mundo de muitos dispositivos 7 é! Casa do Código SÉRGIO LOPES — b- © 2013, Casa do Código Todos os direitos reservados e protegidos pela Lei nº9.610, de 10/02/1998. Nenhuma parte deste livro poderá ser reproduzida, nem transmitida, sem auto- rização prévia por escrito da editora, sejam quais forem os meios: fotográficos, eletrônicos, mecânicos, gravação ou quaisquer outros. Casa do Código Livros para o programador Rua Vergueiro, 3185 - 8º andar 04101-300 – Vila Mariana – São Paulo – SP – Brasil Casa do Código Sobre mim Escreviminha primeira linha de código com 14 anos em 1999 e ela foi emHTML.Daí pra CSS e JavaScript foi um pulo. Em seguida, me aventurei em SSI e PHP, incluindo bancos de dados. Em 2003, iniciei meu curso de Ciência da Computação na USP e nadei em águas mais profundas desde então — Java, C, Python. Cresci bastante em programação backend. Mas eu sempre fui apaixonado por front-end. Com o renascimento daWeb através do HTML5 nos últimos anos, voltei a focar na minha paixão. Respiro front-end o dia todo. Leio muito, estudo muito, escrevo muito e programo muito — desde que envolva bastante HTML, CSS e JavaScript. E, de algum tempo pra cá, resolvi focar emmobile. Meu primeiro site mobile eu escrevi há quase uma década usando WML pra redes WAP (se você é novo, talvez precise daWikipedia pra entender a frase anterior). Imagine minha animação então nessa nova era dos smartphones e o que significam para a Web. Acredito muito na Web única como plataforma democrática e universal. Já trabalhei em algumas empresas, programando em várias linguagens (já até i Casa do Código ganhei dinheiro com opensource). Desde 2004, trabalho naCaelum como instrutor e desenvolvedor. Foi onde minha carreira decolou e onde mais aprendi, e aprendo todo dia. É onde pretendo passar ainda muitos e muitos anos. Ensinar e escrever são uma paixão desde o colégio — lembro a decepção da mi- nha professora de português quando ela descobriu que eu seguiria carreira em exatas. Dar aulas, escrever artigos, blogar e palestrar são minha maneira de misturar essas habilidades. Esse livro é ponto alto em toda essa trajetória. Espero que seja divertido pra você ler tanto quanto foi, para mim, escrever. Obrigado por acreditar nele e comprá-lo. Você pode me encontrar também escrevendo por aí na Web: • Meu blog pessoal onde escrevo bastante sobre Web, mobile, front-end em ge- ral: http://sergiolopes.org • O blog da Caelum, onde sempre publico artigos sobre front-end: http://blog. caelum.com.br • Meu Twitter e meu Facebook onde posto muitos links pra coisas baca- nas de front-end e mobile: https://twitter.com/sergio_caelum e https://www. facebook.com/sergio.caelum • E também participo de vários fóruns, grupos e listas de discussão de Web, onde a gente pode se encontrar. Meu favorito é o novo GUJ: http://www.guj. com.br/perguntas E, se nos toparmos um dia em algum evento, não deixe de me chamar pra bater- mos um papo. — Sérgio Lopes, 2013 ii Casa do Código Sumário Sumário 1 AWebMobile 1 Estratégia mobile 5 2 Os caminhos de uma estratégia mobile 7 3 App ouWeb? Comparativo de possibilidades 13 4 HTML 5 é diferente de HTML 5: o caso das packaged apps 21 5 Design Responsivo por umaWeb única 27 6 Mobile-first 33 7 Mercado, Browsers, suporte e testes 39 Programando aWeb moderna 47 8 Flexibilidade naWeb com layouts fluídos 49 9 Media queries: as melhores companheiras de um layout fluído 59 10 Tudo que você queria saber sobre viewport 67 11 A saga dos 3 pixels e as telas de alta resolução e retina 79 12 Não remova o zoom dos seus usuários 87 iii Casa do Código nos dispositivos de hoje e de amanhã. E muitas das transformações recentes daWeb foram causadas pelas revoluções e novidades dos dispositivos móveis. Então, não é que o título do livro está incorreto, mas, talvez, incompleto. Deveria ser algo como “A Web moderna e como ela foi afetada pelos dispositivos móveis”. Acabei resumindo para “A Web Mobile”. Omercado mobile Decidi que não ia começar o livro citando estatísticas de como omercadomobile cresceu muito nos últimos anos e como ele vai estourar nos próximos. Nemmostrar a evolução do 3G ou 4G no Brasil ou falar de quanto de participação no mercado cada plataforma móvel tem. Qualquer número desses ficaria desatualizado pouco depois da publicação. E também acho que, se você está lendo esse livro, é porque não precisa ser convencido de que o mercado mobile tem um potencial gigantesco. Se você precisar de informações detalhadas sobre o crescimento desse mercado, comportamento dos consumidores e outros dados, recomendo oOurMobile Planet do Google (http://www.thinkwithgoogle.com/mobileplanet/pt-br/). Ele tem dados do mundo todo, inclusive de pesquisas específicas do Brasil. Outra fonte onde você consegue números atualizados mês a mês é o Stat Coun- ter, sobre acesso a Web (http://gs.statcounter.com/). E os sites de notícias de tecno- logia estão sempre mostrando matérias atualizadas com novos dados e pesquisas de mercado — Info, Techtudo, Gizmodo Brasil. Fato é que o mercado para dispositivos móveis é gigantesco e cheio de oportu- nidades. Muita gente está se dando bem: fabricantes de aparelhos, operadoras de telefonia, criadores das plataformas, desenvolvedores de aplicativos e os que acredi- tam no acesso aWeb via mobile. O foco do livro é nesse último grupo. É para todos que querem explorar o potencial de se ter um navegador de Internet no bolso de milhões de pessoas. O livro Organizei o livro como uma série de tópicos com temas diversos. Não é um livro para iniciantes; você precisa ter familiaridade com Web e HTML, CSS e JavaScript. Tambémnão é um livro como qual você vai desenvolver umprojeto prático do início ao fim— recomendo o livro “WebDesign Responsivo” do amigo Tárcio Zemel se você quer um passo a passomais prático com projetinho (http://www.casadocodigo.com. 2 Casa do Código Capítulo 1. A Web Mobile br/products/livro-web-design-responsivo). Esse livro é como uma coleção de artigos sobre Web, mobile e assuntos relacio- nados. Cada seção em geral é curta e pode ser lida independentemente das outras. Você pode até ler fora de ordem ou pular alguma que não lhe interesse. Em diversos momentos, voumostrar exemplos práticos pra você testar. Além do códigomostrado, você tambémpode executar direto no seu dispositivo acessando as URLs de exemplo ou os qrcodes que espalhei pelo livro. Se estiver lendo o ebook, to- das as referências são clicáveis; para os leitores do impresso, coloquei os links de to- das as referências em http://sergiolopes.org/livro-web-mobile/referencias.html pra facilitar. Apesar de ser um livro bem técnico e prático, eu tomei a liberdade de darminhas opiniões pessoais em alguns momentos. Tento deixar claro sempre que algo é uma opinião pra você analisar, julgar e discordar de mim à vontade. Existe um grupo de discussões oficial do livro no Google Groups pra você ti- rar dúvidas e discutir comigo e outros leitores (https://groups.google.com/d/forum/ livro-web-mobile). E tem o GUJ Perguntas (http://www.guj.com.br/perguntas/) onde você também pode postar seus questionamentos. Esse não é um livro completo. No brainstorm original que fiz, acabei com uma lista de assuntos para uns 10 volumes diferentes. Tive que escolher o que ia entrar aqui e o que ia ficar de fora. Gostei da seleção final de tópicos mas talvez eu tenha deixado de fora justo aquele assunto que você queria saber. Quem sabe um dia eu escreva os outros 9 volumes mas, até lá, você pode me encontrar no meu blog onde escrevo mais: http://sergiolopes.org Boa leitura! 3 Capítulo 2 Os caminhos de uma estratégia mobile Então você, convencido do potencial do mercado mobile, decide atacá-lo. Por onde começar? O primeiro ponto é discutir os caminhos possíveis e, então, traçar uma estratégia mobile. Porque mobile? O primeiro ponto é definir o motivo de nossa empresa ou projeto encarar o mundo mobile. Que objetivos queremos atingir? Qual o público-alvo e do que ele precisa? Toda reunião que começa com a frase “precisamos de uma App pro iPhone” já começou errada. A App ou o site mobile são meios pra um fimmaior. Que objetivos meu usuário quer atingir com essa App? Esse levantamento do porquê é importante para definir seus passos no mundo mobile. Dependendo do resultado, podemos concluir que uma App nativa para Casa do Código iPhone é o melhor. Ou que o melhor é um site mobile. Ou que não precisamos de nada disso. O site da Apple, a mãe da era mobile moderna, até hoje não tem uma versão mobile. E não temApp pra iPhone também, nem pra iPad. Nos levantamentos deles, provavelmente concluíram que o site Desktop bem construído é suficiente pra todo mundo. Um tanto irônico, mas um bom exemplo de que montar uma App ou site mobile só pelo oba-oba não é uma boa ideia. App ouWeb? Uma vez decidida a investida em uma presença mobile, a primeira resolução necessária costuma ser se criamos uma App ou se investimos na Web mobile. O próximo tópico do livro (3) vai se aprofundar nas diferenças práticas e técnicas dessas duas abordagens. Depois, no tópico 4, vamos discutirApps híbridas construídas com tecnologias da Web. As diferenças comumente citadas de performance, acesso a recursos de hardware e etc eu nem considero tão relevantes assim. Agora, quero focar na discussão mais estratégica por traz dessa decisão. Os aspectos mais técnicos, aliás, muitas vezes, são irrelevantes. Apesar de existirem diferenças, sim, de performance entre nativo e Web, elas não são determinantes para a maioria das aplicações e usuários. A Web é boa o suficiente para a maior parte dos cenários, assim como ela é boa o suficiente no Desktop apesar de perder em performance para softwares nativos por lá também. Expectativas Na minha opinião, o aspecto que mais deve pesar na decisão por App ou Web é a expectativa do usuário com relação a sua empresa, seu projeto, sua marca. Se você está criando um novo produto ou nova empresa, pensando em algo ino- vador, pode não fazer muita diferença se é uma App ou Web. Você ainda não tem usuários, então não há expectativas com relação a seu produto. Você pode criar algo novo e forte em uma direção específica e não perder ninguém. Um exemplo prático: o Instagram nasceu como uma App para iPhone e só. Era um novo serviço com objetivo de explorar justo o nicho de compartilhamento de fotos no smartphone da Apple. Estrategicamente, a empresa focou num certo nicho e inovou com um produto diferente. Não tinha uma App para Android, um site mobile e nem mesmo uma versão da App pra iPad. Era um foco estratégico e de negócios que só uma empresa nova podia ter. Depois, com o crescimento, lançaram 8 Casa do Código Capítulo 2. Os caminhos de uma estratégia mobile a versão para Android mas nada muito além disso. Agora, se você já tem uma presença na Web, um produto consolidado, iniciar sua estratégia mobile com uma App nativa pode ser um tiro no pé. Imagine um portal de notícias nacional decidir entrar no mundo mobile lançando uma App pra iPhone. Além de deixar a maior parte do mercado de fora, é uma situação que pode ser anormal até para o próprio usuário do iPhone. O portal é tão forte naWeb que o usuário está acostumado a ler as notícias no navegador e, provavelmente, deve abrir o site mesmo no iPhone. Qual é a expectativa do usuário? Web first Eu gostomuito daWeb. Acredito demais nela como plataforma portável e demo- crática. Escrevi esse livro sobre Web! Mas, apesar de tudo isso, concordo que Apps têm seu lugar no mundo, claro. Há muitos cenários onde uma App traz melhor ex- periência para o usuário e satisfaz melhor suas expectativas, sobretudo com relação à usabilidade. Mas omercado de Apps hoje é exclusivo, e apostar em uma plataforma X é arris- cado. Alguns anos atrás, apostar no iOS parecia o tiro certeiro para atingir a maioria do mercado. Hoje, o Android é dominante na maior parte do mundo (e ganha de lavada no Brasil). E amanhã? Muita gente que apostou numaApp iOS há alguns anos está agora correndo atrás da versão Android. E vão precisar correr atrás de qual plataforma depois? Já quem apostou na Web está tranquilo. Uma estratégia é começar sempre pela versão Web do seu produto ou webapp. Sedimentar bem sua presença mobile via Web, garantindo acesso universal e mul- tiplataforma. Aí, conforme as necessidades surgirem e seu planejamento financeiro permitir, você pode investir em Apps específicas de plataformas com recursos e ex- periências nativas. Web first. Várias grandes empresas da Web seguiram esse caminho. Facebook, Google e Twitter são exemplos óbvios. O Facebook tem Apps para iOS e Android bem in- tegradas às plataformas, mas elas só foram construídas depois do site mobile que até hoje oferece suporte a todo tipo de plataforma móvel. Aqui no Brasil, portais de notícias grandes seguiram a mesma estratégia — UOL, Globo, etc —, assim como a maioria das lojas virtuais. Em comum a todos eles? Já eram uma marca forte na Web e o caminho mais lógico era suportar mobile também com a Web. É o que os usuários deles esperam. 9 Capítulo 3 App ou Web? Comparativo de possibilidades Eu sei que esse livro é sobre Web, então há uma clara tendência minha e do grupo de leitores para esse caminho. Mas nem sempre essa escolha é tão simples, e acho que vale uma breve discussão técnica. E, mesmo se você já tiver se decidido por um caminho, é bom analisar os prós e contras dessa decisão. A grande diferença entre Apps e a Web que geralmente se discute é que uma App dá melhor acesso e integração ao hardware e à plataforma nativa do aparelho, enquanto que aWeb traz independência de plataforma e portabilidade. Mas existem milhões de detalhes aí no meio que precisam ser discutidos. Integração com hardware e plataforma Uma App tem acesso direto ao hardware do aparelho e a recursos do sistema operacional. Consegue se integrar com funções avançadas e a outras Apps. Pode manipular o funcionamento do aparelho e até substituir ou complementar funções Casa do Código nativas. Já aWeb roda enjaulada dentro do navegador e, por razões de segurança, não tem acesso direto à plataforma nativa. Mas existem diversas APIs novas do HTML 5 que expõem acesso a recursos antes exclusivos das Apps — exemplos clássicos são acesso à câmera, geolocalização, informações de acelerômetro e giroscópio, e anima- ções 3D com aceleração na GPU. Mas, claro, há muitas coisas mais específicas que ainda só as Apps têm acesso e que não são possíveis pela Web. O que é preciso definir aqui é que tipo de requisito você tem. Se você precisar de coisas muito específicas, uma App será o caminho. Mas as capacidades da Web são suficientes para grande parte dos cenários. Segurança e privacidade Rodar dentro do navegador tem suas vantagens. As restrições de segurança são fortes e a chance de acontecer algo de ruim é bem pequena. O usuário está mais protegido abrindo um site Web do que instalando uma App em seu aparelho. As lojas de Apps tentamminimizar o impacto ruim na segurança com restrições e permissões explícitas que o usuário tem que aprovar. Mas a verdade é que amaioria dos usuários não compreende os impactos das permissões que aprova, ainda mais quando a lista é grande e cheia de termos estranhos (como na instalação de uma App no Android). Outra maneira de tentar evitar problemas são os mecanismos de aprovação das lojas como da Apple que fazem um pente fino. Ou ainda o sistema de detecção de código malicioso que o Android tem. Mas existem vários casos de tudo isso sendo burlado, e Apps que roubam dados pessoais vão parar na loja do iOS e vários vírus na do Android. Isso tudo pelo ponto de vista do usuário, que prefere estar mais protegido. Do ponto de vista do desenvolvedor, o cenário pode ser o inverso: se você quer umaApp que acesse os dados do usuário e tenha altos privilégios, a Web vai limitá-lo. Mas, pro usuário, Web é mais segura. A Web não é isenta de problemas, claro. Mas as décadas de evolução dos nave- gadores fez tudo ser mais seguro. Mais limitado também, mas por boas razões de segurança e de privacidade. Performance Apps sempre serãomais rápidas que aWeb. Elas rodam direto no sistema opera- 14 Casa do Código Capítulo 3. App ou Web? Comparativo de possibilidades taforma (como o Android) não exige que o usuário pré-aprove uma lista críptica de permissões. A Web é totalmente descomplicada. Abra o link no navegador e pronto. E, se quiser, o usuário ainda pode adicionar um favorito em sua tela inicial pra voltar depois no site. Permissões pra coisas mais avançadas são pedidas pelo navegador conforme o necessário (como geolocalização). Quando há atualização, uma App precisa ser instalada novamente pela loja (seja automaticamente ou manualmente). Em muitos casos, isso envolve baixar a App toda de novo, o que pode ser grande (o Android consegue baixar só as diferenças). Na Web, não precisamos fazer nada. O usuário sempre acessa a versão mais recente quando navega. Ainda sobre o tamanho da instalação: uma App precisa baixar tudo durante a instalação, todo código e arquivos de todas as funcionalidades. Uma página Web pode carregar só o que é necessário pra tela atual. Se o usuário nunca usar uma tela avançada, ela nem é carregada no browser, mas seria baixada junto com a App, gastando banda. E, por falar em gasto de banda, não há coisa pior do que estar na rua, no 3G, e precisar instalar uma App. A Web costuma ser bem mais leve pra esse tipo de uso rápido e casual. O ponto principal é que a Web é totalmente descentralizada. Você não fica na mão do fabricante que faz exigências pra sua aplicação ser aprovada, proíbe certos usos legítimos, cobra uma porcentagem cara na venda e controla arbitrariamente a exposição da sua App na busca da loja. Na Web, você divulga seu link em qualquer canal, sem depender de ninguém. Há quem diga que a presença na loja aumenta a exposição da sua App, já que os usuários buscam coisas por lá. É verdade, mas usuários também buscam no Google. E há estudos que mostram que as lojas de aplicativos estão tão cheias hoje que a chance do usuário cair na sua App é bem pequena. Mas, claro, depende da App e do tipo de busca do usuário. Um serviço famoso que tenha marca forte não tem problemas para ser encontrado (buscar Gmail na loja sempre vai trazer a App do Gmail). Mas não há muito espaço para descoberta de novas apps. O usuário não vai digitar ‘notícias’ na busca, de tanta porcaria que vai aparecer; e, mesmo que busque, sua Appzinha não vai aparecer no topo. As Apps demais sucesso fazem sucesso fora das lojas, e são linkadas em artigos e blogs famosos. As pessoas baixam porque conhecem e já ouviram falar. Raramente baixam porque esbarraram nela na loja sem nunca ter ouvido falar. Então, pensando bem, se você fosse pra Web ao invés de App, daria na mesma. 17 Casa do Código Outro ponto a se pensar é o uso casual. Uma App exige um compromisso maior do usuário, uma instalação. E muita gente não precisa e nem está disposta a ir tão longe. Muitos usuários só querem uma certa informação num dado momento, algo facilmente encontrável na Web. Uma App é para uso regular, para usuários fiéis. E, mesmo assim, estudos mostram que a maioria das Apps que as pessoas instalam são abertas bem poucas vezes, quando são. Monetização Uma diferença brutal nessa parte de distribuição onde as Apps ainda ganham de longe é na questão da monetização. As lojas já são plataformas de pagamento integradas e o usuário não tem trabalho algum para comprar Apps e assinaturas. A Web não tem esse tipo de facilidade. Há os serviços de pagamento como PayPal, mas nada tão fácil. Claro que há a contrapartida da porcentagem altíssima cobrada pelas lojas, coisa que, naWeb, você poderia escolher entre diversos serviços de pagamento ou até cobrar diretamente. Muitas empresas que têm nomemais forte começaram a desafiar esse modelo de loja e retiraram suas Apps das lojas e focaram naWeb com pagamento direto pra eles — o caso mais notório foi do jornal americano Financial Times (http://gigaom.com/ 2011/09/22/financial-times-finds-life-outside-the-app-store-pretty-good-so-far/). Mas, tirando essa questão da monetização, o processo de distribuição e instala- ção é muito mais complicado com Apps que na Web. Multiplataforma O grande apelo da Web é ser independente de plataforma. A gente encontra navegador Web em tudo que é aparelho hoje em dia, não importando tipo, marca, sistema operacional. Desenvolver seguindo os padrõesWeb garante o acesso a todos os usuários do mundo, sem discriminação. Claro que isso não quer dizer que não existam suas dificuldades. As incompa- tibilidades entre navegadores têm diminuído bastante nos últimos anos, mas ainda são um problema. É preciso testar bastante e escapar dos bugs. Mas é um trabalho muito menos complicado que fazer Apps para plataformas específicas. O mais comum, aliás, é que o desenvolvimento de Apps foque nas plataformas que estão em alta — nomundomobile, isso significa iOS e Android. Sob argumento de que não vale a pena economicamente suportar plataformas menores, muita gente deixa de lado os zilhões de outras plataformas — no mundo móvel, temosWindows 18 Casa do Código Capítulo 3. App ou Web? Comparativo de possibilidades Phone, Blackberry, Symbian, Bada, Tizen, Firefox OS, só pra citar as mais ouvidas. Não é à toa, aliás, que a maior parte desses sistemas não tão famosos usa tecnologias Web (HTML, CSS e JS) como base pro desenvolvimento de Apps. Elas estariam perdidas se exigissem uma reescrita total da App. Aliás, esse cenário de se usar HTML, CSS e JavaScript para escrever Apps é cada vez mais comum. A ideia é justo resolver o problema da portabilidade — o mesmo código rodaria no Android, iOS, Windows Phone etc, usando sistemas de empaco- tamento como PhoneGap. Vamos discutir melhor esse cenário daqui a pouco, no tópico 4, mas não se engane: Apps HTML5 compartilham a maior parte dos proble- mas das Apps de modo geral e não são Web, apesar de usarem a mesma linguagem. É possível, portanto, ter um mínimo de portabilidade de código ao escrever Apps, mas você ainda vai ter que publicar em lojas diferentes e individualmente. E alguma hora você vai desistir de publicar numa loja menos conhecida pra focar nas maiores (já pensou em publicar na loja do Bada alguma vez?). E assim você vai excluir uma parcela domercado e discriminar esses usuários. É por isso que falamos que a Web é mais democrática, aberta e acessível. Experiência do usuário Há diferenças fundamentais entre Apps e Web sob a ótica da experiência do usuário e de usabilidade. E, na minha opinião, esse acaba sendo o fator mais de- terminante na hora de escolher qual estratégia seguir. Argumentos comuns que as pessoas levantam, como performance e acesso a hardware, pra mim são irrelevantes na maioria dos cenários. Poucos casos exigem performance altíssima ou acesso a tudo que é hardware do aparelho. A maioria dos projetos é mais simples que isso e funcionaria bem tanto na Web quanto em App. Mas a diferença na experiência do usuário é algo sempre presente. A Web tem várias vantagens de usabilidade em relação a Apps. O usuário pode selecionar o texto facilmente, pode dar zoomà vontade (mais sobre isso no tópico 12), pode criar favoritos e atalhos para páginas específicas, pode clicar em links e navegar à vontade no navegador. Apps costumam ser mais limitadas nesses pontos — não posso favoritar uma tela, compartilhar links com as pessoas, dar zoom livremente. Mas, mesmo com tudo isso, a questão principal é que a experiência de uso de uma App é diferente da de um site. Como usuário, você sabe quando está usando uma App ou navegando num site. Ambos podem ter o mesmo conteúdo e prover as mesmas funcionalidades, mas a experiência de uso ainda assim é diferente. É importante conhecer bem o escopo do projeto e as expectativas do seu grupo 19 Casa do Código a confusão é grande com essa modinha de ‘HTML 5’. Precisamos definir bem, justo pra entender o que não é Web. Web não é só usar HTML 5, CSS e JavaScript — até porque podemos fazer si- tes em outras linguagens, como Flash, embora seja cada vez menos comum. Web é a soma de uma rede em cima de HTTP com a capacidade de se criar links entre páginas, em um formato padronizado, o HTML. Web é estar conectado na Internet e carregar suas páginas de um servidor em qualquer lugar do mundo. E, seguindo links, navegar pra todos os cantos. Que fique claro: HTML 5 é só a linguagem usada na Web. Não é aWeb. Reaproveitamento de linguagens Com a Web explodindo em popularidade, o mundo se viu infestado de progra- madores HTML, CSS e JavaScript. Mas nem só de Web é feita a programação. Por isso, existem diversas linguagens focados em servidores, programas Desktop, apare- lhos embarcados etc. Até que caiu a ficha de muita gente: se já aprendemos as linguagens HTML, CSS e JS por causa da Web, será que não seria melhor usar essas mesmas linguagens em outras situações e evitar ter que aprender novas? Excelente ideia, apesar da confusão que isso criou. Se alguém fala que é um programador JavaScript, você não pode simplesmente inferir que ele manja tudo de jQuery. Pode ser que ele nem programe o front-end, mas foque em programas no servidor usando Node.JS. É preciso, então, diferenciar bem os usos que são feitos dessas linguagens hoje em dia. HTML, CSS e JavaScript em todo lugar O JavaScript é usado comumente hoje em duas situações: • Em companhia doHTML,CSS, renderizando numnavegador ou equivalente; • No servidor, como linguagem de programação de uso geral em plataformas como Node.js ou Rhino. Seguindo o caminho onde usamos JavaScript junto com HTML e CSS, que é o que nos interessa neste livro, temos mais duas divisões onde podemos usar esse trio de linguagens: 22 Casa do Código Capítulo 4. HTML 5 é diferente de HTML 5: o caso das packaged apps • NaWeb, rodando no navegador do cliente após um acesso no servidor. Pode- mos falar de um Site comum ou umaWebAppmais complicadinha; • Em Apps empacotadas (packaged apps), seja emmobile ou desktop. Resumindo, graficamente: Packaged Apps A grande novidade do burburinho que se faz em torno de HTML 5 hoje em dia são essas packaged apps. Você programa a aplicação emHTML, CSS e JavaScriptmas em arquivos locais na sua máquina, sem subir para um servidor. Aí você empacota tudo isso numa App que depois será executada no aparelho como uma aplicação normal. Por baixo dos panos, a plataforma de execução vai usar uma espécie de browser pra ler esses arquivos e montar a tela. É o que o pessoal chama de WebView, uma forma de embutir só o mecanismo de execução do browser sem a parafernália toda do navegador completo — barra de endereços, configurações do usuário, favoritos etc. É, basicamente, só um renderizador de HTML. Essas packaged apps estão em todo lugar hoje em dia. O PhoneGap é uma ferra- menta de empacotamento que gera Apps para várias plataformas a partir de um có- digo HTML comum (ele suporta iOS, Android, Blackberry, Windows Phone, Bada, Symbian eWebOS). Parece simples, mas não é. É preciso gerar um binário para cada plataforma que você tiver interesse e, depois, publicar na loja específica de cada uma. 23 Casa do Código Outras plataformas já estão sendomontadas com a ideia de packaged apps embu- tida diretamente. O Firefox OS é um exemplo disso. Você escreve tudo em HTML, cria umarquivo de configuração simples e gera umZIP pronto pra instalar. Windows Phone 8, Tizen eBlackberry 10 são outros exemplos de suporte direto a packaged apps em HTML. No Desktop, essa ideia já existe há anos também. As extensões que instala- mos nos navegadores como Firefox e Chrome são escritas emHTML e empacotadas como extensão (e depois publicadas nas respectivas lojas). OChrome tem tambémas Chrome Apps que são, de novo, aplicações HTML empacotadas e distribuídas naCh- romeWeb Store. O novoWindows 8 fez um estardalhaço como primeiro grande sis- tema operacional Desktop a suportar desenvolvimento de Apps nativas em HTML, CSS e JavaScript. Mas muitos outros seguem essa ideia — como o Chrome OS e o Gnome no Linux. No mundo mobile, outro termo comum de se ouvir para essas Apps HTML 5 empacotadas é Hybrid Apps (aplicações híbridas). E, claro, por ser um HTML ro- dando numa espécie de browser, você também pode carregar páginas externas do seu servidor dentro da App. Nem todo código HTML precisa estar empacotado na App original. HTML 5 é diferente de HTML 5 É importante diferenciar o que é usar HTML 5 (e CSS e JS) na Web do que é usar HTML 5 pra escrever packaged apps. As Apps, mesmo escritas em HTML, têm todas as características (e limitações) de qualquer App, como discutimos antes. O fato de se usar HTML pra escrevê-las só alivia o fato de ser uma linguagem comum e o desenvolvedor não precisar aprender uma linguagem específica da plataforma— Objective-C no iOS, Java no Android, C# no Windows Phone etc. UsarHTML 5 como base para Apps também traz um certo nível de portabilidade e facilidade para suportar múltiplas plataformas. Mas cuidado que isso engana. Ao escrever uma App em HTML 5 pro Windows Phone, por exemplo, você vai usar as linguagens comunsmasmuitas APIs específicas daMicrosoft. Mesma coisa se você for criar uma App pro Firefox OS ou pro PhoneGap. A linguagem é comum emuitas APIs mais simples são as mesmas, mas coisas mais complicadas são específicas de plataforma. E isso, claro, limita a portabilidade. Já quando falamos de Web, falamos de uma especificação comum guiada pelo W3C e pelos navegadores. Falamos de padronização de APIs e linguagens. Isso sim é portabilidade total. Mas, claro, sabemos que apesar da mega evolução, o HTML 24 Capítulo 5 Design Responsivo por umaWeb única A comunidade de desenvolvedores Web compartilhou durante muito tempo um gi- gantesco delírio coletivo. Uma ilusão absolutamente falsa mas que se impregnou de tal forma que todo mundo achava que era verdade. Eu mesmo participei dessa alucinação coletiva durante muitos anos. Estou falando da ilusão de que aWeb tem tamanho fixo. Falar hoje que a Web é uma mídia flexível e adaptável soa trivial. Mas, durante anos, o comum na Web eram as páginas de tamanhos fixos. Discutíamos qual era o melhor tamanho pra fazer as páginas. Seria 960px de largura? 980px? Lembro até hoje da mudança nos sites quando a resolução mais comum dos monitores deixou de ser 800px e passou a ser 1024px. Mas, sempre tivemos monitores de 800px de largura, assim como 1024px. Hoje, as resoluções de 1280px e 1366px são asmais comuns. Masmuita gente usa resoluções maiores, com 1600px ou 1920px. Nossos sites fixos nunca levaram isso em conta. Casa do Código Programávamos pra resolução mais comum e esquecíamos o resto. Nossos designs eram pixel perfect — copiados pixel a pixel do desenho original do Photoshop. Isso é ridículo. Isso não é a Web portável, acessível e universal que gostaríamos. AWeb é flexível Design responsivo nada mais é que (re)lembrar que aWeb é umamídia flexível e adaptável. O vergonhoso é pensar que aWeb sempre foi assim, nós que colocamos as restrições em nossas páginas. Muita gente fala disso há tanto tempo: o seminal artigoADaoofWebDesign, de JohnAllsopp, publicado em 2000 noAList Apart (http://alistapart.com/article/dao), é leitura obrigatória. No início do milênio, ele já falava: “O controle que os designers conhecem na mídia impressa, e constantemente de- sejam na web, é simplesmente em função da limitação da página impressa. Devemos abraçar o fato de que a Web não tem as mesmas restrições, e projetar para essa flexibi- lidade.” Ou seja, a mídia impressa que é limitada, a Web não. Tão óbvio. Esse mesmo artigo ainda falava: “Faça páginas que são acessíveis, independentemente de navegador, plataforma ou tela que seu leitor escolha ou tenha que usar para acessar suas páginas. Isso significa páginas que são legíveis independentemente da resolução ou tamanho da tela, ou do número de cores.” É quase impossível imaginar que ele não estava falando das novas páginas res- ponsivas que abrem tanto no celular quanto no Desktop. Não, ele escreveu isso em 2000, clamando que focássemos em flexibilidade nas nossas páginas, pois a Web é e sempre foi assim. Demorou uma década pra cair a ficha. Mas, antes tarde do que nunca. Design Responsivo Você certamente já viu diversos sites responsivos por aí. São aquelas páginas que se adaptam a todo tipo de dispositivo. Você abre amesma página no celular, no tablet e no Desktop, e ela se adapta pra melhorar a experiência do usuário. Vamos explorar depois todos os aspectos técnicos dessas soluções aqui no livro, mas foquemos agora nos aspectos estratégicos. O termo Web Design Responsivo surgiu num artigo divisor de águas publi- cado em 2010 por Ethan Marcotte no A List Apart (http://alistapart.com/article/ 28 Casa do Código Capítulo 5. Design Responsivo por umaWeb única responsive-web-design)—não por acaso, a frase de abertura é uma citação do artigo A Dao of Web Design que vimos antes. Pouco tempo depois, o próprio Ethan publicou um livro aprofundando as ideias — tenho um review sobre ele no meu blog: http://sergiolopes.org/ review-responsive-design-ethan-marcotte/ A ideia pra palavra ‘responsivo’ veio da arquitetura, na qual se fala de técnicas para construções e materiais de adaptarem ao ambiente e às pessoas que interagem com ele. Aí o Ethan fala: “Ao invés de criar designs desconectados para cada um do crescente número de dis- positivos web, nós podemos tratá-los como faces da mesma experiência. Podemos criar para uma experiência de visualização ideal, mas embutir tecnologias padronizadas nos nossos designs para fazê-los não apenas mais flexíveis, mas mais adaptados para a mídia que os renderiza.” A chave pro design responsivo é fazer um design flexível e adaptável, que se ajuste às características do navegador, do dispositivo e do contexto do usuário. Os pilares técnicos das soluções responsivas são o layout fluído (tópico 8), o uso de media queries (tópico 9) e de imagens flexíveis (tópico 19). Vamos lidar detalhadamente com cada um desses pontos nos tópicos seguintes do livro. O conteúdo é o que importa Háquemdiga que é impraticável oferecer omesmo site para todomundoporque, quandonavegamos em telas pequenas, queremos conteúdomais focado e páginasmais simples e diretas. É absolutamente verdade que usuáriosmobile têmmenos paciência para páginas grandes e carregadas, mas isso não inviabiliza um design responsivo. A chave é a priorização de conteúdo. É preciso repensar todo o conteúdo para descobrir o que realmente importa, e remover todo o excesso. Uma página mobile não deve ser apenas um design menor, mas uma completa reestruturação de con- teúdo. Por isso que só adaptar o design de um site Desktop já existente dificilmente funciona. E, se você já gastou um bom tempo cortando coisas secundárias e priorizando o importante, por que oferecer essa versão mais simples e funcional apenas para usuá- rios mobile? Por que temos mania de pensar que usuários Desktop devem receber páginas cheias de informações inúteis? Responsive design é entregar a mesma informação — útil e priorizada — para todo mundo! 29 Capítulo 6 Mobile-first Convencido do tamanho gigantesco do mercado mobile e de que a Web é uma só pra todo mundo, você decide investir no design responsivo. Ótimo passo. Hora de tomar a próxima decisão: por onde começar? Em especial, na hora de criar meu site ou webapp, começo pensando primeiro no Desktop ou primeiro nos dispositivos móveis? Vou precisar cobrir tudo, claro, mas por onde começar? E é tão importante assim definir por onde começar? Mobile é diferente Amaior diferença entre um dispositivo móvel e umDesktop é o espaço disponí- vel para o conteúdo. A área útil da página. Claro que sempre dá pra dar scroll, mas é fato que cabe menos informação no celular que na telona do computador. Além do tamanho, há outras diferenças, como o contexto de uso do dispositivo. Um celular é muito mais flexível e pode ser usado em muito mais situações que um Desktop: posso estar na rua, no carro, na fila do banco, em casa no sofá, deitado na cama, assistindo TV, usando o banheiro. Casa do Código Poderíamos falar também da tendência dos dispositivos móveis terem touch screen, o que é quase onipresente já. Mas, como vamos discutir no tópico 23, isso não é mais um diferencial, já que notebooks e monitores com touch são cada vez mais comuns. Mas fato é que há diferenças claras no uso de aparelhos móveis em comparação ao uso do Desktop. Mais ainda: mobile não é só diferente, parece ser tambémmais limitado. Tela menor, rede lenta, hardware mais lento, touch menos preciso que mouse, etc. Dispositivos móveis trazem mais liberdade de uso mas trazem também novas restrições que não pensávamos antigamente no Desktop. Como lidar com isso? Abrace as restrições É muito mais fácil começar seu design tendo em mente as restrições do mobile e depois evoluir para o modo Desktop que é menos limitado. O contrário é bem mais trabalhoso: criar no Desktop sem restrições e tentar limitar depois conforme for adaptando para o mobile. Em termos práticos: um design mobile-first nos obriga a focar mais e a prio- rizar melhor o conteúdo. Abraçando as restrições do mobile, acabamos chegando em um design mais simples e funcional, já que não há muito espaço para enrolação. Aí quando evoluímos o design para a versão Desktop, o resultado é também uma interface mais focada e todo mundo ganha. O caminho inverso é bemmais difícil. Pelo Desktop ser bemmenos restrito, aca- bamos enchendo a páginas de coisas sem problemas. Quando tentamos transformar em mobile, o design começa a parecer exagerado e é bem difícil encaixar tudo. Criar um design mobile-first é focar no principal, e isso não é fácil. É bem mais fácil fazer uma interface cheia de coisas que uma interface simples que atinja o mesmo objetivo. Bons designs, porém, são simples e funcionais; e pensar primeiro no mobile te ajuda a chegar nisso. E já que você vai conseguir chegar num produto bom e focado no mobile, pode usar o mesmo na versão Desktop. Aliás, não é porque o Desktop tem mais espaço que devemos entupi-lo de coisas. Telasmaiores não significamumavontade do usuá- rio de ver mais tranqueiras. Interfaces simples e focadas são melhores em todas as situações. Mas claro que isso também não significa desperdiçar o espaço fantástico do Desktop. Queremos um design simples e conteúdo focado, mas também queremos 34 Casa do Código Capítulo 6. Mobile-first E o termo em si —mobile-first — nasceu em um post em 2009 pelo especialista mobile LukeWroblewski (http://www.lukew.com/ff/entry.asp?933) no qual ele falava mais da ideia de design e foco. Depois, ele mesmo lançou um livro com esse título onde abordou melhor essas ideias com muitos exemplos práticos de usabilidade e design. É um livro muito bom e interessante — você pode ver meu review aqui: http://sergiolopes.org/review-livro-mobile-first-luke-wroblewski/ 37 Capítulo 7 Mercado, Browsers, suporte e testes Escrevi na introdução do livro que não pretendo falar de números específicos do mercado mobile, já que eles ficariam desatualizados rapidamente. O que interessa, claro, é o seu mercado, da sua aplicação. Todo projeto Web precisa definir uma política de compatibilidade dos navega- dores. Por mais que falemos daWeb única e universal, sabemos que há navegadores de toda qualidade espalhados por aí. E, na maioria dos cenários, não é viável finan- ceiramente tentar alcançar o suporte a todos. É preciso deixar alguns de lado. Mas como traçar essa linha? Como definir os navegadores que recebem suporte oficial? Você precisa ver os dados do seu público, analisar as estatísticas do site em ques- tão. Para isso, você vai usar alguma ferramenta de coleta de dados como o Google Analytics. Observe atentamente as informações reais do seu cenário pra tomar as melhores decisões para o seu público. Se você estiver iniciando um projeto novo, recomendo olhar as estatísticas da região em questão no Stat Counter (http://gs.statcounter.com/) e definir um grupo Casa do Código • Samsung Galaxy 5 de 2,8” com Android 2.2 oficial Samsung e pixel ratio 0.75; • iPod Touch 4 de 3,5” com tela retina e iOS 6; • iPad 2 de 9,7” com iOS 6.1; • Nokia XpressMusic com Symbian S60 bem velho. Essa lista é minha, pessoal, com base nos meus projetos, nas minhas limitações e necessidades. Não coloquei pra você copiar, mas para ter uma ideia de como eu me virei. E, mesmo assim, ainda sinto falta de ter umWindows Phone (tenho planos para comprá-lo em breve), um celular com teclado físico e talvez um iPad Mini e outro tablet Android. Instalando os browsers No Android, você vai provavelmente instalar vários browsers para testes. O browser padrão do Android e o ChromeMobile são osmais usados. Mas há algumas pessoas usando FirefoxMobile ouOperaMobile. O Firefox pode ser importante se o Firefox OS realmente decolar, já que seria omesmo browser dessa versão do Android (podemos economizar na compra de um aparelho!). Figura 7.1: Lista dos browsers instalados no meu celular Android, incluindo os beta. No iOS, o cenário é mais simples já que só oMobile Safari da Apple é permitido. Até existem outros browsers, como o Chrome, mas ele é na verdade o motor de ren- 42 Casa do Código Capítulo 7. Mercado, Browsers, suporte e testes derização do Safari com cara de Chrome. A Apple não permite renderizadores de outros browsers— por isso, não temos Chrome de verdade ou um Firefox ou Opera. Há alguns proxy browsers (que renderizam no servidor), como o Opera Mini e o UC, mas você precisa antes ver se vai realmente suportá-los. No Desktop, você vai ter que instalar algumas versões do Chrome, Firefox e Opera. O Safari é importante, mas só está disponível para Mac. E o Internet Ex- plorer, claro, só no Windows. Então, na prática, você sempre vai precisar de umas máquinas virtuais pra rodar navegadores de outras plataformas (ou use vários com- putadores). No caso do Internet Explorer, a boa notícia é que a Microsoft oferece gratuita- mente para desenvolvedores Web máquinas virtuais de testes. Eles têm máquinas virtuais prontas pra se rodar no Windows, Mac ou Linux, executando Windows XP, Vista, Windows 7 e Windows 8, com todas as versões do IE desde o 6. É só baixar e rodar (http://www.modern.ie/virtualization-tools). Emuladores para mobile Como você nunca vai ter condições de comprar todos os aparelhos do mercado, o uso de emuladores pode ser interessante. Há emuladores excelentes, como o do iOS, comos quais você pode simular iPho- nes e iPads de todos os tamanhos, rodando iOS desde o 4.x até o mais recente. O ponto negativo é que você precisa de um Mac pra isso. Mas os emuladores em si são muito bons e rápidos de ligar. Você pode testar todo tipo de suporte do Mobile Safari. Única limitação é não conseguir testar as interações touch e a experiência real do usuário com o aparelho. Por isso, é bom ter um outro dispositivo real com iOS também, e só usar os emuladores pra testar os browsers de versões diferentes. Para Android, há emuladores gratuitos que o Google disponibiliza. Dá pra rodar em qualquer sistema operacional, mas não é a coisa mais fácil de instalar. Eles são mais pesados e demorados para rodar. Como eu tenho 5 aparelhos Android no meu lab, não costumo usar muito os emuladores Android pra testar páginas Web. Mas eles são uma opção caso você precise testar versões diferentes dos aparelhos que você tiver. OWindows Phone também tem emuladores que você pode instalar. Eles rodam bem emWindows nas máquinas mais novas da Intel. Dá pra rodar no Mac virtuali- zando, mas ficam bem pesados e exigem uma máquina com pelo menos um Core i5 por restrições nas instruções de virtualização do processador. Já o Firefox OS é, na verdade, um sistema todo baseado no Firefox. Então, é bem 43 Casa do Código fácil de testar. Você instala o Firefox normal no Desktop e depois o emulador do OS em cima dele. Ele roda rápido e sem problemas, com a vantagem de estar dentro do browser e te permitir usar Firebug e inspector diretamente. Há emuladores para outras plataformas também, que você pode pesquisar me- lhor conforme a necessidade. Minha dica geral é usar emuladores como um suporte para sua estratégia de de- senvolvimento, para não precisar rodar sempre no aparelho. Eu costumo ir desen- volvendo noDesktop, usando emuladores, e só rodo nos aparelhos quando o projeto estiver mais estável. Mas, lembre, é importante sempre rodar em aparelhos reais pra você pegar a experiência real do usuário, sobretudo com relação à performance, à estabilidade e à interação. Debug em browsers mobile Amaior dificuldade de se desenvolver em mobile é debugar as páginas rodando nos aparelhos. No Desktop, basta instalar uma extensão como Firebug ou usar o próprio Inspector do navegador (como o Chrome Developer Tools). Nos browsers mobile, é bem mais complicado porque geralmente você quer abrir o navegador no aparelho mas debugá-lo no Desktop (não faz muito sentido abrir um debugger na telinha do aparelho). A mais fácil de todas é o iOS a partir da versão 6 se você tiver um Mac. Basta habilitar a opção de debug no Mobile Safari, conectar o cabo USB no computador e ir nomenuDevelop no Safari doMac. Lá, você consegue abrir um inspetor associado ao navegador do aparelho (e funciona até com o emulador local). 44 Parte II Programando a Web moderna + ao , 1 Pd t —> = 5 Capítulo 8 Flexibilidade na Web com layouts fluídos A grande estrela de um web design responsivo é o layout fluído. Isso quer dizer não usar medidas fixas como pixels (ou pontos, centímetros, milímetros etc) pra programar o design. Não dá mais pra copiar as medidas no Photoshop da imagem estática que o designer criou com o layout do site. Layout fluído é usar medidas flexíveis e é tão velho quanto o HTML em si. Medidas flexíveis As duas medidas flexíveis mais usadas são as porcentagens e o em. As porcen- tagens são usadas pra especificar medidas de tamanho com relação ao tamanho do elemento pai. body { /* a página ocupa a largura da tela toda */ width: 100%; Casa do Código • O p vai ter 20px * 0.9 = 18px. Um poderoso recurso para aumentar ou diminuir o design proporcionalmente é mudar o font-size do elemento pai—por exemplo, mudando o article e afetando o h1 e o p. Nova medida: rem O em é bem flexível mas, se tiver muitos níveis de elementos, todos mexendo no font-size, é difícil controlar o valor final do em. E qualquermudança num elemento lá no meio afeta seus filhos. Existe uma outra medida, a rem, que também é flexível como o em mas não é afetada pela hierarquia de elementos pai-filho. O rem vem de root em e significa um em proporcional apenas ao elemento raiz (a tag <html>). Na prática, isso significa que 2rem sempre serão relativos ao tamanho da fonte base do documento (os 16px iniciais), e não interessa onde o elemento está na página. Se pegássemos o mesmo código anterior e mudássemos em pra rem, o resultado seria: • O html e o body vão ter os 16px base; • O article terá 16px * 1.25 = 20px; • O h1 tem 16px * 2 = 32px; e • O p vai ter 16px * 0.9 = 14px. O rem ainda é flexível, mas você precisa mudar o font-size do elemento html pra afetar os valores dos filhos. É útil em algumas situações onde o em parece compli- car demais. O suporte nos navegadores é bastante bomhoje e a única grande exceção é o IE 8 e anteriores (http://caniuse.com/rem). Existem outras unidades de medidas flexíveis que não citei ainda. Em medidas textuais, existem, além do em e do rem, a ch e a ex. Elas são muito específicas e com pouco suporte então não nos interessa muito agora. Já uma medida nova quem tem ganho bastante destaque são as viewport units, com vw e vh. É bem simples: 1vh é equivalente a 1% da largura da janela do nave- gador. Com ela, você pode, por exemplo, fazer uma tipografia que escala proporci- onalmente ao tamanho do browser, excelente pra design responsivo. Um exemplo: 52 Casa do Código Capítulo 8. Flexibilidade na Web com layouts fluídos h1 { font-size: 3vw; }. O suporte ainda é pequeno nos navegadores mas tem crescido rapidamente (http://caniuse.com/viewport-units). Fique de olho para usar num futuro bem próximo. Importante são as proporções Mas você provavelmente já conhecia as medidas flexíveis e porcentagens e em. O difícil é usar as medidas flexíveis de maneira eficaz e sem ficar louco. Pelo menos eu tive bastante dificuldade no início, principalmente depois de anos acostumado a medidas fixas e a copiar os tamanhos direto do Photoshop. Osegredo de um layout commedidas flexíveis é pensar na proporção entre os elementos. É treinar o olho pra enxergar as relações de espaço entre os elementos da página ao invés dos tamanhos fixos do layout. Analise esse design e observe a seção com as 4 notícias: O primeiro passo seria resistir e não abrir o Photoshop paramedir o tamanho de cada bloco. Você tem que olhar para esse desenho e enxergar um painel de notícias dividido em4 pedaços. Não importa se o design de cada notícia tem 200px ou 300px. Em CSS, estamos falando de algo assim: 53 Casa do Código .noticia-secundaria { width: 25%; float: left; } Estabelecemos que as notícias listadas naquele painel de baixo ocuparão um quarto da área disponível. Não interessa o tamanho da tela ou da janela do nave- gador: a proporção é estabelecida na porcentagem e o tamanho final é recalculado pelo navegador automaticamente. Figura 8.1: Exemplos desse grid flexível simples pra você testar: http://sergiolopes. org/m0 Esse exemplo é bem simples. O difícil é treinar a cabeça a pensar sempre em porcentagens e proporções, aindamais se você vem de anos de web design em pixels, como eu vim. Nas fontes é a mesma coisa. Você precisa olhar para o design e enxergar que o título principal é 50% maior que o título secundário e estabelecer essa relação no código. Ou seja, uma notícia terá tamanho 1em e a outra, 1.5em. Se alterarmos a fonte base da página, todas as medidas em emmudam junto, proporcionalmente. Dica de CSS: box-sizing Responda rápido: se eu tiver duas section com texto, o CSS a seguir vai fazer um layout em 2 colunas de largura igual? section { float: left; padding: 5%; width: 50%; } 54 Casa do Código Capítulo 8. Flexibilidade na Web com layouts fluídos Imagine o design das 4 notícias que fizemos antes em um monitor gigante com 4000px de resolução. Vai funcionar, vai ficar tudo em 4 colunas, mas com umdesign bizarro e mega espaçado. É bem comum que queiramos um layout fluído e flexível mas com certos limites em casos específicos. A propriedade max-width do CSS é bem útil nesses casos. Podemos aplicá-la no body pra restringir o tamanho da nossa página a, no máximo, um certo tamanho: body { max-width: 2000px; margin-left: auto; margin-right: auto; width: 100%; } No caso de um browser gigante, nosso design fixa em 2000px e fica centralizado na tela. Claro que o ideal, pensando em flexibilidade total, seria não ter essa restrição e deixar tudo fluir. Mas o ideal também seria nosso design de adaptar e ficar bonito também nessas resoluções gigantes. E nem sempre é o caso. Nem sempre vale a pena programar o design pra tantas resoluções diferentes e precisamos focar. Se você fizer o layout totalmente flexível e fluído até 2000px, vai atingir 99% do mercado atual. E as telas mega gigantes ganham um site funcional, limitado a 2000px. É bom pra todo mundo. Tenha o max-width (e o min-width) na manga quando precisar colocar certas restrições no layout. Evite, claro, abusar disso. Não vá colocar um max-width:800px sabendo que os Desktops de hoje são bem maiores que isso. Escolha um valor que faça sentido no seu projeto. Omais importante é que esse max-width é uma regrinha amais apenas com uma restrição final no design. Todo o resto você vai fazer fluído e em porcentagens. Ou seja, se um dia precisar atingir mais resoluções ou quiser ir pro caminho do 100% fluído, basta remover ou trocar seu max-width. Aliás, hoje eu costumo desenvolver usando medidas flexíveis até os sites de ta- manho fixo. Às vezes, o projeto ou cliente quer um tamanho fixo em 960px, por exemplo. Nem por isso saio usando pixels no CSS todo. Podemos fazer tudo em porcentagens e em, e só colocar um body { width: 960px; } no final. No dia em que o cliente decidir pelo fluído, é só tirar essa restrição do body. Além disso, porcentagens podem ser bem mais legíveis que pixels — é bem mais claro dividir essa página de 960px em 5 colunas usando um width: 20% do que olhar pra width: 192px e enxergar as 5 colunas. 57 Capítulo 9 Media queries: as melhores companheiras de um layout fluído Na apresentação do design responsivo, o pai da técnica, Ethan Marcotte, falava de 3 componentes: layout fluído, media queries e mídias flexíveis. Muita atenção se dá para as media queries, mas o central é o layout fluído, por isso dediquei o tópico anterior inteiro a isso. Mas, claro, o design fluído não resolve todos os problemas. Aí que as media queries entram. Elas são essenciais para um bom design responsivo. As limitações do layout fluído Uma página construída com medidas flexíveis é totalmente fluída e já está 90% no caminho de um design adaptável a todo tipo de tela. Mas é difícil fazer tudo ficar bonito e ajustado a todo tipo de resolução só com porcentagens e em. Pegue o design do tópico anterior, que tem 4 notícias divididas com width:25%. O site vai funcionar no celular, mas fica bem estranho dado o pequeno tamanho da Casa do Código que só serão aplicadas caso a condição seja válida. No exemplo, o (max-width: 400px) indica que só vamos aplicar o CSS em questão quando a janela do nave- gador tiver, no máximo, 400px. Você pode testar redimensionando o navegador no Desktop ou abrindo no celular (que costuma ter tela com largura de 320 ou 360px). Media queries são o ponto central da capacidade de adaptação dos designs res- ponsivos. São essenciais em projetos que envolvem dispositivos móveis mas ganha- ram seu espaço até em soluções puramente Desktop. São uma das principais ferra- mentas do desenvolvimento Web moderno. Breakpoints Mas, claro, é inviável criar umamedia query para cada tamanho de tela existente no mundo, por isso a importância do layout fluído. Usando medidas fluídas, seu design se adapta naturalmente a várias resoluções e, só quando necessário, as media queries entram, pontualmente, para ajustar o design e melhorar a experiência do usuário. Esse ponto em que decidimos colocar uma media query é chamado de break- point. É o ponto de quebra do nosso layout fluído onde uma reestruturação maior é necessária. No nosso exemplo, podíamos ainda colocar mais uma media query com outro breakpoint intermediário. Já temos o layout em 4 colunas nas telas grandes e em 1 co- luna nas telas pequenas. Podemos adicionar um design em 2 colunas num tamanho de tela intermediário: @media (max-width: 600px) { .noticia { width: 50%; } } 62 Casa do Código Capítulo 9. Media queries: as melhores companheiras de um layout fluído Figura 9.2: URL do exemplo: http://sergiolopes.org/m2 Podemos colocar várias media queries, com condições diferentes, no meio do nosso CSS. A ordem, porém, é importante, já que a regra que vem por último so- brescreve a anterior. Além de max-width, podemos usar a min-width nas media queries. Essas são, sem dúvida, as media queries mais usadas e as que você mais vai ver na prática. Há algumas outras, porém, que podem ser interessantes pontualmente. Outras media queries e por que você não vai usá-las Você pode também colocar uma media query com valor exato ao invés de max/min, usando algo como (width: 320px), mas isso é bem inútil na prática. Só vai pegar telas com tamanho exato de 320px, restringindo a fluidez do design. Existe a media query device-width (e as versões commax/min), que representa o tamanho da tela do aparelho. Isso é diferente de usar o width normal, que repre- senta o tamanho da janela do navegador. Na maioria dos celulares, esses valores são 63 Casa do Código equivalentes já que o navegador é sempre em tela cheia. Mas existem navegadores mobile que aceitam ser redimensionados, assim como no Desktop. Na maioria dos casos, você não está interessado no tamanho da tela, mas sim no tamanho do nave- gador. Para todos os casos que usamos width (commax, min, device), também é possí- vel usar height. Essa media query pode ser útil em alguns casos, mas 99% das vezes você está mais interessado na largura e não na altura do navegador. Isso porque a Web é uma mídia que flui verticalmente e o comprimento da página não interessa tanto. Além de controlar tamanhos, é possível usar media queries que representem capacidades e características do navegador. A mais útil é a orientation que pega a orientação do aparelho — podemos usar (orientation: portrait) ou (orientation: landscape). Você pode usá-las para otimizar o design de acordo com a forma que o dispositivo é segurado. Há outras media queries ainda mais específicas, com uso limitado, e pouco su- porte nos navegadores. Não vamos discutir muito aqui, mas você pode consultar: https://developer.mozilla.org/docs/CSS/Media_queries Na esmagadora maioria dos casos, você vai usar apenas max-width e min-width. Operadores nas media queries Podemos usar a palavra and para fazer umE lógico. No exemplo a seguir, amedia query só será avaliada se ambas as condições forem verdadeiras ao mesmo tempo: @media (max-width: 600px) and (orientation: portrait) { } Fazer um OU lógico é equivalente a separar várias media queries por vírgulas, comonoCSSnormal. Nopróximo exemplo, omesmoCSS será aplicado caso alguma das duas condições seja verdadeira: @media (min-width: 300px), (min-height: 300px) { } É possível também negar umamedia query usando a palavra chave not no início dela. 64 Capítulo 10 Tudo que você queria saber sobre viewport Entender como os elementos que você cria na sua página vão ser desenhados na tela é essencial. Muita coisa acontece dentro do navegador e uma delas, importantíssima, é a forma como as medidas são calculadas e exibidas pro usuário. Faz algum tempo que simplesmente colocar um width:100px num elemento não vai necessariamente fazê-lo ocupar 100 pixels na tela. Um pixel não mede um pixel. Por mais estranho que pareça agora, o tamanho de um pixel depende de uma série de fatores. E os navegadores dos dispositivos móveis trouxeram ainda mais questões a serem consideradas. Telas pequenas, alta resolução, retina, zoom, view- ports. Vamos entender tudo isso. Um pixel num navegador normal no Desktop O normal é você criar uma página, dar os tamanhos dos elementos e eles serem Casa do Código desenhados na tela ocupando exatamente esse tamanho. Coloque um logotipo de 300px de largura e ele ocupará 300px da tela física do computador. Isso é normal. Se colocar algum elemento medido em porcentagem, ele tem seu tamanho calculado em pixels proporcionalmente ao tamanho da janela do navegador. Tudo isso funciona ok num cenário normal no Desktop. Você pode até des- cobrir o tamanho da tela do computador usando, em JavaScript, screen.width e screen.height— vai devolver, digamos, 1280 e 768. Aliás, essa medida é, 99% das vezes, bastante inútil pra desenvolvedores Web. Estamos mais interessados no ta- manho do navegador que no tamanho da tela, afinal o navegador pode não estar maximizado. Você pode pegar o tamanho disponível no navegador com window.innerWidth ou ainda com window.outerWidth se quiser considerar a janela toda (incluindo barra de ferramentas, barra de endereços etc). Figura 10.1: Tamanho da tela e do viewport do navegador no Desktop. O viewport O espaço disponível para a página ser renderizada no navegador é o que chama- mos de viewport. Ele depende do tamanho da janela do navegador e desconsidera as 68 Casa do Código Capítulo 10. Tudo que você queria saber sobre viewport barras de ferramenta, barra de rolagem, navegação etc. É aquele espaço em branco onde a página abre e, como vimos, podemos medi-lo com window.innerWidth e window.innerHeight. Num navegador hipotético em tela cheia que não tenha nenhuma barra de fer- ramentas e só mostre o conteúdo da página, é claro que o tamanho do viewport (window.innerWidth) é igual ao tamanho da tela (screen.width). Certo? Não, de- pende. O zoom de página Todo navegador moderno permite que o usuário dê zoom na página. É um re- curso essencial para acessibilidade — nem sempre o usuário tem visão perfeita, e nem sempre o desenvolvedor deixou as coisas com tamanhos grandes e legíveis. Es- tamos falando aqui daquele zoom dos navegadores Desktop (esqueça mobile por enquanto), que geralmente você acessa usando Ctrl + / Ctrl - (ou usando Cmd no Mac). Pense: se você der zoom de 200% na página, o que você espera que aconteça com aquele logotipo que ocupava 300px na tela? Claro que você espera que ele fique com o dobro do tamanho e seja desenhado ocupando 600px da sua tela. Isso que o zoom de página faz, aumenta tudo de tamanho. Mas e o código da sua página, muda quando o usuário da zoom? Obviamente, não. Você continua escrevendo que a imagem tem width:300px mas o navegador sabe que, agora, deve desenhá-la ocupando 600px, já que o zoom foi de 200%. Ou seja, um pixel não é mais um pixel. Você escreve 300px mas ele é desenhado com 600px. Confuso? A questão aqui é que estamos falando de pixels diferentes. Chamamos de pixel físico (ou device pixel) aquele menor ponto na sua tela que pode receber uma cor. E chamamos deCSS pixel aquela medida que você escreve no seu código usando o px. E eles são diferentes! Na verdade, na maioria dos casos, um pixel físico é igual a um CSS pixel. Mas, quando o usuário dá zoom, as coisas mudam. Um zoom de 200% faz 300 CSS pixels serem renderizados como 600 pixels físicos. A regra é que número de pixels físicos = número de CSS pixels × zoom. O viewport muda com zoom Ao dar zoom, as coisas ficam maiores e cabe menos informação na tela. A tela 69 Casa do Código Zoommobile e os dois viewports Claro que o site Desktop aberto no celular fica bem difícil de usar. Ele abre pe- quenininho mas o usuário depois faz o gesto de pinça (pinch) pra fazer um zoom e ver o pedaço da tela que interessa. Repare, porém, que esse gesto de zoom que fazemos no smartphone é diferente daquele zoom que fazemos no Desktop. Esses modos de zoom são tão diferentes que damos nomes diferentes pra eles. O que fazemos no celular chamamos de redimen- sionar página (page scale) e o do Desktop é zoom de página (page zoom). O page scale no celular só dimensiona o pedaço visível da página, ele não altera o design da página. O site continua renderizado igualzinho e o gesto de pinça só faz a gente observar um pedaço específico. É diferente do page zoom no Desktop, que aumenta o tamanho dos elementos e renderiza novamente a tela. Em outras palavras, o page zoom altera o tamanho do viewport enquanto o page scale altera o quanto vemos do viewport, mas ele continua igual. A página continua com 980px no celular enquanto fazemos o gesto de pinça, só que enxerga- mos um pedaço menor dela. Por isso, falamos que, em dispositivos móveis, existem dois viewports. Há o viewport que representa a área disponível para nossa página. Esse viewport, que vamos passar a chamar agora de layout viewport, mede 980px fixos no iPhone. O outro é o visual viewport que é o tanto que estamos vendo atualmente na tela. Se abrir a página sem dar zoom, o visual viewport é do tamanho do layout viewport — podemos ver a página toda, como na Figura anterior. Mas, quando fazemos o gesto de page scale, diminuímos o visual viewport para mostrar só um pedaço do layout viewport: 72 Casa do Código Capítulo 10. Tudo que você queria saber sobre viewport Figura 10.2: Meu blog no iPhone dando um page scale num pedaço da página. O layout viewport é o mesmo mas só uma parte está visível no visual viewport. Podemosmedir o layout viewport com document.documentElement.clientWidth e o visual viewport com window.innerWidth. Esses conceitos são bem complicados. Entender completamente a relação entre os viewports diferentes não é algo fácil, mas é essencial. Rode o teste a seguir em um dispositivo móvel moderno com um navegador atual para ver as diferentes medidas. Faça os gestos de zoom, navegue, gire o aparelho e observe como os viewports se relacionam: 73 Casa do Código Figura 10.3: URL do exemplo: http://sergiolopes.org/m3 Geralmente, não estamos interessados no tamanho do visual viewport. Lembre que as medidas da página são sempre relativas ao layout viewport. Ajustando o layout viewport O layout viewport padrão no iPhone mede 980px de largura, pois assume que seu site foi pensado para Desktop. O navegador do Android pensa parecido e usa um viewport padrão de 800px. Já o Opera Mobile usa 850px e o Internet Explorer no Windows Phone, 974px. Mas abrir um site Desktop no celular é uma experiência pouco agradável. Fre- quentemente, vamos querer criar uma página otimizada para mobile, que não de- mande tanto zoom e já mostre o conteúdo em tamanho e formato interessantes para uma tela tão pequena. Como fazer? Obviamente, não podemos deixar a página com layout fixo em, por exemplo, 960px. Podemos tentar porcentagens e colocar um width:100 no ele- mento principal, pensando em se adaptar a diversos tamanhos de tela. Mas isso não vai resolver: o layout viewport é grande (980px no iPhone) e os 100% no CSS vão significar tudo isso. O site é mostrado como se fosse de Desktop, com zoommínimo e conteúdo praticamente ilegível. Que tal colocar width:320px, o tamanho real do dispositivo? 74 Casa do Código Capítulo 10. Tudo que você queria saber sobre viewport exemplo: um Galaxy S3 tem 360px de largura, um iPad tem 768px, um Nexus 4 tem 384px, um Galaxy Note tem 400px, um Kindle Fire tem 600px e assim por diante. É possível deixar ameta tag viewport com tamanho flexível, baseado no tama- nho do aparelho. Basta usarmos: <meta name="viewport" content="width=device-width"> Isso assumirá o valor específico pra cada aparelho, que é o valor mais adequado para seu tamanho, conforme determinado pelo fabricante. A meta tag viewport pode receber alguns outros parâmetros. O mais comum e recomendado para a maioria dos sites mobile é: <meta name="viewport" content="width=device-width, initial-scale=1"> O parâmetro initial-scale=1 indica para o navegador que a página deve abrir no tamanho especificado (você poderia dizer pra página abrir já com um zoom ini- cial). Esse parâmetro não parece muito útil, mas ele é importante no iOS. Sem ele, o Mobile Safari considera a largura da página sempre igual ao tamanho no modo retrato, mesmo com o aparelho virado em paisagem. Ou seja, num iPhone, a página teria 320px tanto em retrato quanto paisagem. Coloque o initial-scale=1 e isso não acontece, o tamanho certo é usado em ambas as orientações. Agora, configurando o viewport com device-width, umCSS pixel é do tamanho de um pixel físico. Bem, pelo menos nas telas comuns. As telas de alta resolução e retina mudam um pouco tudo isso. É o próximo tópico (11). Viewport em CSS A parte mais irônica de toda essa discussão sobre viewport é que usar a meta tag não é maneira oficial de se fazer. A meta tag viewport foi inventada pela Apple e copiada por todo mundo. Acabou virando um padrão de mercado. Mas, ofici- almente, há outra especificação que lida disso no W3C, a CSS Device Adaptation (http://dev.w3.org/csswg/css-device-adapt/), ainda em rascunho enquanto escrevo o livro. A principal diferença é que essa spec joga a responsabilidade para o cara certo, o CSS, em vez de uma tag HTML. É a nova regra @viewport que você pode usar assim: @viewport { width: device-width; } 77 Casa do Código Lembra bastante a meta tag e tem parâmetros parecidos (consulte a spec pra mais detalhes). Uma vantagem bem interessante é poder usar várias configurações de viewport aomesmo tempo, definidas commedia queries. A sintaxe é simples mas dá umnó na cabeçamisturar tudo isso. Reflita sobre o que o código a seguir vai fazer: @media (max-width: 400px) { @viewport { width: 320px; } } Para telas até 400px de largura, o viewport é fixado em 320px. Isso quer dizer que o site é renderizado a 320 CSS pixels e depois redimensionado pra encaixar na reso- lução real da tela (que tem menos de 400px). É um jeito de fazer o layout encaixar na tela sem fazer um layout fluído de verdade — o browser redimensiona sozinho nosso layout fixo em 320px pra encaixar na tela. Daria então pra fazer 3 designs (smartphone, tablet, desktop) fixos, com viewports diferentes e deixar o browser re- dimensionar baseado no tamanho da tela. Tudo isso será futuro, pois o suporte nos navegadores é bem baixo enquanto escrevo o livro. O IE10 é o primeiro a usar essa regra (ainda com prefixo) num modo novo do Windows 8 chamado Snap Mode (http://timkadlec.com/2012/10/ ie10-snap-mode-and-responsive-design/). 78 Capítulo 11 A saga dos 3 pixels e as telas de alta resolução e retina No tópico anterior sobre viewport (10) falamos da diferença entre pixels físicos e CSS pixels. Pois bem, o mundo era desse jeito até começarem a surgir os primeiros An- droids com telas de alta resolução e iPhones retina. Temos 3 pixels diferentes agora. Os iPhones antigos vinham com 320px de largura. A partir do iPhone 4, o pri- meiro com tela retina, eles passaram a vir com o dobro de resolução. Ou seja, 640px de largura. Mas o tamanho físico do aparelho é o mesmo. O que acontece então? Comoficamnossas páginasmobile então que assumiamuma resolução bemme- nor? Com resolução tão alta quanto um Desktop, os celulares mais modernos vão renderizar as páginas bem pequenas, como um site Desktop? Felizmente, nossas páginas continuam funcionando porque esses dispositivos de alta resolução conti- nuam reportando um device-width de 320px, pra manter a compatibilidade. A ideia de reportar um device-width diferente do tamanho de pixels físicos surgiu no Android e depois foi copiada pelo iOS e outras plataformas. Dessa forma, Casa do Código O que importa é o tamanho em DIP Todos os iPhones mostram 320px de conteúdo, não importando se é retina (com 640px físicos) ou não. Precisa ser assim, pois os pixels físicos são muito pequenos na tela retina. Seria péssimo pro usuário mostrar 640px de conteúdo, tudo ficaria muito pequeno. No fim, pra usabilidade, conta mais o tamanho da tela emDIP que o tamanho físico. Não quer dizer claro, que ter uma tela com alta resolução e com alto *pixel ratio* seja ruim. Embora o conteúdo fique igual de tamanho nos dois tipos de iPhone, ele ficamais bem definido no retina, claro. Textos e gráficos ficam ótimos. Conteúdos grandes e com zoom out ficammais definidos— como uma foto grande ou um vídeo HD ou mesmo um site Desktop visto no celular. Devíamos falar de ‘DPI de conteúdo’ A confusãomaior nisso é que as especificações dos aparelhos ematérias nos sites de tecnologia costumam falar apenas da resolução física do aparelho e não de view- ports e pixel ratios. Claro, esses conceitos confundem muita gente, principalmente o usuário final. Mas a contradição é que o viewport é justamente o número mais útil pro usuário, muito mais que saber a resolução física. Num artigo que li recentemente no Gizmodo, havia uma comparação entre o iPad Mini e o Nexus 7. O argumento era que a tela de 1024x768 do iPad Mini era pior que a de um Nexus 7 de 1280x800 pois tinha menor área útil disponível para o usuário. Errado! Embora com resolução física mais alta, o Nexus 7 tem um device pixel ratio 1.33% e viewport menor (966x603px contra 1024x768px do iPad Mini). Um usuário que queira ver mais conteúdo na tela, vai preferir o iPad Mini. Quando lemos comparativos sobre aparelhos, é comum ver as pessoas citando DPIs físicos. Por exemplo: • iPhone não-retina tem 163 dpi com largura de 320px • iPhone retina tem 326 dpi com largura de 640px • Galaxy S tem 233 dpi com largura de 480px • Galaxy Y tem só 133 dpi com largura de 240px Só vendo esses poucos exemplos, a ideia é que temos telas com resoluções bem diferentes e DPIs diversos. 82 Casa do Código Capítulo 11. A saga dos 3 pixels e as telas de alta resolução e retina Mas isso não é verdade se levarmos em conta a área real pro conteúdo em DIP. Por isso, acho que deveria existir uma métrica de dpi de conteúdo, que mostra a densidade da tela com base na quantidade de conteúdo que ela mostra, em device independent pixels. Olhando novamente pra lista de aparelhos vemos que todos têm amesma largura de viewport e a variação na densidade de DIP é bem menor: • iPhone não-retina tem 163 dpi de conteúdo com viewport de 320 DIP de lar- gura • iPhone retina tem 163 dpi de conteúdo com viewport de 320 DIP de largura • Galaxy S tem 155 dpi de conteúdo com viewport de 320 DIP de largura • Galaxy Y tem 177 dpi de conteúdo com viewport de 320 DIP de largura Pro usuário final, essa medida de dpi de conteúdo é mais importante que o dpi físico. Porque um iPad mini tem o mesmo viewport que um iPad normal? O lançamento do iPad mini trouxe muita discussão sobre sua usabilidade. O Jakob Nielsen, papa da usabilidade, declarou que a tela é pequena demais e com pro- blemas de UX (http://www.useit.com/alertbox/specifications-vs-ux.html). Outros reviews chegaram na mesma conclusão, e até nomes como Luke Wroblewski e Brad Frost entraram nessa discussão. O problema do iPad Mini é que ele tem a mesma resolução de 1024x768 do iPad normal mas em uma tela 27% menor fisicamente. Pior, seu device pixel ratio é 1, o que faz com que o viewport final seja também de 1024x768. Na prática, todas as coisas do iPad abrem 27%menores em tamanho, tornando os botões mais difíceis de apertar, os textos menores pra ler e etc. Muita gente se pergunta em como a Apple chegou no tamanho de 7.9 polegadas do iPad Mini. Esse número não é aleatório. Com 7.9, o iPadmini tem omesmo dpi de conteúdo dos iPhones. Ou seja, vai renderizar tudo do mesmo tamanho físico que um iPhone faz. Veja as contas: • iPhone não-retina (320x480) tem 162.98 dpi de conteúdo numa tela de 3.5” com pixel ratio 1 83 Casa do Código • iPhone retina (640x960) tem 162.98 dpi de conteúdo numa tela de 3.5” com pixel ratio 2 • iPadmini (1024x768) tem 162.02 dpi de conteúdo numa tela de 7.9” com pixel ratio 1 • iPad 4 retina (2048x1536) tem 132 dpi de conteúdonuma tela de 9.7” compixel ratio 2 Olhando essa lista, percebemos que o estranho é o iPad normal, com um dpi bemmais baixo. As coisas ficammaiores fisicamente no iPad normal, o que é bom já que um tablet grande costuma ser usado a uma distância maior do usuário (apoiado na mesa, no colo etc). Na prática, o que a Apple está dizendo é que o iPadmini foi feito para ser usado na mesma distância que você usa o iPhone, e não como você usa o iPad normal. Quantos pixels minha tela deveria ter? A questão aqui é de usabilidade. Pixels pequenos demais tornam a leitura do usuário mais difícil, que é grande crítica dos analistas ao iPad mini. Você precisa usar o aparelho mais perto do rosto, o que pode não ser muito natural. O W3C tem uma medida oficial pra determinar o tamanho de um pixel de conteúdo na tela, o que eles chama de pixel de referência (http://www.w3.org/TR/ css3-values/#reference-pixel). Ele é medido em ângulos, claro. Um pixel num celu- lar que usamos perto do olho tem comprimentomenor que um pixel numa televisão que vemos a metros de distância. Para analisar se um pixel está do “tamanho certo”, é preciso saber a distância do usuário em relação à tela. O tamanho do pixel de referência do W3C é de 0.0213 graus. Deixando a mate- mática um pouco de lado, isso quer dizer que: • Um iPhone foi projetado para ser visto a uma distância de 41.9cm do olho; • O iPad normal é melhor visto a uma distância de 51.7cm; • Já o iPad Mini é pra ser usado como um iPhone, a 42.1cm de distância. (se quiser saber melhor sobre a matemática por trás disso tudo, recomendo: http: //www.kybervision.com/Blog/files/AppleRetinaDisplay.html) 84 Capítulo 12 Não remova o zoom dos seus usuários Vimos no tópico sobre viewport (10) a importância da meta tag para adaptar a página corretamente nos dispositivos móveis. Analisamos os parâmetros width e initial-scale, mas há outros. Os demais parâmetros controlam o gesto de re- dimensionar a página (page scale). Com eles, você consegue bloquear o zoom do usuário de algumas formas: <meta name="viewport" content="width=device-width, user-scalable=no"> <meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1"> Mas, na esmagadora maioria dos casos, você não deveria fazer isso. Exceções talvez sejamwebapps comuma ideia de canvas fullscreen onde os gestos são tratados pela aplicação (mapas e jogos talvez). Em sites web normais? Jamais. Casa do Código As telas pequenas dos smartphones ensinaram algo simples para os usuários: se algo estiver pequeno, apenas pince os dedos (pinch) e dê zoom! É um gesto básico de dispositivos touch e conhecido por todo mundo. Mas, mesmo assim, muitos sites bloqueiam o zoom nas páginas. Não faça isso. Há um mito que circula por aí de que limitar o zoom faz com que nossa página fique mais parecida com uma App. Primeiro: site não é App, então não tente parecer uma. Segundo: se algumas Apps têm essa limitação de não deixar dar zoom, por que copiar essa deficiência pra sua página? Controle na mão do usuário Desabilitar o zoom das páginas é tão irritante, mas tão irritante, que os browsers mobile modernos estão deixando esse controle na mão do usuário! O browser do Android 4 e o Chrome Mobile, por exemplo, têm essa opção nas configurações: Figura 12.1: Configurações de zoom do Android 4 e do Chrome Mobile 88 Casa do Código Capítulo 12. Não remova o zoom dos seus usuários OMobile Safari do iOS, infelizmente, ainda não temuma opção dessas. Também não consegui achar no Opera e no Firefox uma opção semelhante. Uma gambiarra útil pra usuários dessas plataformas é usar um bookmarklet que reescreva a tag viewport dos sites pra habilitar o zoom sempre (https://gist.github.com/sergiolopes/ 5231024). O famoso bug do zoom no iOS Eu acho que o grande culpado da proliferação de páginas com zoomdesabilitado é um famoso bug no iOS até a versão 5.x que faz com que a página dê um zoom quando você gira o aparelho em modo paisagem. É bem irritante. Você está vendo a página em modo retrato e, quando gira o aparelho, a Safari dá um zoom in e você não consegue ver a página toda — e precisa fazer um gesto de zoom out. Se desabilitarmos o zoom, o bugnão acontece. Mas é um jeito covarde de resolver o problema. O iOS 6 resolve esse bug doMobile Safari, então isso é coisa do passado. Mas mesmo que o bug do iOS seja um problema pra você e seus usuários com iOS velho, pense em alguma opção: • Não faça nada. Sim, uma opção é deixar o bug acontecer. Lembre que um usuário de iOS está acostumado a isso, afinal todos os sites do mundo são afe- tados! E a maioria dos usuários com iOS 6+ está ok. • Se incomodar muito e você quiser tirar o zoom do usuário por causa do bug, pelo menos faça isso apenas no iOS e não limite todos os outros dispositivos do mundo que funcionam direito. Lembre que, principalmente no Brasil, o Android é muito mais usado que o iOS. • Há hacks em JavaScript que solucionam o problema em 99% dos cená- rios. Veja um comparativo de hacks que resolvem o bug: https://github.com/ sergiolopes/ios-zoom-bug-fix#other-solutions Conclusão Demodo geral, desabilitar a possibilidade do usuário dimensionar a página a seu gosto é péssima usabilidade. Nem todo usuário tem visão perfeita e o gesto de page scale é uma das ferramentas essenciais de acessibilidade. Vamos discutir mais sobre acessibilidade relacionada ao outro tipo de zoom, o page zoom, em outro tópico (16). 89