Nowy standard HTML5 dla automatycznego wypełniania formularzy? Zobaczysz go już w Chrome

Deweloperzy Google Chrome poinformowali o wprowadzeniu do tej przeglądarki obsługi nowego atrybutu HTML. Niby nic wielkiego, ale może rozwiązać to naprawdę dokuczliwy problem, z którym borykają się użytkownicy serwisów internetowych od samego początku istnienia przeglądarek.

Któż z nas nie kocha webowych formularzy? Mozolne wypełnianie dziesiątek pól, zwykle informacjami adresowymi, to ulubiona czynność internautów, którzy wolą ją nawet od ręcznego zamykania wyskakujących okienek. Dlatego gdy w przeglądarkach pojawiły się mechanizmy autouzupełniania formularzy, wielu użytkowników poczuło się rozczarowanych.

Rozczarowanie szybko im jednak przeszło, gdy okazało się, że autouzupełnianie działa jakby chciało, a nie mogło. Bardzo często przy rejestracji na nowych witrynach dochodzi do zupełnego pomieszania przez ten mechanizm – nierzadko w polu adres pojawi się numer telefonu, a zamiast kodu pocztowego dostaniemy nazwisko. Nie ma żadnego sposobu by te zapamiętane przez przeglądarkę dane uporządkować ani wygodnie redagować. Istniał co prawda standard dla systemów autouzupełniania, ECML – ale chyba nikt o nim nie słyszał, i nikt go nie stosował.

Teraz jednak Google postanowiło pozbawić internautów i tej zabawy. „Z przyjemnością informujemy prowadzenie w Chrome obsługi nowego, eksperymentalnego atrybutu 'autocomplete type' dla pól formularzy, który pozwoli webdeweloperom na jednoznaczne przypisanie etykiet polom tekstowym i polom wyboru. Te etykiety to standardowe typy danych, takie jak 'full-name' czy 'street-address'” – pisze Ilya Sherman na blogu Google Webmaster Central.

Jak to działa? Pole dla wpisywania adresu e-mail mogłoby być zakodowane teraz np. tak:

Przyznajmy, ta nowość w HTML5 jest naprawdę pożyteczna. Co najważniejsze, ma szanse na stanie się webowym standardem, przekazana już została grupie WHATWG. Szkic Autocomplete można znaleźć już w wiki grupy, a jej implementacja w Chrome, mimo że standardem jeszcze nie jest, pomoże w upowszechnieniu wśród webdeweloperów. Jeśli zaś producenci innych przeglądarek nie wprowadzą szybko obsługi google'owej propozycji, to można liczyć na pojawienie się rozszerzeń tworzonych przez społeczność.

Z tym umiłowaniem ręcznego wypełniania formularzy to przecież tylko żartowaliśmy.

źródło: googlewebmastercentral.blogspot.com |pic: annaOMline

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

8 skomentuj »

Komentarze

#1 amigowiec^® 2012-01-27 11:43:48 0
Wszystko fajnie, ale widzę dwa problemy:

-ułatwione działanie dla spamiarek typu Xrumer,

-o ile tego jakoś nie zabezpieczą, to niesamowicie prosta możliwość wykradania danych: wystarczy jakikolwiek formularz na stronie, w którym umieszczamy inputy z odpowiednimi x-autocompletetype a następnie ukrywamy je przez JS. Et voilà, mamy masę danych o użyszkodniku.
IP: 78.8.136.[...] IBrowse/2.4 (AmigaOS 3.9; 68K)
#2 Tom 2012-01-27 12:53:48 0
@amigowiec: Autouzupełnianie będzie działać jak to, które znamy tj. kowalski wpisuje literkę i dostaje listę wyboru, dopóki nie wybierze i nie klepnie enterek play, to w polu input nic nie ma. atrybut zaproponowany przez googla ma na celu ustandaryzowanie uzupełniania. Z moich dotychczasowych doświadczeń wynika, że przeglądarki bazowały na atrybucie "name" pola input. teraz nie będzie ważne jak webdeveloper sobie nazwie to pole ale jaki "typ" mu nada.
IP: 89.74.61.[...] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
#3 WebDev^® 2012-01-27 13:52:58 0
Kiedyś się tym interesowałem więc napiszę kilka własnych wniosków.

Sytuacja jest mniej więcej taka:

- jest kilka standardów IETF vCard czyli wizytówek elektronicznych, ale żaden z nich nie jest dobrze zaimplementowany. Praktycznie nie ma menadżerów kontaktów które w pełni wykorzystywałyby możliwości tych specyfikacji. Brakuje np. zarządzania kluczami prywatnymi i obsługi innych mniej popularnych właściwości (np. poziomu ochrony czy nagrań wymowy imienia i nazwiska).

- jest standard hCard, ale jest praktycznie martwy bo brakuje rozszerzeń ułatwiających import danych ze strony do menadżera kontaktów. Może wyszukiwarki mają trochę łatwiej.

- jest szkic standardu W3C Contacts API i nie widziałem na razie żadnej implementacji.

- no i mamy ten standard autouzupełniania.

Moja refleksja jest taka, czy nie można by tego jakoś ujednolicić. Nie ma istotnej różnicy w zarządzaniu danymi kontaktowymi własnymi lub kogoś innego. Chodzi o to, że chcemy łatwo wprowadzać dane ze stron internetowych do menadżera kontaktów i łatwo uzupełniać formularze, bez przepisywanie każdego pola. Gdzie Chrome przechowuje te dane kontaktowe, którymi uzupełnia formularze. W buforze przeglądarki? Potrzebny jest implementacja interfejsu wymiany kontaktów pomiędzy przeglądarkami internetowymi a menadżerami kontaktów.
IP: 80.55.85.[...] Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
#4 vfdsfd 2012-01-27 18:23:09 0
@WebDev®: Nie możemy ujednolicić vCard, hCard, Contacts i autocompletetype, tak samo jak nie możemy zlikwidować rowery na rzecz samochodów. Oba to środki transportu i mogą służyć do podobnych celów ale nie do identycznych. vCard i hCard jak sama nazwa wskazuje nie służy do autouzupełniania tylko to wizytówek. Contacts również jak sama nazwa wskazuje służy do ECMAScriptowego dostępu do kontaktów z mobilnych urządzeń. Jedyne co można zarzucić temu rozwiązaniu to to, że własności (x-)autocompletetype nie są definiowane w słownictwie RDF.
IP: 87.205.147.[...] Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
#5 WebDev^® 2012-01-27 21:04:39 0
@vfdsfd

Przede wszystkim ujednolicić to nie to samo co zlikwidować. Nie chodzi mi o likwidowanie tych specyfikacji tylko o to, żeby ich autorzy uwzględnili to co już istnieje i spróbowali zbudować z tego spójną działającą całość. Obecnie jest taka sytuacja, że są różne specyfikacje, opisujące różne aspekty zarządzania kontaktami, ale brakuje ich integracji. Takie połowiczne rozwiązania gdzie można np. autouzupełniać formularze swoimi danymi, ale już nie można tych danych wysłać w wizytówce vCard są tylko częścią sukcesu.
IP: 80.55.85.[...] Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
#6 vfdsfd 2012-01-28 10:56:43 0
@WebDev®: Nie chciałbym aby ujednolicali wygląd roweru i samochodu, wole jak rower ma 2 koła a samochód 4 ;) Słabo by to działało jakby w drodze ujednolicenia (np na drodze konsensusu) zrobili samochód z 3 kołami :) . A tak poważnie, wykorzystany format RFC3106, akurat on się nadawał. vCard się do tego nie nadaje, ponieważ ma "znaczniku rodziców", np N, co uniemożliwia użycie tego w autouzupełnieniach. Aczkolwiek podobnie uważam, że można wybrać było coś bardziej elastycznego np jak RDF i dzięki temu definiować dowolne słowniki podpowiedzi, które można bez problemu mapować na vCard lub nawet bez mapowania używać vCard-rdf.
IP: 77.255.51.[...] Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
#7 tomaszs^® 2012-01-30 03:11:06 0
Dobry pomysł. Chciałbym, żeby ten nowy standard również zajmował się wpisywaniem za mnie komentarzy. To odciąży mnie od tej uciążliwej pracy i zostawi więcej czasu na wpisywanie CAPTCHA.
IP: 89.69.28.[...] Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
#8 kv109 2012-01-30 15:16:34 0
Dobra okazja, żeby polecić Form Fillera dla Chrome :)

https://chrome.google.com/webstore/detail/ackpeimfmiejdmhjpjhaaannpmcfcpll
IP: 89.231.22.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.