Deixar de suportar o IE6 é questão de sobrevivência. E para matar o IE6, nós precisamos evoluir. Cabe a nós educar o usuário. Formar um mundo novo.

Abaixo segue o email recebido do Google.

Dear Google Apps admin,​

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5. As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser. We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience. We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,
The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

• Porque é a web que comanda
• Simuladores de Browsers Mobiles
• Ah, o maravilhoso mundo real
• Aonde nos leva a morte do Internet Explorer 6?
• Web Standards Project – WaSP

Hoje, aparelhos como o iPhone, que tem um browser com um bom suporte a HTML 5 e CSS 3, possibilitam criar sistemas e aplicativos baseados em web, com características, designs e comportamentos idênticos aos de aplicações instaláveis nos aparelhos. E o melhor, podem ser utilizados de qualquer lugar, pela web. Outro ponto negativo é que desenvolver para iPhone/iPod Touch é um bocado burocrático. Você precisa ter o SDK que só funciona no OS X, e você precisa aprender Objective C para programar os Apps para Apple. Em contrapartida, para fazer um App baseado em Web, onde seus clientes acessarão o sistema diretamente pelo browser do aparelho, é preciso saber Javascript, HTML 5 e CSS 3. Se você já é desenvolvedor Web, você já sabe desenvolver para iPhone, iPod Touch, Android e qualquer outro dispositivo similar.

Se você gosta dos efeitos de transição dos aparelhos, você pode fazê-los sem problemas utilizando JQuery ou CSS 3. Há até um plugin de JQuery chamado JQTouch, que permite fazer efeitos idênticos ao do iPhone. Esse plugin foi pensado exatamente para funcionar em Mobile Safari e outros aparelhos com browsers avançados, como no Android.

Um caso sobre o que estamos falando é a aplicação do Itaú. Se você tem um iPhone, baixe o aplicativo pela AppStore. Ao abrir o aplicativo, perceba que o sistema não faz nada além de mostrar o site do Itaú. É muito mais interessante e barato ensinar o usuário a visitar o site em vez de procurar um aplicativo e instalar. Não é necessário nem divulgar um endereço mobile do site – esse aliás é outra discussão.

Obviamente, há exceções. A maioria dos jogos, se não todos, e alguns sistemas disponíveis funcionam melhor (ainda) se forem instalados no aparelho. Mas a grande maioria dos sistemas, principalmente aqueles que o usuário simplesmente insere ou verifca informações e dados, podem ser servidos diretamente pela web.

No caso do iPhone, os sistemas que utilizam recursos do aparelho, como por exemplo fazer o aparelho vibrar, bluetooth, bateria, GPS e etc, precisam ser instalados. Isso não se aplica a alguns mobiles da Nokia que são baseados na plataforma WRT.
A plataforma WRT permite que você desenvolva aplicativos utilizando Javascript, HTML e CSS. E por meio de Javascript, você pode ativar os recursos que ter utilizar no aparelho. Nesse caso, há uma vantagem em cima do iPhone: você não precisa aprender Objective C. Basta saber Javascript, CSS e HTML.

O cenário de hoje é interessante. Tudo o que o desenvolvedor sempre sonhou em utilizar de HTML 5 e CSS 3 pode ser aplicado no desenvolvimento para web mobile. Os browsers estão mais espertos e a cada dia trazem novidades interessantes para melhorar o desenvolvimento dos padrões e da web. Realmente, daqui pra frente, é um novo mundo que se forma. Um mundo tão ou mais complexo que o desenvolvimento web para desktops como conhecemos hoje. Pra mim, é mais apaixonante.

• Guidelines de User Experience da Apple.
• Forum Nokia – Web Runtime

• Ah, o maravilhoso mundo real
• O que é Tableless?
• Processos e Adoção de Padrões
• Versionamento inteligente para mobiles
• Porque só para o iPhone?

O Android é o novo sistema operacional para mobiles do Google. Até para um AppleBoy, como eu, o sistema é interessante. Tem a interface bem acabada, app’s amigáveis e etc. Ele faz muito bem o papel dele. O Engine de renderização do browser dele é WebKit. O mesmo engine que o Safari Mobile utiliza. E não estou falando de versões antigas do Webkit como alguns outros celulares utilizam. O Android utiliza as versões mais atuais do Webkit, com suporte extenso a CSS e HTML. Portanto, um site que teoricamente foi feito apenas para iPhone, pode ser visualizado da mesma maneira pelos usuários de Android.

Aí entra outra questão: provavelmente você deve ter pensado que seria apenas fazer um script de detecção de browser, capturando as visitas de Safari Mobile e Android e pronto. É aí que você se engana. Já há vários outros aparelhos que estão utilizando engines parecidas e que podem renderizar sua “versão de iphone”. Exatamente por isso, que você precisa fazer um filtro por características e não por browser. Fazemos isso utilizando Media Queries.

As Media Queries permitem fazer um pequeno filtro, onde definimos as características do dispositivo que acessará a página. Com isso, podemos definir um CSS específico para aquele grupo de dispositivos que se encaixaram no seu filtro. Veja um exemplo abaixo:

1
2

<link rel="stylesheet" href="style.css" type="text/css" media="screen and (min-width:481px)">
<link rel="stylesheet" href="mob.css" type="text/css" media="screen and (max-width:480px)">

