*******************************************************************************
 DOCUMENTAÇÃO
*******************************************************************************
 O servidor pode inserir mensagens que derivam de validações que o cliente não
 pode replicar (por exemplo, para ver se determinado ficheiro existe). A
 natureza dessa mensagem é assinalada por um "data-vemsg" vazio (mas
 existente).

 A validação de grupo ocorre apenas se todos os campos forem válidos.

Valores para "t":
  - 1 (modInstall): valida tudo menos nulos;
  - 2 (modInstall para campos não-correntes): valida tudo menos nulos;
  - 3 (onChange:isTrusted = false): valida tudo menos nulos;
  - 4 (onInput): só valida se estiver com erro;
  - 5 (onChange): valida tudo;
  - 6 (onSubmit): valida tudo.


*******************************************************************************
 NOTAS
*******************************************************************************
- N1 (msg.js): Ao colocarmos já o id da caixa do erro, antecipamos o seu
  impacto real no posicionamento de elementos. Por exemplo, sem isto, poderia
  causar deslizamento numa página antes de ter a classe e depois, sem ela,
  voltar a não o causar -- isto faria a caixa ficar desalinhada com o campo.

- N2 (cli.js): Altera tipos avançados (date, number, etc) para "text", de forma
  a que as regras impostas pelo navegador não interfiram com a validação do
  FormValidator.

- N3 (cli.js): A borda do "offsetParent" do rótulo afecta, dependendo do
  navegador, os valores do "offsetLeft" e "offsetTop" -- no Firefox afecta, no
  Chrome não.

- N4 (cli.js): A formatação de valores é feita apenas nos campos de texto, pois
  doutra forma entrariam em conflito com o navegador. Já a filtragem pode
  variar conforme o tipo.
  Ver também o parâmetro "retype" de go().

- N5 (cli.js): Pelo menos no Firefox, as alterações ao DOM que o FormValidator
  executa para assinalar o campo que tem o foco, fecha uma lista que tenha
  sido aberta e activada (ou seja, não tinha o foco antes) com um clique.
  Contorna-se esse problema, antecipando o foco de campos desse tipo para o
  momento em o rato é premido.

*******************************************************************************
 A FAZER
*******************************************************************************
- Antecipar a necessidade de módulos adicionais e passá-los a preload().

- A primeira apresentação de uma mensagem de erro deve aparecer progressivamente.

- Contornar o facto dos <SELECT> não dispararem o "oninput".

- Implementar intervalos de datas.

- Quando um campo está a ser validado em tempo real (a reagir a "oninput"), converter a
  mensagem de erro numa mensagem a dizer "Ok", ou "Correcto", a desaparecer lentamente.

- Incluir lista de campos nas mensagens de erros de grupo.

- Em "msg.js", replicar a técnica usada pelo checkRight_() nas funções do mesmo tipo, que
  é suficiente -- verifica-se se o campo seguinte(/anterior) ficaria debaixo da mensagem
  se colocada no lado em causa, e aplica-se penalizações se for o caso.
  (Ver http://cmdoc.cmmartins/documentos-por-classificar/Docs-UM-2010.1.jpg/form)

- O posicionamento da mensagem também deve ter em conta que ela por vezes se refere a um
  grupo e não a um elemento. Nesses casos, não faz sentido ter em conta o rótulo, que é o
  que acontece agora.

- Tocar um som para quando são detectado um erros na validação do formulário.

- Implementar a apresentação de dicas nos elementos desactivados para explicar o porquê do
  seu estado. Essa informação poderia ficar na propriedade "data-why" e seria apresentada
  em conjunto com o eventual título do rótulo.

- Criar sistema flexível para a definição de mensagens personalizadas. Por exemplo: deve
  ser possível apresentar a mensagem «Introduza o seu nome» em vez de «Este campo tem de
  ser preenchido».

- Carregar dinamicamente o CSS para a apresentação de erros.

- Ao seleccionar um campo num <FIELDSET> deve seleccionar o elemento todo, porque funciona
  como um único campo.

- Implementar o teste efectivo de URIs e endereços de correio electrónico, comunicando com
  os servidores respectivos.

- _getvar() deve variar em função do tipo de campo; por exemplo, os atributos "min" e
  "max" dos campos de datas estão definidos para receberem valores no formato aaaa-mm-dd,
  mas devem ser apresentados no formato mais natural para cada utilizador.

- Quando o utilizador abandona a página com uma edição a meio (ou seja, já alterou
  campos), deve ser avisado ou por intermédio de uma mensagem no "onunload" da página (que
  provavelmente terá consequências na "bfcache" do Firefox), ou as alterações devem ser
  gravadas num "cookie" ou na base de dados local e repostas na visita seguinte. Esta
  última opção é superior mas implica que haja algum mecanismo que permita ao utilizador
  verificar na visita seguinte que está a ver certos dados que não foram guardados.

- Garantir que não anula a fbcache;

- Permitir associar erros com não-campos;
  (Por exemplo, um <TD> com um total calculado do documento e que tem de ser positivo.)