HTML5 – Parte 3 – Novos elementos para formulários

Publicado em 14/10/2010

10


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:

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.

<form> revisitado .. Fim da estrutura hierárquica obrigatória

O elemento <form> 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 <form> desde que identifiquemos claramente a relação de hierarquia. Observe o seguinte bloco:

<!doctype html>
<title>Forms</title>
<form id=foo>
   <input  name="text1" type=text>
   <input type=submit>
</form>
<input  form=foo name="text2" type=text>

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:

<input type=email required>
<input type=url required>

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!

image

Data, mês, semana e hora

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

  • <input type=date> cria um formato padrão para entrada de datas;
  • <input type=time> cria um formato padrão para entrada de hora;
  • <input type=month> …
  • <input type=week>

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

image

… e assim no Chrome:

image

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 <div> ou <span>, e links para javascript. Agora o browser sabe que se trata de informação de data ou hora e, consequentemente, consegue promover a integração adequada.

Números e intervalos

Considere o seguinte bloco html:

<input type=number min=0 max=100 step=5>

Pegou a idéia, certo? Use:

<input type=range min=0 max=100 step=5>

E teremos algo assim no Opera:

image

E assim no Chrome:

image

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

Bem menos trabalho que tinhamos antes para fazer a mesma coisa.

Outros elementos

A especificação prevê outros tipos de entrada, além dos descritos aqui. Por exemplo, há um tipo para telefones (tel) e outro para cores (color). Entretanto, esses tipos não foram implementados, ainda, por nenhum browser para desktop.  O tipo para telefones já foi implementado no iPhone, e o tipo para cores já foi implementado no BlackBerry.

Suporte a máscaras

Além dos tipos específicos para diversos tipos de dados, também podems especifica uma máscara para controlar a entrada. Observe:

<input 
      pattern="[0-9]{5}(\-[0-9]{3})?"
      title="CEP">

Esse campo somente aceitará números no formato especificado (CEPs, com ou sem complemento).

Aparentemente, apenas o Chrome oferece suporte a esse recurso atualmente.

Definindo HTML5

Como iniciamos no último post, durante essa série, na medida em que vamos conhecendo mais detalhes do HTML5, vou tentar ir criando uma definição para a linguagem. Com o que temos aqui, podemos dizer que:

HTML5 é a sucessora oficial para o HTML 4.01, que está sendo desenvolvida paralelamente pelo W3C e pelo WHATWG, que dá ênfase maior para a semântica do que para a sintaxe. Incorporou mais significado aos documentos mediante novas TAGs de indicação ao conteúdo. Além disso, simplificou drasticamente a criação de formulários reduzindo muito a necessidade da escrita de código JavaScript que valide decisões.

Por enquanto, é o que temos. Vamos avançar mais nos estudos para poder complementar essa definição! Entretanto, gostaria de destacar que parece ter havido um esforço na direção de mover para especificação tudo que era repetitivo nos desenvolvimentos de documentos Web. Foi assim com a substituição de classes por tags (mais semânticas) e agora com a inclusão de tipos de entrada comuns (dispensando JavaScript)

Bem,

Por hoje, era isso.

Etiquetado:
Publicado em: Sem categoria