A media que fiz é muito simples de ser entendida. A primeira linha engloba dispositivos que tem tela colorida, com uma resolução de largura mínima de 481px, isso inclui seu monitor, notebook e etc. A outra linha engloba dispositivos com uma largura máxima de 480px, ou seja, iPhones, Androids e dispositivos que seguem esse mesmo esquema de resolução e etc.

Dessa forma, você filtra os dispositivos e não os browsers dos aparelhos. Isso previne que algum celular, tão bom quanto o iPhone e o Android fiquem de fora de ter uma boa experiência de uso. Quer fazer um teste interessante? Se você estiver utilizando um browser que aceita media queries, redimensione a janela para uma largura menor que 480px. Você verá o Tableless chaveando os estilos automaticamente. Perceba que alguns elementos são reformatados e outros retirados do layout.

O filtro ainda não está completo porque não estamos contemplando os aparelhos que não aceitam meda queries, mas são mobiles. Para isso, usaríamos os Media Types, com valor de handheld. Embora celulares que aceitem os Media Types não tenham um bom suporte de CSS, podemos fazer pelo menos uma formatação de texto, cor e background. Celulares que utilizam Opera Mini, terão uma ótima experiência.

É sempre aquela mesma velha idéia: dar a melhor experiência para todos os meios de acesso. Sempre.

• Porque é a web que comanda
• Introdução sobre Media Queries
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• O que são Media Types do CSS?

Graceful Degradation e Progressive Enhanced

Procurar querer dar uma boa experiência para todos os dispositivos utilizados pode se tornar um problema, já que a variação de aparelhos e hardware é muito maior quando comparado com o mundo dos desktops.
Sabemos que, para um site normal, é seguro ter uma largura de 990px. Sabemos que com essa largura, o site vai ficar bem diagramado em diversas resoluções, começando em 1024.
Mas nos aparelhos móveis não temos essa métrica. A variação dos tamanhos das telas é muito maior. Os aparelhos e a forma de uso de cada um são muito diferentes.

Eu não gosto de nivelar os sites por baixo. Pelo menos não hoje. Há muitas possibilidades de fazermos um bom trabalho de user experience, mas não o fazemos, porque há alguns perfis de usuário, que infelizmente temos que prever no escopo. Por isso sou a favor do Graceful Degradation e do Progressive Enhanced.

Fornecer a melhor experiência possível para todas as camadas de usuários. Esse é o alvo para a utilização do Graceful Degradation e do Progressive Enhanced. 
Se nivelarmos o visual e as funcionalidades do site/sistema por baixo, iremos prejudicar demais os usuário “de alto escalão”. Para entender melhor, imagine um usuário de Safari Mobile acessando um site customizado para Internet Explorer Mobile.

Versionamento Especifico

Já é prática antiga criar versões dos sites para um sistema, aplicação ou dispositivo específico. Fazíamos isso na guerra dos browsers e fazemos isso hoje para alguns browsers antigos. Versionar um site é uma das saídas mais simples para resolver um grande problema. Como a quantidade de dispositivos de acesso está crescendo, a necessidade de haver uma versão do site para estes dispositivos é mais que normal. O HTML é uma linguagem feita para que seja acessada por diversos meios. Hoje, os meios de acesso são bem escassos, consigo pensar apenas em Desktops e Aparelhos de mão (celulares e smartphones). Você consegue pensar em mais alguns outros?
Embora não sejam maioria, os consoles estão aumentando sua presença online. Aparelhos como XBOX e Playstation estão se tornando cada vez menos restritos para jogos, e estão indo muito além do que poderíamos imaginar um dia. O XBOX já anunciou sua integração com Facebook e Twitter. Embora este tipo de acesso seja ainda muito limitado e controlado pelas fabricantes dos consoles, imagine, como seria a experiência de acessar a internet que temos hoje por um Playstation ou XBOX. Eu acharia sem graça. É uma interface totalmente diferente da comum. Mesmo se tentássemos levar a mesma experiência atual com os desktops para estes dispositivos, na minha opinião, estaríamos subutilizando-os.
A mesma coisa pode acontecer com aparelhos como o Surface da Microsft. Eu não imagino um usuário abrindo um navegador como o Firefox, IE ou Opera no Surface e utilizando-o para navegar na internet como fazemos hoje. Não encaixa. É algo diferente, mais interativo, divertido. E atenção aqui: quando digo interativo, não estou querendo dizer que tudo deverá ser feito com Silverlight ou Flash, pelo contrário. O HTML 5 e o CSS 3 estão vindo para acabar com esse mito.

Também não estou dizendo que talvez você fará uma versão dos seus sites para cada novo dispositivo que aparecer. Pelo contrário. Estou dizendo que eles serão necessários de acordo com o público de cada site, e de cada negócio.

Até hoje os desenvolvedores e também os donos de sites, tem uma dificuldade muito grande em criar ou decidir se é útil ou não desenvolver uma versão dos sites para mobiles. Imagine quando a cartilha de meios de acesso aumentar.

A Globo.com e também outros grandes sites enfrentam o mesmo problema: decidir quem vai e quem fica. Decidir qual aparelho será priorizado e qual receberá apenas uma versão de texto.
Claro que com o tempo, as limitações de cada aparelho serão mínimas e as características de cada um serão bem parecidas. Isso diminuiria muito o trabalho de desenvolvimento e aumentaríamos a quantidade de acesso, pelo simples fato de que estaríamos dando quase que a mesma experiência para uma quantidade maior de dispositivos.

