HTML5 – Parte 3 – Novos elementos para formulários

Olá pessoal, tudo certin?

E não é que estou gostando do tal de HTML5?! Muito legal. Se você é novo por aqui, talvez queira ver o que já escrevi sobre o assunto:

• HTML5 – Parte 2 – Semântica para todos
• HTML5 – Parte 1 – história e elementos de estrutura

Sobre o que vamos estudar hoje? Sobre as novas capacidades para formulários do HTML5! Mas não vou esgotar o assunto.. Pretendo mostrar um cadin sobre os novos elementos , nada muito além disso.

Sem mais delongas,

Formulários HTML5 e browsers web

Infelizmente, como será demonstrado, nem todos os browsers oferecem suporte decente aos recursos de formulário do HTML5. Como você irá perceber, o IE, mesmo IE9 beta 9, ainda está bem “atrasado” com relação a essas características.. Então .. não espere muito, por enquanto.

revisitado .. Fim da estrutura hierárquica obrigatória

O elemento foi agradavelmente ampliado. Entre as novidades mais interessantes, destaco o suporte para ações HTTP update e delete, além das atuais post e delete. Outro ponto que merece destaque é que podemos colocar elementos pertencentes a um formulário fora do nodo desde que identifiquemos claramente a relação de hierarquia. Observe o seguinte bloco:

Importante: Por enquanto, essa funcionalidade só é suportada pelo Opera

O input adicionado fora do bloco do form é parte integrante do formulário.  No meu exemplo, text2 pertence a foo. Isso dá uma certa flexibilidade quando estamos pensando no design de nossas páginas.

Novos elementos para formulário do HTML5

Para mim, o grande ganho do HTML5 está nos novos elementos e no seu suporte nativo para validação. Eventualmente, nenhum JavaScript precisa ser escrito para formulários com tipos comuns. Vamos tratar um cadin disso..

Os novos tipos de campos estão na gênese da especificação que se transformou no HTML5, e é onde nós podemos ver todo o cuidado que os responsáveis pela especificação tiveram com compatibilidade retroativa. As novidades, estão associadas, quase todas, a novos valores para o atributo type do elemento input. Como todos os browsers assumem “text” como valor default para type, quando uma extensão não for reconhecida, o campo será renderizado como texto simples.

Observe que a especificação não faz qualquer exigência sobre como cada browser irá renderizar o tipo associado. Isso é muito importante pois, assim, cada tipo de campo poderá ser renderizada da forma mais adequada para cada device. Se você utilizar um iPhone, por exemplo, terá um seletor adequado sendo apresentado quando um campo for selecionado, que, por sua vez, é diferente daquele apresentado no desktop.

Emais e URLs

Repare esse bloco html:

Esse bloco “diz” ao browser que ele não deveria permitir que o formulário fosse enviado ao servidor sem que o usuário informe  um dado que pareça um email – não há qualquer verificação se esse email existe ou não, apenas se ele está em um formato inválido. Também demanda uma URL válida.

Como ocorrerá com qualquer dos elementos para formulário, dados não serão enviados se o campo for deixado em branco e o atributo required estiver presente.

Aparentemente, apenas o Chrome e o Opera adicionaram suporte para esse tipo, infelizmente!

Data, mês, semana e hora

Aqui está uma de minhas soluções favoritas nessa especificação.

• cria um formato padrão para entrada de datas;
• cria um formato padrão para entrada de hora;
• …

E esse formato é ajustado conforme o device que é utilizado. Atualmente, para dar uma idéia, o elemento para data é renderizado assim no Opera:

… e assim no Chrome:

Aparentemente, apenas o Chrome e o Opera adicionaram suporte para esse tipo, infelizmente!

Claro, estamos no começo da “coisa”. Como o bowser consegue entender o que significa cada elemento no formulári (olha a melhoria de semântica aqui outra vez), pode “chamar” a agenda do usuário que poderá conferir seus apontamentos. O ponto a ser destacado aqui é que agora o browser consegue “entender” o que o campo para entrada de datas significa – nada mais de