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

O vídeo conta a história de um cara que faz de tudo para que os usuários não utilizem a velha versão do Internet Explorer, fazendo com que isso se torne um vício. Ele diz que os IEs antigos servem para apenas uma coisa: “baixar outros browsers”. Hell yeah!

A Microsoft tem promovido o IE9 por que é o IE que mais se adequa ao padrões web até agora. O IE10 é muito melhor, mas ainda não está nas prateleiras e provavelmente vai ser lançado de verdade somente com o Windows 8. O IE10 fica no páreo com os browsers mais atuais como Chrome, Firefox e Safari, mas o IE9 está fazendo um ótimo trabalho também e não dá tanta dor de cabeça como as versões antigas do browser.

Veja o vídeo e divirta-se.

Posts Relacionados

• Dicas de sobrevivência em uma era pós o IE6
• Schema – Marcação de dados estruturados
• Seu lugar ao sol
• Prefixos dos browsers: A web precisa de você
• Google Chrome para Android

O Google acaba de lançar o Google Chrome para Android. Antes que você fique todo alegre, o Chrome para Android só está disponível para os usuários do Ice Cream Sandwich ou tablets. Ele é baseado na simplicidade do Chrome para desktops, prometendo a experiência de navegação.

Eles reimaginaram o uso de tabs para os mobiles, e nas tablets a utilização as tavs ficaram similares com o Chrome para Desktops. Temos também incluído nessa versão mobile o famoso “Porn mode” ou o Incognito, que é o modo de navegação privativa.

O Google Chrome para Android ainda está em fase beta e você pode baixá-lo no MarketPlace mais próximo.

Uma boa notícia para toda a comunidade de desenvolvimento web mobile. A briga fica acirrada entre os sistemas. O que é bom para nós e para os usuários. Agora oremos para que o IE10 para Windows Phone saia logo, o que eu duvido. Acho que ele somente virá com o Windows Phone 8. Entretanto temos um ótimo cenário quando falamos sobre browsers para mobiles.

Posts Relacionados

• Dicas de sobrevivência em uma era pós o IE6
• Schema – Marcação de dados estruturados
• O browser que você amou odiar
• Seu lugar ao sol
• Prefixos dos browsers: A web precisa de você

O tráfego medido pela comScore mostra o market share dos principais players do mercado de mobile em Novembro. O Android continua ganhando, logo atrás vem o iPhone que foi impulsionado pelas vendas do 4S. Todas as outras plataformas perderam campo. Outra coisa, o report da comScore não conta com iPads nem iPods.

Os mobiles Android represetam algo em torno de 47% e o iPhone 30%.

O mais importante são os números abaixo que mostram o uso de conteúdo por estes dispositivos pelos usuários:

Acho que pouquíssimas pessoas, mesmo nos seus computadores, entram no site do Twitter para escrever em vez de usar algum App, não é verdade? Mesmo assim acho que o futuro não estão nos Apps. Eles sempre ficarão lá, firmes e fortes, mas aos poucos muitas empresas irão reformular seus sistemas web para ficar o mais parecido possível com as apps. Esse é o mais inteligente já que você não precisa reprogramar tudo novamente como é feito hoje. A mudança do CSS será o trabalho mais importante nesse caso, já que a interface “precisa” ser diferente em cada um aparelhos.
Na verdade não precisa… Mas é bom manter a interface nativa de cada um dos aparelhos para que os usuários não estranhem a utilização. Não seria bom que a interface do twitter no Windows Phone fosse igual a do iPhone ou a do Android. Confunde bastante. Não, é?

Só uma observação: estes números refletem a realidade lá dos states, ok? Provavelmente esse comportamento pode ser multiplicado em outros países, como aqui.

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• Responsive Web Design – focando a coisa certa
• Um pensamento sobre design para web
• Experiência cross-device
• Simuladores de Browsers Mobiles

Os dispositivos móveis se tornaram uma febre e vieram para ficar. É a melhor forma de fazer a inclusão digital para aqueles que não tem uma forma de ter um notebook ou um desktop em casa. Não estou falando daqueles smartphones de R$1500, mas dos muitos smartphones, com teclados qwerty, prontos para internet e que custam R$200. Isso sim é inclusão digital para as massas de verdade.

Alguns números