Outro ponto importante, mas consolador, é que há motores de renderização muito bons hoje em dia. Vide Gecko e Webkit. Ambos de código livre e que recebem sugestões e modificações do mundo inteiro. Por exemplo, os aparelhos da Nokia e também o Chrome utilizam o Webkit como base para seus softwares de acesso. Isso faz com que consigamos manter o controle de nosso desenvolvimento e nos dá uma visão melhor de todo o horizonte de possibilidades.

Você, como desenvolvedor, tem a obrigação de viver um pouco mais além. Não pense que iremos escrever HTML e CSS para todo o sempre. E mesmo que for, serão linguagens totalmente diferentes de como as conhecemos hoje.

Conhecendo os browsers e seus motores

Os browsers estão ainda muito longe de melhorar a forma com que lidamos e navegamos com a web. Nenhum deles trouxe nos últimos anos uma inovação capaz de fazer com que melhoremos nossa experiência online. Eles ainda estão engatinhando muito e parte da culpa não é deles. O W3C se mostrou muito lerdo nos últimos 11 anos. Eles acordaram muito tarde para as reais necessidades dos desenvolvedores. A comunidade por sua vez, sacudiu todo o W3C, tomando a iniciativa e começando um novo evanlegismo em pról do HTML 5 e do CSS 3. Isso fez com que o W3C entendesse melhor o que os desenvolvedores precisavam para que a web inteira fosse privilegiada.
Os browsers por sua vez, aproveitaram toda essa mudança, e começaram uma nova guerra, em silêncio. O suporte aos Padrões dos principais browsers do mercado está invejavelmente avançada. Há browsers como o Internet Explorer que sempre serão atrasados, mas que felizmente estão acordados também para as novas atualizações do mercado.

Mesmo assim, acho que o foco não se deve dar em browsers específicos, acho que nossa atenção deve ser voltada para os Motores de Renderização. Hoje, os principais são:

• Gecko
  Motor com código aberto. É utilizado nas aplicações da Mozilla: SeaMonkey, Camino, Firefox, Thunderbird etc. Gecko é um motor herdado do antigo Netscape, baseado no Mosaic.
Depois da Guerra dos Browsers, a Netscape doou o motor de renderização para a comunidade, que culminou na criação da Mozilla.
  
• Presto
  Motor proprietário da Opera Software. A Opera é uma das empresas que mais inovam no mercado de browsers. Embora eles tenham tecnicamente um dos melhores browsers para desktops, a versão mobile é a mais utilizada. Eles tem duas versões: Opera Mobile, para smartphones e Opera Mini, para celulares mais básicos. A Opera também está muito presentes em outros mercados fora da web.
• Webkit
  Motor com código aberto, é utilizado hoje em aplicações como Safari, Safari Mobile e Chrome, browser do Google.
É o mais novo motor de renderização do mercado. Foi criado pela Apple, baseando-se no motor de renderização KHTML, que estava só presente em browsers para Linux, como o Konqueror. Aproveitando que o KHTML é um sistema OpenSource, a Apple modificou todo o seu código, fazendo melhorias e aperfeiçoando-o para criar seu browser o Safari. 
A Apple fez várias outras modificações posteriores em cima desta primeira versão. Deu o nome de Webkit, e hoje, conduz o desenvolvimento dessa plataforma.
• Trident
  É o motor proprietário da Microsoft. É utilizado em aplicações como Outlook e claro, no Internet Explorer. Eles estão criando um novo motor, que é utilizado no Internet Explorer 8 e posteriores.
Embora o Trident fora o primeiro a suportar completamente a primeira versão do CSS, atualmente ele é o motor de renderização mais atrasado. A Microsoft vem fazendo um bom trabalho para tentar recuperar essa má fama, mas mesmo assim, os outros motores do mercado estão muito além.

Quando conhecemos o motor de renderização dos browsers, e sabemos quais suas limitações, não precisamos nos preocupar com a quantidade de browsers criados. O Google lançou o seu browser chamado Chrome, baseado em Webkit. Embora fosse um novo browser, isso não deveria assustar os desenvolvedores, já que é o mesmo motor utilizado no Safari. Logo, a renderização dos dois é muito parecida. Não é uma preocupação a mais, pelo contrário.
A mesma coisa se aplica aos browsers para mobiles dos sistemas da Nokia e também do iPhone. Ambos utilizam Webkit para renderizar as páginas. Isso dá liberdade para a criação de interfaces mais elaboradas, tornando a experiência de usuário mais interessante em dispositivos móveis.

Já o Internet Explorer, com seu motor de renderização se mostra um inimigo dos desenvolvedores. Embora a Microsoft esteja trabalhando arduamente em um novo código, as versões antigas deste motor ainda assombra a muitos desenvolvedores. E infelizemente, em alguns projetos, precisamos dar um passo para trás por conta da massa de acessos feitos por este motor.
A mesma história se aplica para a versão do Internet Explorer Mobile. O suporte crítico aos Padrões Web faz com que os aparelhos com este sistema se tornem obsoletos quando se trata de experiência online.

Entenda a importância dos motores de renderização. Eles tem um papel fundamental no comportamento do mercado e faz com que avancemos no desenvolvimento web.

No final tudo dá certo. Ou não.

A web está passando por uma transação infinita. A cada dia ela ganha mais foco na mídia, mais atenção das empresas, tanto grandes, quanto pequenas. Sempre que um novo dispositivo é criado, um novo nicho de usuários surge, com novas maneiras e costumes de navegação. É impossível agradar a todos. Por isso é importante estabelecer prioridades. Um bom caminho é ajudar no desenvolvimento e compartilhamento de sistemas que ajudam a web a avançar. “Muda, porque quando a gente muda, o mundo muda com a gente.” Gabriel O Pensador.

