O Google publicou um artigo no blog que mantém voltado para webmasters aconselhando a adoção de um novo parâmetro em formulários desses que encontramos a todo momento na internet. A proposta do gigante da web é muito simples: que no código-fonte do formulário apareçam atributos de HTML específicos para que o navegador complete automaticamente a informação que o usuário precisaria adicionar manualmente ali.
De acordo com a empresa, o Chrome e outros browsers já oferecem o auto-completar com alguma taxa de acerto. Entretanto, a situação ficaria ainda melhor se o navegador não precisasse adivinhar se o campo pede o nome ou o endereço de email, por exemplo.
Se depender do Google, a seguinte estrutura será adotada nos formulários:
<input type=”text” name=”field1” x-autocompletetype=”email” />
Repare na presença do atributo “x-autocompletetype”. Por meio dele o desenvolvedor especifica qual é a informação que o campo apresentado e, assim que lê isso, o navegador pode adicionar a informação automaticamente. Para tanto, como você já deve saber, o auto-completar tem que estar ativo no browser. Além disso, o usuário precisa ter preenchido a informação antes pelo menos uma vez para que fique salva.
Até agora só o Google se comprometeu com o atributo e disse que ele está instalado no Chrome. Outras empresas que oferecem o auto-completar devem implementa-lo, mas o Google não disse quais são essas companhias. Ainda é importante observar que o atributo foi lançado em caráter experimental e não passou por endosso do W3C, o consórcio que regula os padrões para a web. Pode ser que venham a adota-lo no futuro, pode ser que não.
Cá no Tecnoblog o Google Chrome é o navegador mais utilizado. E como temos muitos leitores que trabalham com web, não custa nada dar o recado: o atributo está aí para quem quiser implementar.
Aqui tem o texto completo relatando a proposta de atributo.
Atualizado às 19h20.
Assine pelo iTunes
Assine pelo Feed
Boa!!
Acho que seria melhor propor um padrão de nomenclatura de id, assim iria validar no W3C.
Dai já é gambiarra…
Gambiarra o campo de email se chamar “email”?
Legal, aí vc tem 2 campos de e-mail no mesmo formulário e os dois terão o mesmo id e nome.
Os dois campos de email terão o mesmo e-mail?
Sim, gosto que meus usuários informem o mesmo dado repetidas vezes (ironia). Sério, dá uma lida no que vc propôs e analisa isso de forma funcional.
Calma, rsrs. Eu fiz a pergunta exatamente por isso, os dois campos não terão o mesmo id, pois não terão a mesma informação.
O que eu quis dizer com a minha sugestão, é que se o desenvolvedor quer facilitar para que os dados do usuário sejam preenchidos automaticamente, bastasse colocar os ids dos campos de acordo com o conteudo, mas sem obrigação nenhuma de fazer isso e nem ter de colocar em inglês como disse o Scott.
Se você tem dois campos de e-mail, provavelmente eles não terão o mesmo e-mail e você não precisará inserir o x-autocompletetype=”email” nos dois, pois se fizer isso estará dificultando pro usuário e não facilitando, o mesmo aconteceria com o id. O type também não daria certo.
Agora, o Carlos ali em baixo disse que a maioria dos frameworks deixariam de funcionar, não tinha pensado nisso.
Obrigar todo mundo a chamar o campo para cidade de “city” e o para endereço de “street” é gambiarra.
O ID? É mais fácil fazer uma tipagem nova. O ID é muito relativo, depende dos padrões de como a página ou sistema web vai seguir.
sim tipagem, seria uma otima solução, até mesmo para validações. Ex: type=”email”, type=”seach”, type=”name” e por ai vai….
Sim, isso sim seia ótimo.
A tipagem é outra história. Ela define o jeito que o campo deve ser preenchido, mas continua limitada quando existe mais de um campo do mesmo tipo em um mesmo form, mas com significados diferentes – telefone residencial, comercial e celular, por exemplo.
Tinha q padronizar o nome da tag (nada de “x-”…) e os conteúdos válidos nessa tag, não name e id.
Se isto acontecesse a maioria dos frameworks web deixariam de funcionar.
Bem legal esse atributo de auto complementar, como você disse o navegador não vai precisar adivinhar o que o campo pede – como você já disse. Mas como sempre só funcionará no Chrome e provavelmente no Opera, sendo adotado pelos demais apenas se ele for reconhecido pela W3C.
HAHHAHA, tiraram o “programam em HTML…”. Já ia tirar uma onda.
O que dá medo é que com o passar do tempo esses seguidos recursos criados pelo Google para o Chrome o transformem em um novo Internet Explorer, um navegador fora dos padrões.
Mas com uma pequena diferença: ele não está usando esses recursos em detrimento dos padrões existentes, mas sim adicionando uma opção a mais. Quem quiser continuar com o padrão, tá tranquilo.
Bem colocado o comentário do Micael, para mais esclarecimento recomendo fortemente a leitura do post http://www.pcmag.com/article2/0,2817,2397158,00.asp
Para quem viveu a época sabe do que ele está falando!
Ótimo texto. E bons comentários também.
Espero que não aconteça, outro internet explorer nããããão! o.o :S
Realmente, parece que ele está seguindo esse caminho. Ainda bem que ele tem atualização automática.
Apesar que se for para identificar a informação contida em um campo, em HTML5 já existem tipos específicos com este propósito. Exemplo: type=date, type=email, type=datetime, type=url, type=color, etc.
Bem lembrado, e de quebra já vem com validação
É diferente.
Essas identificações do HTML5 apenas descrevem o tipo dos campos, não o conteúdo deles.
Afinal, podemos ter um campo de data para aniversário, outra para a data de lançamento de alguma outra coisa, etc.
A idéia é especificar ainda mais o conteúdo do campo, afinal, em um cadastro de endereço, temos: endereço, complemento, bairro e cidade, e todos são – geralmente – campos do tipo texto.
Vinicius,
Você não entendeu, o atributo type no html5 poderia também servir para isso.
Hoje com o atributo type do html5, ele traz um campo difirente, por exemplo para numero, ele traz o botão para cima e para baixo, e faz validação também para o tipo do conteúdo.
Agora é obvio que esse atributo não contempla tudo, como endereço, nome entre outros, nesse caso não seria redudante.
Eu entendi, você parece não ter compreendido a intenção.
O atributo type do elemento input do HTML5 define como deve ser feita a entrada de dados e qual a validação necessária para esse campo – em resumo, define a sintaxe.
Ele não diz – nem poderia dizer, dadas as limitações – qual o valor semântico que esse campo tem, informação a qual o auto-completar tenta adivinhar pelo nome do input, e muitas vezes erra. ou acha que não tem a informação, porque o nome é diferente.
A proposta é de que com esse novo atributo, os campos de um form tenham um contexto definido e já possam vir com os valores corretos preenchidos – ou permitir a escolha ao clicar sobre o campo, enfim.
Cara
vamos ao exemplo dado aqui:
autocomplete type é email.
cada vez que eu digitar algo em um campo com autocompletetype email eu vou salvar no browser todos os emails, e fornecer posteriormente a cada vez um um campo similar(similar me refiro a ter o mesmo atributo) receber o foco vou autocompletar
cada vez que eu digitar algo em um campo TYPE email eu vou salvar no browser todos os emails.
O que acontece hoje é que os browsers olham o name, e isso varia de programador para programador!
Hoje com a pequena quantidade de tipos de input o melhor é arriscar o name, mas quando tivermos tipos bem definidos a necessidade desse atributo não se faz necessário, a não ser que seja necessário especificar mais ainda…
Só pra esclarecer, atributo type do HTML5 diz respeito ao tipo do campo (email, texto, data, cor, etc) – COMO O CAMPO DEVE SER PREENCHIDO.
O atributo proposto x-autocompletetype diz respeito ao conteúdo do campo – por exemplo: endereço, telefone, nome, sobrenome, nome do meio, etc – que são todos do mesmo tipo (type=text no caso) – COM QUE VALOR JÁ SALVO O CAMPO PODE SER PREENCHIDO.
Mesmo no HTML5, o atributo type do input ainda fica limitado a definir os tipos de entrada (o que faz sentido). O atributo type não tem como dizer QUAL dado deve ser preenchido, apenas COMO deve ser preenchido.
Ou você quer que o W3C defina tipos para endereço, telefone residencial, telefone comercial, celular, bairro, cidade, etc?
Desisto
Ué, mas porque o Chrome deveria saber se é uma data de lançamento ou aniversário, o que isso interessa pra ele? É apenas data não?… não entendi essa colocação…
Preenchimento semi-automático de formulários usando o recurso auto-completar, aumentando a chance de acerto.
Pensando pelo lado de acerto, realmente serve, mas se a W3C não aprovar eles não tem nem o porque continuar, se não vai virar bagunça…
Aqui eu to defendendo a motivação e a utilidade do campo, não necessariamente a implementação.
Problema da W3C, é que eles tão mui devagar, e mui indecisos ainda. Eu entendo que é preciso cautela na definição de novos padrões, mas meu deus hein.
Mas, se for feito da maneira certa, mesmo que não seja definido formalmente, pode virar um padrão involuntário, como é o bloco ID3v2 no MP3.
Sempre achei a ideia de adivinhar o conte[udo do input pat[etica, espero que a WC3 aprove. Quero ver isso em todos os browsers.
O que vai ter de form oculto com isso… hahaha
eu tenho uma muiiiiiitttttoooo melhor que essa do google. Pq nao faz um cadastro unico para a internet? tipo eh um saco ter que ficar preenchendo essas coisas toda hora. Com um “cadastro unico” ficaria bem mais facila vida de todos, seja para as emprensas “roubar” nossos dados e gostos na web, seja pra nao ter que ficar preenchendo um tanto de coisa qdo for solicitado.
Eu eim… não quero meus dados em todos os cantos da internet…
Tipo… openID?
Só por não passar no endosso da W3C, eles já deviam deixar de lado, guardado para num futuro, se a W3C utilizarem, eles também implementarem. Parece um navegador antigo que conheço por aí…
Inútil! O HTML5 já tem atributos para formulários, que serve exatamente para dizer ao browser que tipo de dado deve ser inserido no campo!
Os browsers (até onde sei, nenhum possui suporte ainda) só necessitam dar suporte a tais atributos e autocompletar conforme ele. Não criar algo mais complicado que faz exatamente o mesmo e mais limitado!
O tipo de dado não indica que valor deve receber. Tipo, se tem lá um cadastro de endereço, o campo com o nome da rua, bairro e cidade são todos do tipo texto. Como é que o navegador vai ter certeza que no campo de bairro ele deve preencher com o bairro e não com a cidade?
Corroborando:
Imagina um campo do tipo “telefone” (admitindo que houvesse um padrão para isso).
Daí no cadastro você tem, “Residencial”, “Comercial” e “Celular”.
É legal vir os três preenchidos com o mesmo número?
gambi mode ON
Atualmente ele se guia pelo nome do campo, mas com cada desenvolvedor criando um nome “adebundê” do jeito que acha melhor, e nos mais diversos idiomas, onde num lugar ele se chama “login” no outro ele é “usuario”, ou “user” ou “operator”, e por aí vai. Endereço? Email? Aí a coisa vira zona, mesmo. A proposta do google faz sentido, mas se não houver contrapartida da comunidade, não servirá de nada
Isso mesmo… define o tipo da informação que o campo guarda, e um pouquinho de javascript(? ou sei lá) pode fazer a mágica de capturar todos os seus dados armazenados em autocompletar…
A ideia é bacana, mas tem que planejar bem como implementar isso nos padrões.
Não concordo!
É só usar HTML 5 corretamente. O navegador não precisaria adivinhar se o campo pede um nome ou email se o campo for assim:
Isso já existe e é puro HTML!!!
Vejo que a discussão continua correndo solta nesse artigo. Apenas para complementar, parece-me que algumas informações, como email, estão previstas no HTML “atual”. Entretanto, na proposta do Google eles falam e adicionar outros campos previstos como atributos em formulários do HTML5. São eles número do cartão de crédito, nome impresso no cartão de crédito e informações similares.
Acho que isso vai vingar… veremos o que o pessoal do W3C vai decidir…