As vendas de smartphones já passaram as de PCs. A utilização de emails pelos dispositivos móveis aumentou em 36%. Sem contar que o tráfego de visitação de websites utilizando smartphones cresceu 600% em 2010!

O Paypal tempos atrás recebia algo em torno de $10 Milhões de dólares em pagamentos via mobiles. Por dia! Eles tem uma predição de movimentar algo em torno de 6 Bilhões só este ano! E em 2016 serão $31 Bilhões!

As perspectivas globais são enormes. Abaixo, veja um inforgráfico que o blog The Meta Cloud preparou. Cuidado para não se assustar.

O conceito

Você consegue entender estes números? Se sim, você vai entender que o conceito do Mobile First faz muito sentido, mas vai contra toda uma tradição de desenvolvimento de sites que você está acostumado. A ideia do Mobiles First é que comecemos a desenvolver e planejar projetos web, desde um pequeno site até um grande sistema, primeiramente para dispositivos móveis e somente depois para desktops/notebooks.

Algumas vantagens

Se o mundo inteiro está passando mais tempo acessando a internet com dispositivos móveis, não é muito sensato pensarmos primeiramente em fazermos sites para desktops/notebooks, não é? O fato é que ao colocar os mobiles primeiro lugar, desfrutamos de uma série de vantagens:

• As capacidades técnicas são mais interessantes. Com o mobiles você pode brincar com o acelerometro, GPS, multitouch, giroscópio e etc. Isso amplia a experiência do usuário para um patamar que o desktop nunca terá.
• Foco. Quem já teve que adaptar um site para mobiles entende que informação demais prejudica. Se focar nas ações essenciais que o usuário executará ao acessar seu site com um dispositivo móvel é o básico.
• A atenção em áreas como Arquitetura de Informação, Usabilidade e Acessibilidade é aumentada. Em mobiles, decidir onde cada botão vai ser posicionado é tão essencial quanto a programação server-side ou um HTML bem feito.
• Te prepara para outros cenários. Fazer sites mobile é só o primeiro passo. Mas e os grandes formatos como SmartTVs ou outros dispositivos? Não vai demorar muito para acessarmos a internet de qualquer dispositivo sem bloqueios ou restrições.

O design

O design também precisa ser revisto. Na verdade, o design mais do que nunca conta com as respostas e os conceitos de AI, Acessibilidade e Usabilidade. Se antes fazíamos festa porque a resolução dos desktops aumentaram e agora temos mais espaço para trabalharmos, nos mobiles o cenário é completamente o contrário.

Arquitetura de Informação

As informações que você previa no desktop precisam ser remanejadas, diminuidas e retrabalhadas para que se adaptem nas telas menores. A maioria dos celulares tem algo em torno de 320×480 pixels. Se não tomarmos cuidado, toda a informação pode se perder em uma tela tão pequena. No mundo mobile o simples é a palavra que manda.

Você pode perceber que alguns websites conseguiram resolver bem seus problemas de excesso de informação promovendo em seus websites mobiles apenas as ações realmente importantes e dando foco ao conteúdo que provavelmente o usuário irá consumir quando estiver utilizando um pequeno dispositivo.

Se você é usuário do Flickr, conhece aquele bando de opções que ele guarda em seu menu principal. São centenas de opções e ações que certamente não cabem em uma tela tão pequena.

Um estudo profundo certamente deve ser feito para que você saiba exatamente quais informações e ações serão mais úteis na versão mobile.

Mantendo informações importantes

Existem também outras formas de acomodar um grande número de informações sem que isso atrapalhe o usuário. Uma delas é criando menus dropdown ou separando uma tela que guarda as informações que serão menos utilizadas mas que são igualmente importantes para a utilização do site/sistema. Veja abaixo dois bons exemplos vindo dos sites Gmail e ESPN.

Onde os usuários utilizam seus mobiles e visitam seu site? Bem, de todo lugar. Algumas pessoas acham que usuários utilizam apenas quando estão em filas, ônibus, parados no trânsito etc. Mas algumas pesquisas mostram que 84% dos usuários usam seus dispositivos em casa. Isso mesmo… em casa. Veja bem: quando as pessoas estão em casa, elas preferem utilizar seus smartphones em vez do notebook/desktop!
62% utilizam enquanto assistem a TV. Até a TV perde atenção quando briga com os mobiles.