• Ah, o maravilhoso mundo real
• Aonde nos leva a morte do Internet Explorer 6?
• Google Apps não suportará mais IE6
• Lançado Firefox 3.5
• Graceful degradation é tudo sobre Acessibilidade

Em primeiro lugar, é importante distinguir o ideal daquilo que é possível fazer. Li um bocado sobre RDF e ontologias há uns dez anos. Li “A Revolução Inacabada”, vi o RSS nascer e se tornar popular, vi as primeiras aplicações entenderem o formato. RDF falhou. Dez anos se passaram e continuamos escrevendo HTML para ser lido por navegadores e só. Há poucos exemplos de aplicações semânticas na vida real, e a maioria seria desenvolvida de uma forma ou de outra.

Há muita gente, por exemplo, definindo seu próprio padrão de XML para trocar dados com sistemas parceiros. Quantos desses estão usando RDF, com uma ontologia interpretada automaticamente por sistemas que “descobrem” os serviços um do outro? Ou seja, não há novidades nisso nos últimos dez anos.

Escrever HTML bom é importante, porque vai ajudar o Google a indexar seu site e vai facilitar a vida de quem tentar HTML parsing nele. Mas, seja sincero, você tem mesmo esperanças de que alguém vá lê-lo como XML? Vê alguma vantagem real em validar seu código como XHTML, além de provar a si próprio que fez tudo direito? E onde está a promessa dos microformats? Microformats só fazem diferença se forem usados por muita gente. Ninguém vai fazer um parser de um formato usado em apenas um site. Você consegue citar, de cabeça, cinco sites que usem microformats e não foram feitos por você? Ah, claro, não vale incluir na lista o microformats.org.

Nem RSS é um bom exemplo de aplicação de semântica XML. Existem pelo menos dois formatos populares do padrão, além do padrão Atom, que serve para a mesma coisa. E não sei de nenhum leitor de RSS de sucesso que faça parsing dos feeds como XML. O que todos fazem é ler e interpretar a string. É isso mesmo que você entendeu, quase tão bom quanto um CSV! Outro exemplo digno de nota é o SOAP, que foi criado para fornecer aos webservices a capacidade de “autodescoberta”. Você conhece alguém que use isso de verdade? Já viu algum robô que varre a web em busca de serviços e entende sozinho como usá-los? SOAP só tem a vantagem de oferecer tooltips para ajudar os programadores .Net que usam Visual Studio. Enquanto isso, lá fora, XMLRPC e REST (com JSON) estão mudando o mundo.

Por que essas tecnologias falharam, embora pareçam todas boas idéias? Meu palpite é que elas exigiam um raciocínio de longo prazo, um tipo de aposta, que é muito difícil de conseguir. Embora XHTML, Microformats ou SOAP sejam idéias muito boas, aplicá-las em seu site só vai ter valor se muito mais gente o fizer. Se você aplicar o formato sozinho vai perder seu tempo.

O que é muito diferente de, por exemplo, deixar de usar tabelas para layout, escrever bom HTML ou usar jQuery. Essas coisas lhe devolvem um benefício imediato. Se deixar de usar tabelas para layout vai ter um site mais leve e vai perder muito menos tempo quando tiver que mudar o layout, se escrever HTML bom vai ter menos trabalho para escrever CSS, para fazer o CSS mobile e o de impressão, e se usar jQuery vai escrever javascript em um terço do tempo.

Note que esses três exemplos também tiram benefícios do fato de muita gente estar usando. Há muitos bons lugares para se aprender HTML e CSS, há muitos sistemas Open Source que já trabalham gerando código bom e os buscadores entendem a semântica do bom HTML. Mas você não depende desses benefícios para tomar a decisão de uso. Quando começamos, há dez anos, a fazer layouts tableless, não aparecíamos melhor no Google e praticamente não havia sistemas gerando HTML direito. Mas o fizemos assim mesmo porque os benefícios imediatos compensavam o esforço.

É por isso que eu temo que nunca teremos uma web semântica de verdade, e estamos condenados a fazer HTML parsing para sempre.

Há exceções. RSS, por exemplo. RSS é uma sombra do que poderia, mas é um padrão de sucesso, amplamente adotado. E não pode ser explicado com minha teoria do benefício individual imediato. Se você estiver usando RSS sozinho no mundo, não terá nenhum benefício. Talvez o sucesso do RSS se deva ao fato de precisar de uma pequena rede de usuários para oferecer um grande benefício.

Você já se perguntou como foram vendidos os primeiros aparelhos de FAX? Ter um FAX só faz sentido se mais gente tiver. Foram vendidos aos pares. As empresas o compravam para trocar documentos entre a matriz e as filiais. O fato de poder trocar documentos com o resto do mundo era, no início, um “benefício adicional”. Se você precisa trocar conteúdo com um site parceiro e vocês forem os únicos usuários de RSS no mundo, terá valido a pena. Conforme a comunidade de usuários aumentava, o valor de ter RSS crescia. Muita gente começou a usar Bloglines e todo mundo queria entrar na festa.

Há alguns anos eu percorri o país com o pessoal da Locaweb comparando o modelo de adoção do RSS com o que eu imaginava que seriam os microformats. Eu estava errado. Pense um segundo no formato de reviews dos microformats. Qual o real benefício de usá-lo? Há alguma aplicação indispensável, onde você realmente quer estar, baseada em hReview? Para que você vai perder seu tempo?

