Desde 2010 acompanhamos de perto toda a evolução do HTML5 até ele finalmente se tornar uma recomendação do W3C. Entra elemento de um lado, sai atributo de outro, até que, em outubro de 2014, presenciamos a publicação de um padrão que já era amplamente utilizado por desenvolvedores e por boa parte do mercado. Foi um enorme avanço que a Web precisava há muito tempo. Mas e agora? Para onde caminha a padronização das tecnologias Web?

A resposta mais simples seria o HTML6, certo? Nem tanto. Ainda existem elementos e atributos que ficaram de fora ou que não foram discutidos com sua devida importância. Partes da especificação, como os input types relacionados a meses e semanas, que estavam previstos nas primeiras versões do HTML5 e agora estão no Working Draft da versão 5.1 são apenas alguns dos exemplos.

E as folhas de estilo? Quanto tempo ainda vamos esperar para ter as CSS3 como uma recomendação do W3C? Calma, jovem Padawan. Hoje as coisas estão mais dinâmicas. As especificações de CSS estão saindo de forma modular. A grande vantagem dessa forma de publicar especificações é que ela não costuma demorar tanto para sair. Conforme os módulos vão ficando maduros, tornam-se recomendações do W3C. É o caso de diversas especificações, como CSS Color Level 3, Selectors Level 3 e Media Queries, além das especificações em conjunto com outros grupos, como o Motion Path Module Level 1, publicado como Working Draft no último dia 9 de abril em conjunto com o grupo de trabalho de SVG. Vale também lembrar que o grupo de trabalho de CSS já está trabalhando em diversas especificações para CSS level 4. A lista completa está na página do grupo de trabalho.

Acredito que estamos em um momento importante do desenvolvimento de tecnologias de uma forma cada vez mais colaborativa e participativa. Tecnologias abertas para consumo de dados e informações das mais diversas aplicações. Novas APIs estão surgindo na mesma velocidade das aplicações, e isso torna a vida do desenvolvedor muito melhor, que pode fazer uso de uma interface rica para o acesso às aplicações.

E o que eu faço com esse monte de APIs? Podemos fazer o que o IFTTT nos sugere, por exemplo: coloque a Internet para trabalhar para você. A aplicação disponibiliza um campo que pode ser configurado para executar determinada função de uma aplicação quando algo acontecer (If This Then That). A aplicação apenas se conecta a um conjunto de aplicações com APIs públicas que permitem a troca de informações para executar determinadas ações, como “publique uma foto no Twitter quando uma imagem for publicada no meu Instagram”. E isso pode ser explorado mais a fundo nos seus objetos conectados, como “se o sensor de movimento da minha casa detectar algo, mande-me uma mensagem pelo WhatsApp”, ou algo assim.

Considerando esse mundo pós-recomendação-HTML5, não vou esticar a conversa sobre as APIs de Geolocation ou Touch Events, que são recomendações desde 2013. Eu gostaria de explorar neste texto algumas das recentes APIs que ainda estão em seu processo de desenvolvimento.

As APIs para aplicações mobile são interessantes, pois não valem somente para smartphones ou tablets. Dependendo da aplicação, alguns wearables podem fazer uso em uma aplicação Web. Pulseiras e relógios podem muito bem ter aplicações que usem a Vibration API para controlar o mecanismo de vibração do dispositivo. Esses mesmos dispositivos e outros como roupas, óculos ou eletrodomésticos podem usar a Battery Status API para acessar informações de status de bateria e adaptar a aplicação para um melhor desempenho, dependendo do percentual de carga da bateria, e por aí vai. O W3C também publicou uma API bem interessante para a definição de interfaces para Gamepads (ainda em Working Draft).

Mas falar em wearables conectados é muito 2015! Cada vez mais, teremos objetos conectados e nem vamos mais perceber como eles interagem e interferem em nossa vida. Dados trafegarão pela nossa roupa, pele, casa, cidade e por lugares nunca antes imaginados. Por esse motivo, a padronização é extremamente importante, para que não tenhamos silos isolados de aplicações que não se comuniquem e que sejam seguras e garantam a privacidade do seu usuário ou “dono”, como queira chamar a pessoa que porta essa aplicação em seu corpo, casa ou cidade.

A quantidade de dados trafegados por objetos conectados será cada vez maior, por isso a padronização desses dados é fundamental para garantir que eles possam se conectar a outros dispositivos e até serem combinados com outros dados. A marcação semântica em uma quantidade tão grande de dados deve ser considerada como algo de grande importância e impacto. Nesse aspecto, o W3C já trabalha há anos com a Data Activity. Além das especificações, destaco os trabalhos de coletar e publicar boas práticas no uso de dados na Web, como o que é feito pelo grupo Data on the Web Best Practices.

Segurança e privacidade ainda são temas relevantes quando se fala em Web, em qualquer âmbito. Desde os primeiros formulários embutidos nas páginas até as mais ricas aplicações Web embarcadas em dispositivos móveis devem ter sérias considerações quanto a suas políticas de segurança e privacidade. Mesmo com as atividades do Security Activity (que discute questões como Criptografia e Pagamentos na Web) e do Privacy Activity (que aborda temas como Tracking Protection), é fundamental que o debate envolva todos: de desenvolvedores a usuários. Todos nós devemos lutar por uma Web segura de verdade.

Creio que num futuro bem próximo os dados transitarão de forma muito mais ampla em uma rede largamente conectada, possibilitando-nos fazer consultas, análises e trocar dados com nossos serviços de saúde, seguros, entretenimento etc. de forma muito mais rápida, dinâmica e amigável ao usuário final. Muitas dessas aplicações quase invisíveis usarão a Web como ponte ou como interface. Não vai mais existir o Mobile Web. A web estará em tudo: dos dispositivos móveis a imóveis (como a sua casa). Nesse sentido, o HTML5 foi um marco no desenvolvimento da Web, como muitos outros ainda serão.