Não existem mais desculpas. Os browsers para mobiles estão tão modernos quanto os dos desktops. O hardware está muito mais poderoso, mais do que poderíamos imaginar a dois anos atrás. Existe um número gigante de usuários utilizando estes dispositivos, isso os torna potenciais visitantes e claro, compradores. Porque desperdiçar esta oportunidade?

Você pode ler mais sobre este assunto neste livro esperto escrito por LUKE WROBLEWSKI. Aproveite!

Posts Relacionados

• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Sites para Dispositivos Móveis – Breve introdução
• Browsers dos Dispositivos Móveis
• Responsive Web Design – focando a coisa certa

Quando produzimos um site os problemas de compatibilidade fazem parte da regra do jogo. Para tentar contornar estes problemas utilizamos hacks, comentários condicionais, sniffing de browsers e outras coisas, que muitas vezes mais prejudicam do que ajudam.

Para ajudar mais ainda o CSS3 e o HTML5 apareceram derrubando tudo, e o problema de compatibilidade que já era chato, ficou mais chato que meia molhada. Embora os browsers estejam muito mais atuais e suportando propriedades avançadas de CSS3 e HTML5, não é garantia que todos eles suportem as mesmas propriedades. E é aqui que começamos a ter problemas novamente, como no passado.

Como você consegue reconhecer quem um determinado browser suporta CSS Animation? Como você sabe que o browser conhece LocalStorage do HTML5? Você não vai ficar olhando numa tabelinha toda vez que tiver essas dúvidas para fazer um visual ou uma solução alternativa para tais browsers.

É por essas e outras que você utilizará a Modernizr.

O que é a Modernizr

Modernizr é uma pequena biblioteca Javascript que detecta a disponibilidade das novas características do HTML5 e CSS3 nos browsers. Muitas destas características já estão implementadas nos browsers, mas é muito chato você decorar quais novidades os browsers já estão suportando. O que a Modernizr faz é simples: ela te diz quais features um determinado browser suporta e insere classes no HTML para que você possa utilizar para fazer uma versão alternativa de visual ou solução.

Entenda que a Modernizr não é um sniffing de browser. Ela é diferente. A Modernizr faz o trabalho de detectar das seguintes formas:

• Ela testa 40 features de CSS3 e HTML5 em alguns milisegundos.
• Depois ela cria objetos javascript que contém os resultados destes testes.
• Aí são adicionadas classes no elemento HTML descrevendo exatamente quais propriedades e novidades são ou não nativamente suportadas.
• Depois disso você consegue ter os resultados descritos nos navegadores dinamicamente e então pode tomar decisões criando alternativas para aquelas propriedades não suportadas pelos browsers antigos.

Como funciona

É simples: primeiro você baixa a versão mais atual da biblioteca no endereço http://www.modernizr.com/. O interessante é que você tem a opção para personalizar a biblioteca, indicando quais features você quer que a Modernizr teste no seu projeto.

Depois você inclui esse pacote no seu HTML:

Feito isso, insira uma classe no-js no elemento HTML:

Quando a Modernizr rodar, ela irá substituir essa classe para uma js se o browser estiver com o Javascript ligado, já te dando um feedback para tomar alguma atitude se o usuário estiver com o Javascript desligado.

Junto com essa mudança são adicionadas outras classes, indicando o que o browser aceita nativamente ou o que ele não aceita. Ficará algo parecido com isso:

O browser que eu utilizei é o Safari/Mac. Pelo visto ele aceita bastante coisa.
O que o browser não aceita, a Modernizr insere uma classe com o prefixo no- antes da classe, por exemplo: no-boxshadow, no-geolocation, no-touch etc.

A Modernizr também cria um objeto Javascript contendo um valor booleano para cada uma dessas features, possibilitando a criação de testes. Um exemplo:

Exemplos de utilidade

Exemplo bem básico: imagine que você queira utilizar o box-shadow em seu projeto. Browsers como o IE6,7,8 não reconhecem essa feature, então seria interessante darmos uma alternativa, como por exemplo, colocando uma borda em vez de sombra. Assim o elemento não fica tão diferente do que deveria.