Será que não estamos resolvendo o problema errado? Quando o Diego diz que bordas arredondadas são mais importantes que RDF, será que ele não tem razão? Para meus clientes, hoje, bordas arredondadas com CSS significam um site mais rápido, mais barato (menos tempo gasto recortando imagens) e, para os sites muito visitados, economia de banda. É uma diferença pequena, mas é uma vantagem. E RDF? Além de oferecer RSS, que nem vai ser lido como XML, o que eu posso fazer de real hoje com RDF para meus clientes?

Desculpe se meu raciocínio parece mesquinho. Ele é. Estou tentando ser realista. Uma das principais influências sobre as decisões humanas é a inércia, e não acredito que o mundo vá, num futuro próximo, adotar de maneira revolucionária o RDF ou mesmo o XHTML. Ainda acho essas idéias fantásticas, só não sei se são possíveis.

O realismo também me faz crer que a nova estratégia de especificações modulares do W3C é uma coisa boa. Sofremos décadas com implementações parciais do HTML 4 e do CSS 2. Agora vamos assumir a realidade inevitável. Os desenvolvedores de navegador se sentirão mais à vontade para dizer a você o que funciona ou não. E não precisamos esperar anos para a definição de um padrão. Podemos usar os recursos com os quais o consórcio já concordou hoje. Leva mesmo alguns anos para o W3C bater o martelo sobre determinado padrão, e as especificações modulares representam um ciclo de releases muito mais dinâmico.

Já temos um acordo sobre CSS Transform, bordas arredondadas, múltiplos backgrounds, repetição no DOM, validadores de formulários, SVG, DOM Storage, querySelectors e uma série de outros recursos legais. Por que esperar até a próxima Olimpíada para dizer aos desenvolvedores de browsers: “Ok, pessoal, fechamos tudo, HTML 5 e CSS 3 já são padrões, podem implementar”? De qualquer maneira, a adoção modular das especificações do W3C é inevitável. Embora a especificação tenha saído inteira, a adoção foi modular no HTML 3, no HTML 4, no CSS 2. Sabendo que não vai ser diferente mesmo, não é melhor que tenhamos bonitas tabelas de compatibilidade entre o que existe e o que cada navegador suporta?

Dá uma olhada na lista de módulos do CSS3. Você não quer esperar isso tudo ficar pronto para ter bordas arredondadas.

• O Caminho Suave para o Tableless
• O que é Tableless?
• Sobre Internet Explorer para Mobile – Breve impressão
• Não “otimize” seu código
• O que são Media Types do CSS?

Um dos objetivos do W3C – se não o maior objetivo – é organizar toda a informação da internet. Para fazer isso, precisamos identificar toda essa informação de forma que a extração não seja complexa, pelo contrário, de maneira que a toda a informação que precisarmos possa ser extraída rapidamente, fácil e de qualquer tipo de dispositivo ou aplicação. Por isso, o W3C perdeu muito tempo criando padrões como RDF, por exemplo. Não desmerecendo essas tecnologias, que aliás são bem úteis para nos hoje. Mas cá entre nós, fazer bordas arredondadas para mim, hoje, é mais importante do que algumas necessidades de semântica.
Alguns dos desenvolvedores, a grande maioria gringos, também tinham essa visão. A necessidade de grande parte dos desenvolvedores eram ter coisas simples como suporte a PNG, bordas arredondadas, resize de imagem no background, colocar várias imagens de backgrounds em um elemento, css animation, e assim por diante. Por isso, muitos desenvolvedores começaram reinvidicar uma alteração de prioridades. O HTML 5 surgiu daí. Muitos se enganam se acham que o HTML 5 foi idéia original do W3C. Ele surgiu de um grupo de inconformados de o HTML não ter a pelo menos 10 anos, uma nova atualização. Então começaram a estudar e a escrever um novo padrão para a linguagem. Isso surgiu de uma união de desenvolvedores da Apple (Safari/Webkit), Mozilla e Opera. Muitos se enganam também, se acham que só o W3C pode criar padrões. Você pode criar um. Se vai haver suporte da comunidade, do W3C e dos fabricantes de browsers, é outra história. Mas você tem todo o direito de criar.

O grupo do HTML 5, queria mudar. Eles estavam cansados de usar uma tecnologia antiga e começaram a fazer o trabalho que se esperava que o W3C fizesse. Por fim, essa iniciativa ganhou tanta popularidade e ajuda de outros desenvolvedores, que o W3C resolveu abraçar a idéia e hoje ele cuida desse padrão.
O CSS3 também começou a aparecer por que o W3C abriu os olhos e resolveu começar a revolucionar a linguagem.

O W3C mudou. Os times que cuidam dessas linguagens foram divididas. Modularizadas. Deixe-me explicar. O CSS3 não será mais lançado de uma vez, mas em módulos. Há um time que cuidará da propriedade background. Outra que cuida da propriedade position, outra que cuida da propriedade border, e assim por diante. Isso possibilita que cada módulo, cada propriedade, cada parte do CSS seja lançado independentemente, acelerando o processo de suporte dos browsers e utilização pelos desenvolvedores. Logo, não há mais aquela história de “Browser tal não suporte CSS3”. Mentira, ele suporta, mas algumas das funcionalidades. A mesma coisa acontece com o HTML5. Dizem que o IE8 não suporta HTML 5, mas é mentira. Ele suporta partes do HTML 5. Já há vários módulos implementados no IE8, que fazem parte da especificação do HTML 5. Isso também acontece com os outros browsers.

A web vai ficar mais dinâmica agora. O CSS 3 e o HTML 5 vieram para separar o joio do trigo. Os designers não vão mais ficar pintando quadradinhos como antes. O CSS está virando uma linguagem visual de verdade. Há, por exemplo, working drafts de suporte a variáveis no CSS. E isto é só o começo.
A mesma coisa para o HTML 5. A mudança das tags estruturais do HTML é apenas a ponta das novas possibilidades. Para o pessoal que achava que o HTML é coisa de criança, se prepare, porque o buraco, agora, é mais embaixo.

• Processos e Adoção de Padrões
• Ah, o maravilhoso mundo real
• Lançado Firefox 3.5
• Graceful degradation é tudo sobre Acessibilidade
• Porque só para o iPhone?

Mas não é tempo de comemorar, ainda há muito trabalho a fazer. Há oito anos o Zeldman publicou seu célebre artigo To Hell With Bad Browsers, em que nos explicava porque devíamos abandonar o suporte aos navegadores 4.0. O ponto básico era não ter que fazer várias versões do mesmo site. Uma versão apenas, com bom layout CSS, podia funcionar para todo mundo, com todas as vantagens dos padrões web, mas não nos navegadores 4.0.

Bom, fazem oito anos. OITO LONGOS ANOS! Há oito anos que podemos escrever uma versão só de cada site, desde que saibamos escrever hacks de CSS e ajustes de float para o Internet Explorer 6. Há oito anos que estamos repetindo o fato de que o Internet Explorer 6 é a pedra que restou em nosso sapato. Há oito anos que sonhamos em não ter que escrever hacks.

A morte do Internet Explorer 6 significa apenas isso: poder usar PNG transparente e não ter que escrever hacks (ou não ter que escrever tantos hacks.)

A Microsoft passou oito anos sem atualizar seu navegador para nos dar exatamente o que? PNG transparente? Nesse período, Firefox, Opera, Safari e Konqueror estão trabalhando em coisas como controle de opacidade, CSS transform, bordas com imagem, sombras, media queries, colunas e os maravilhosos novos seletores do CSS3. Coisas maravilhosas que você já pode usar, mas a maioria de seus usuários não vai ver porque usa Internet Explorer.

A morte do Internet Explorer 6 nos leva apenas ao lugar onde deveríamos ter chegado há oito anos: sites sem hacks. A Microsoft ainda está algumas gerações atrasadas e, se queremos usar CSS 3 e HTML 5 um dia, é bom parar de comemorar e voltar ao trabalho. Há um mundo para mudar.

• Ah, o maravilhoso mundo real
• Google Apps não suportará mais IE6
• Porque é a web que comanda
• Introdução: diversidade dos meios acesso
• Processos e Adoção de Padrões

Elementos de Áudio e Vídeo do HTML5

A adoção de algumas características do HTML5 está se tornando cada vez mais frequente nos novos browsers. Isso é bom porque não precisaremos esperar tanto para que todos os browsers tenham suporte a grande parte das características do HTML5, Javascript e CSS3.

No Firefox 3.5, é nativo o suporte aos elementos de áudio e vídeo do HTML 5. Isso inclui suporte para encodes de vídeo Ogg Theora e Vorbis para áudio. O código para incluir um vídeo é basicamente este:

1
2
3

<video src="http://v2v.cc/~j/theora_testsuite/320x240.ogg" autoplay>  
Atenção: Seu browser não suporta esse formato.
</video>

A mensagem que está entre a tag VIDEO é mostrada caso o browser não reconheça o formato de vídeo.
Caso o browser não abra o formato de vídeo OGG, você pode indicar para que ele abra um outro formato automaticamente, veja o código:

1
2
3
4
5

<video autoplay>  
  <source src="video.ogg" type="video/ogg">  
  <source src="video.mov">  
  Atenção: Seu browser não suporta esse formato.
</video>

@font-face – Suporte a fontes externas

A propriedade @font-face serve para que apliquemos fontes aos sites que não sejam default no computador do visitante. Ele era apenas suportado em browsers com motores Webkit, agora o Firefox trouxe essa possibilidade, aumentando o número de usuários que suportam essa característica.

A sintaxe:

1
2
3
4
5
6

@font-face {
  font-family: "Bitstream Vera Serif Bold";
  src: url("http://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf");
}
 
body { font-family: "Bitstream Vera Serif Bold", serif }

Você define primeiramente a fonte que irá ser utilizada, indicando seu source para que o browser possa localizá-la e assim fazer o download para ser aplicada. Feito isso, você pode utilizá-la nos elementos normalmente, como você faz com as fontes default.

Já falamos sobre propriedade @font-face aqui.

Opacity

Agora não precisamos mais utilizar o prefixo -moz- antes da propriedade OPACITY. Antes utilizávamos para testes apenas. Agora o pessoal do Firefox tirou esse prefixo para favorecer a propriedade OPACITY, sem prefixo. Eu nunca gostei destes prefixos, mesmo assim, essas coisas evitam erros de funcionalidades entre os browsers, já que um pode interpretar de forma diferente propriedades que ainda não foram realmente lançadas.

A propriedade opacity modifica a opacidade dos elementos, onde o valor 0 é totalmente transparente, e 1 é totalmente visível.

1
2
3
4
5

div {
   opacity: 0.3;
   border: 3px solid black;
   background: orange;
}

E um bando de outras atualizações