Como a Modernizr colocou uma classe no elemento HTML referente a aceitação das features, podemos utilizá-la fazendo assim:

Assim, se o browser não aceitar a propriedade box-shadow o usuário verá uma borda no lugar. Você pode fazer isso com praticamente qualquer nova feature do CSS3 e do HTML5. Uma listagem completa dessas features suportadas está aqui.

Ah, mais uma coisa: provavelmente você já utiliza um scriptzinho html5.js para fazer com o que os Internet Explorers reconheçam as tags do HTML5, correto? O Modernizr já faz isso automaticamente. Sugiro que pare de utilizar o html5.js e passe a utilizar a Modernizr somente.

A Modernizr facilita demais as coisas. A ideia é que você não prive seus projetos da utilização de features novas. A produção vai ficar mais eficaz e seu projeto sempre estará atualizado com as melhores práticas do mercado. Adote a Modernizr e seja feliz.

Sugiro que você dê uma lida na documentação da Modernizr. Tem bastante coisa interessante lá que você deveria saber.

Posts Relacionados

• CSS3 – Sombras em textos e elementos
• Múltiplos backgrounds com CSS
• CSS3 – Abas com a pseudo-classe :target
• Drops 3 – Duas formas de modular seu CSS
• Introdução ao CSS 3D – Flip Card

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

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

Um pouco de história

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

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

O DOM em sua forma e como é reconhecido pelos navegadores

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

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

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

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

A Render Tree

Como a render tree é montada

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

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

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

Destruindo (ou atualizando) a Render Tree

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

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

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

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

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

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

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

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

Arvore DOM com suporte HTML5

Arvore DOM IE e outros navegadores sem suporte HTML5

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

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

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

Referências

Entendendo os Reflows por Alysson Franklin

Modernizr para suporte HTML5

HTML5shiv para suporte HTML5

Browser Wars pela Wikipedia

ECMAScript pela Wikipedia

Javascript pela Wikipedia

JScript pela Wikipedia

CSS Box model pelo W3C

DOM pela wikipedia 

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

W3C Overview do DOM

Declaração de atividades do DOM pelo W3C

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

Traversing the DOM by Mike West

Progressive enhancement demystified by Aaron Gustafson

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

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

Posts Relacionados

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

Hoje, as interfaces touch estão maduras e estáveis, que chegam a inspirar as interfaces dos sistemas desktops. Vide o que aconteceu com o OS X Lion e com o Windows 8. As principais ideias foram retiradas de suas respectivas interfaces mobiles: o Windows do Windows Phone e o Lion do OS X para iPad.
As interfaces mobiles e as interfaces desktop ficarão mais homogêneas com o passar do tempo, se assemelhando cada vez mais, contudo, as interações são totalmente diferentes. As interfaces criadas para cada dispositivo nos ajudam a distinguir os ambientes e também a forma com que o usuário interage.

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

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

Ambas as versões tem suas limitações e um legado de compatibilidade com seu sistema base que precisam manter.

A ideia de criar uma especificação destinada para as interfaces touch é que tenhamos controle sobre as ações do usuário, da mesma forma que temos nos desktops. Para isso eles estão mapeando uma série de eventos que específicos das interfaces touch. Assim podemos definir ações baseadas nessas interfaces. Estão participando da escrita desta especificação Doug Schepers do W3C, Sangwhan Moon da Opera Software ASA e Matt Brubeck da Mozilla.

Se você parar para ler a específicação, vai entender que poderemos controlar quando o usuário interage encostando o dedo na tela, movendo o dedo e também ao retirá-lo. Você poderá controlar a área de toque. Se o elemento for pequeno, por exemplo, você poderá aumentar essa área de toque para que o usuário não tenha dificuldades. Poderá acionar eventos no momento que o usuário rotacionar os elementos. Se você está fazendo um WebApp poderá acionar um menu contextual personalizado quando o usuário fizer um “tap” com dois dedos. O usuário vira basicamente um proctologista.

A especificação ainda é um rascunho mas já está mostrando que as possibilidades são imensas. Eu vivo me perguntando até onde irá o HTML, CSS e Javascript com essas novas mudanças. Será que vão continuar fáceis como são hoje ou tudo vai ficar complicado? Será que serão eles que farão todo o trabalho ou novas linguagens serão criadas para lidar com essas novidades? Who knows? Eu tenho um palpite, mas é assunto para outra hora.