E há uma série de outras atualizações interessantes para os desenvolvedores, veja uma lista completa aqui.

Daqui pra frente os browsers irão forçar ainda mais a evolução do desenvolvimento web em todos os sentidos. Eles estão cada vez mais implementando coisas novas, que se dependessem do mercado, iriam começar a serem utilizadas daqui a alguns anos. Graças a esta concorrência entre os navegadores, essas novas novidades estão sendo suportadas cada vez mais cedo e podemos começar a utilizar para melhorar os projetos a partir de agora.

Baixe o Firefox 3.5 aqui.

• Ah, o maravilhoso mundo real
• Processos e Adoção de Padrões
• Porque é a web que comanda
• Prepare-se para a Revolução
• Graceful degradation é tudo sobre Acessibilidade

Graceful Degradation é algo que vemos todos os dias. Trata-se de um método comum em dias onde a Internet é muito mais que um simples computador ligado no telefone. Acho que resumidamente, podemos dizer o que exatamente é Graceful Degradation com a frase:

Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don’t work.

Peter-Paul Koch em Fluid Thinking

Esse assunto é bastante velho, mas que volta à tona nestes dias de campanhas contra o IE6 e outros browsers antigos. Eu mesmo já falei para ignorar totalmente o Internet Explorer 6, mas não é tão fácil assim. Eu posso ignorar aqui no Tableless, onde os usuários são de um nicho específico, mas eu não posso ignorar esse público quando se trata de um produto que é feito para o meu cliente. O cliente do meu cliente utiliza IE6. E ignorá-los significa fazer meu cliente perder dinheiro. Isso está fora de questão.
Então, se seguirmos este raciocínio, pense bem: podemos cometer este erro com outros tipos de usuários. Por exemplo, se seu site não pode ser bem visto em dispositivos móveis ou se não é bem acessado por leitores de tela.

É tudo sobre acessibilidade

Engana-se aquele que acha que acessibilidade é apenas sobre cegos e outras pessoas com alguma necessidade fisica. É claro que esse público merece uma atenção especial, que muitas vezes é tristemente ignorada. Mas quando falamos sobre acessibilidade, temos que entender que há outros grupos que se encaixam nesse assunto.
Quando um visitante não consegue acessar seu site por causa da resolução, ou por meio de algum dispositvo, ou por algum sistema de voz etc, estamos falando de acessibilidade.

Temos que prever visitantes com necessidades diversas. Há pessoas que passam a maior parte do tempo viajando. Por isso é muito difícil ler emails ou trabalhar conectado por notebook ou computador decente. Por isso ela passa a maior parte do tempo utilizando aparelhos móveis. Não por que ela queira, mas por causa da sua necessidade.
Se negligenciarmos o acesso desse tipo de público, cometemos um erro grave de acessibilidade. O mesmo para um simples visitante que não consegue acessar seu website por causa da sua resolução. Ele usa 800×600 porque precisa e não porque quer. Embora haja alguns que nem sabem o que é resolução.
Necessidade. Acessibilidade é tudo sobre a necessidade das pessoas.

Meios de acesso a Internet

Se as pessoas acessam a Internet, elas acessam por meio de um dispositivo especifico. Se ela é cega ou tem algum ou outro problema de visão, ela acessa o site por um leitor de tela. Se ela viaja muito ou fica muito tempo presa no trânsito, utililza dispositivos móveis.
Hoje em dia não existem muitos meios de acesso a Web. Se não acessamos por um computador ou um dispositivo móvel, acessamos com o que?
Outros meios de acesso a Internet estão nascendo. Na verdade novos usos para o acesso a Internet estamos surgindo e com estes novos usos, surgem novos meios de acesso. Vide o Surface da Microsof. É um meio totalmente diferente de interagir com a Web. Mas é um novo meio.

Mas e o Graceful Degradation?

Problemas com compatibilidades sempre existiram e creio que nunca deixarão de existir. Pelo contrário. Esses problemas serão mais comuns embora fiquem mais fáceis de resolver. Não serão apenas probleminhas entre browsers (os browsers existirão em tempos futuros?), mas também entre dispositivos.

Acontece muito hoje: tentamos acessar um serviço por um determinado browser, e somos aconselhados a utilizar outro browser porque o serviço não é compativel ou não funciona bem no nosso browser predileto.
Isso tira qualquer um do sério. O site deveria funcionar em qualquer browser. Para exemplificar: se em um meio de acesso eu não consigo utilizar bordas arredondadas nos elementos, os elementos apareceriam sem as bordas arredondadas. Isso não deveria prejudicar minha experiência de uso. Eu perderia um pouco no Design, mas conseguiria utilizar o serviço sem problemas.

A idéia do Graceful Degradation é exatamente essa: dar a melhor experiência possível ao dispositivo/meio que o usuário estiver utilizando sem prejudicar a acessibilidade.

Os usuários do IE6 por exemplo podem ficar sem bordas arredondas, position fixed, sombras e pngs semi-transparentes, mas eles precisam acessar e utilizar perfeitamente o site, com a melhor experiência que é possivel dar a este browser.

Mesma coisa é aplicada aos dispositivos móveis. Estes dispositivos normalmente não tem os mesmos recursos de um desktop. É tudo diferente, desde o poder de processamente até o tamanho das coisas. Então imaginar que o uso do sistema/site será parecido como se fosse acessado por PC, é um erro.

É um erro também se fizermos um site pensando em dispositivos menos capazes mas não nós lembrarmos do grupo de usuarios que acessam seu site com dispositivos mais completos e modernos. É engraçado porque pensamos sempre no usuário que está no pior cenário. Mas aquele usuário que não seria um problema pra nós, pode se tornar o pior deles.

Um exemplo disso é quando usuários de iphone acessam sites inteiros feitos em Flash. Sabemos que é uma limitação do aparelho. Mas estes usuários estão crescendo e seu cliente pode estar ali. Normalmente ninuem coloca uma versão diferente da do Flash. Logo, estes usuários simplesmente são ignorados. Imagine a frustação.

Resumidamente, Graceful Degradation é dar a melhor experiência que você conseguir para o usuário.
Se ele utiliza o último lançamento da Apple ou se ele utiliza um Nokia 6111 com Opera Mini. Ele precisa ter a melhor experiência que é possível dar dentro dos limites de cada dispositivo.
Obviamente que vice não vai prever todos os tipos de usuário. Mesmo porque seria impossível fazer isso. Novamente eu digo o óbvio: faça um estudo de público-alvo é importante.

Para complementar seu estudo:

• Fault-tolerant System
  
• Graceful Degradation Dan’s Web Tips
• Graceful Degradation – CSS3.info
• Graceful Degradation Progressive Enhancement

• Ah, o maravilhoso mundo real
• Prepare-se para a Revolução
• Lançado Firefox 3.5
• Porque só para o iPhone?
• Sites para Dispositivos Móveis – MediaType

O beta da sua versão 4 acabou de ser lançado e tem uma série de modificações visuais e outras novidades.
Na sua versão beta, foram adicionados algumas características interessantes para a utilização da navegação do usuário. A Apple diz que são 150 novidades na versão 4 beta. Dê uma olhada aqui na lista completa.
Vou comentar rapidamente as que me chamaram mais a atenção.

Mudanças visuais

Houve uma série de mudanças visuais que além de impressionar, ajudam bastante na experiência de navegação. As abas por exemplo, foram colocadas no topo da página, como o Chrome. Isso facilita e aumenta a área útil do browser.

A interface do Safari no Windows segue o mesmo padrão do sistema. Em vez de carregar uma interface própria, que faz com que o programa se torne mais pesado, o pessoal da Apple resolveu fazer com que o Safari tenha o visual nativo do Windows.

Uma característica que, pelo que eu me lembre, apareceu primeiro no Opera e depois no Firefox, foi agora adotado também pelo Safari que é a Full-Page Zoom. Quando o usuário tem dificuldades para ler o texto no browser, antigamente os browsers aumentavam o tamanho da Fonte do texto. Agora, com o Full-Page Zoom, o browser dá um Zoom na pagina inteira, como se fosse um zoom no Flash. É mais interessante porque mantem o design do site intacto e resolve o problema do usuário.

Foi adicionado também proteção contra Pishing e Malware, autocompletar inteligente no campo de endereço e busca.

Desenvolvimento Web

O pessoal do Safari também implementou uma série de novidades para nós, desenvolvedores. Infelizmente, muitas coisas não poderemos utilizar por conta da falta de suporte idêntico de outros navegadores. Mesmo assim, já sabemos que o Safari está com uma série de boas intenções para ajudar a comunidade e facilitar o desenvolvimento para web.
O pessoal que desenvolveu o Safari, ainda continua levando a sério aquela história de suportar a próxima geração de padrões. Ou seja, o Safari é um dos únicos a suportar, por exemplo, HTML 5 media tags e CSS Animation.
Ele também suporta agora CSS 3 Web Fonts, isso significa que você, designer, não está mais amarrado com meia dúzia de fontes.

Sobre HTML5, o Safari agora suporta as características de Offline Support e MediaTags. Sem contar que ele passou no teste Acid 3.
Ele também está renderizando mais rapidamente scripts em Javascript. A Apple diz que a renderização do Javascript ficou 6 vezes mais rápida que o IE8 e 4 vezes mais rápida que o FF3. Alguém quer fazer o teste?

Ele ganhou também um Inspetor de código decente. Um ponto contra é que não é possível editar a página por esse Web Inspector como fazemos com o Firebug. Mesmo assim, ele é muito completo, dá para substituir a Firebug.

Eles inseriram uma série de outras novidades para que possamos controlar erros e fazer testes na hora do desenvolvimento. Realmente é um kit completo (ou quase) de desenvolvimento web. Para ver o resto das características, veja a lista completa aqui!

Se você quer saber mais detalhes sobre a compatibilidade de CSS do Safari e outros detalhes importantes, a Apple mantém uma página de apoio ao desenvolvedor web. Lá você encontra uma série de materiais interessantes sobre o desenvolvimento para Safari e informações sobre o WebKit.

O resto das mudanças são coisas que fazem o Safari se aproximar mais do Firefox e Internet Explorer. Mesmo assim, ainda acho que a Apple faz pouca “propaganda” do seu browser. Ele é muito conhecido no mundo Mac, mas ainda é um anônimo no mundo Windows!

Aos poucos o Safari ganha corpo e conquista sua fatia do mercado. A briga vai ser silênciosa como eu sempre digo, mas muito concorrida. Mais do que nunca os browsers estão entendendo a receita de conquistar os usuários e os desenvolvedores. Ponto para o Safari, mas ainda há um grande caminho para percorrer.

• O Chrome não quer dizer muita coisa
• Browsers – Guerra Fria
• IE para MAC deixado de lado (ainda bem)
• Browsers
• Web Standards Project – WaSP