Posts Relacionados

• Mobile First – A arte de pensar com foco
• Introdução ao Responsive Web Design
• Porque é a web que comanda
• Experiência cross-device
• Command & Conquer: Tiberium Alliances

Graciosamente retroceder ou progressivamente evoluir?

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

Graciosamente retroceder

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

Progressivamente evoluir

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

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

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

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

Boas escolhas e até a próxima.

Posts Relacionados

• Experiência cross-device
• Seu lugar ao sol
• Agora é a vez dos desenvolvedores
• Introdução ao CSS 3D – Flip Card
• Command & Conquer: Tiberium Alliances

Hoje existe uma gama muito grande de aparelhos com telas de tamanhos variados. Comece a pensar pelos netbooks e depois vá diminuindo até chegar em um smartphone popular como iPhone, Milestone e etc. A variação de tamanho de tela é muito grande. Lembrando que o tamanho da tela é uma coisa e a resolução de tela é outra. Nunca confunda os dois. A largura da tela do iPhone na posição retrato é de 320px. Mas sua resolução padrão é 980px. Isso quer dizer que se você fizer um HTML simples, colocar uma imagem de 980px de largura e visualizar no iPhone, não existirá barra de rolagem. Obviamente a imagem ficará miniaturizada, como mostra abaixo:

Isso é interessante porque possibilita a boa visualização de websites que não estão preparados para mobiles. Vemos o site inteiro miniaturizado, com possibilidade de fazer zoom em qualquer parte do layout.

A tag meta viewport

Mesmo assim os smartphones tem telas pequenas podem dificultar a leitura se fizermos um sistema planejado para grandes resoluções. Por isso é interessante que possamos customizar o viewport para que ele se adeque a realidade desses dispositivos. É aí que entra a metatag viewport.
Com essa metatag iremos customizar a resolução inicial que o browser deve renderizar do viewport do dispositivo. Dessa forma, podemos preparar websites com resoluções personalizadas para smartphones e outros aparelhos.

A sintaxe é muito simples e deve ser colocada, como sempre, na tag head:

Os valores de content são os que seguem abaixo:

Como usar

A tela abaixo não tem nenhuma tag de viewport definida.

Veja que o texto do elemento está bem pequeno. Isso é porque estamos visualizando-o em 980px de resolução em uma tela de smartphone.
Vou acrescentar a seguinte linha:

Define que a largura do viewport será 320px. O resultado está abaixo:

Se inserirmos uma imagem ou um objeto maior que a largura do viewport, uma barra de rolagem é criada. Não precisa se preocupar com o espaço da barra, já que pelo menos nos OSs de smartphones novos, como iPhone e Android, a barra fica invisível e só aparece pro cima dos elementos.

Adicionando o initial-scale com o valor de 1.5, temos um aumento na escala da visualização. Abaixo segue um exemplo comparativo. A imagem inserida tem 320px de largura, logo ela ficará bem justa na tela quando a escala é 1.0, e um pouco estourada quando a escala é 1.5 ou maior. Veja:

Agora com escala de 1.5:

Agora com escala de 2:

E agora com texto, nas mesmas proporções:

Se colocarmos o user-scalable como NO, desabilitamos a possibilidade do usuário de fazer zoom quando ele bate duas vezes com o dedo. Deixar habilitado o zoom é interessante utilizar quando o viewport não está sendo customizado. No nosso caso aqui, isso não iria adiantar muita coisa, já que todos os elementos estão com o tamanho natural, por isso vamos desabilitá-lo.

Atente-se para o detalhe de colocar , (vírgula) entre um valor e outro.
Veja um exemplo aqui. Tente ver com um smartphone como o iPhone, Android, etc.

Manipular o Viewport nos dá possibilidades para personalizar o visual de qualquer site para praticamente qualquer dispositivo, não importa sua resolução ou seu tamanho de tela. Quando unimos isso às media queries, temos um outro mundo de possibilidades.

Posts Relacionados

• Quem precisa de versão mobile?
• Experiência deve ter começo, meio e fim
• PDF – Browsers antigos: guerra contra o terror
• Seu lugar ao sol
• Command & Conquer: Tiberium Alliances