Kontynuując poprzedni artykuł chciałbym wyczerpać temat. Zgodnie z agendą pozwolę sobie zająć się dzisiaj nowymi atrybutami, typami, pseudoklasą :dir, a także dwiema metodami, które w mojej opinii zasługują na uwagę.

Na koniec wyrażę swoją opinię nt. rekomendacji HTML 5.1 oraz przekażę co w trawie piszczy, czyli jak przebiegają przymiarki do wersji 5.2.

 

Zmiany, zmiany

W poprzednim artykule ukazała się agenda, które punkty chciał po kolei przeanalizować. Tutaj dla zachowania kolejności przytoczę ją ponownie, by później rozwijać kolejno punkty zapisane wytłuszczoną czcionką.

  1. Nowości
    1. Elementy
      1. menu, menuitem, contextmenu
      2. details, summary
      3. dialog
      4. picture
    2. Atrybuty
      1. srcset
      2. sizes
      3. allowfullscreen
      4. autocomplete
      5. inputmode
      6. nonce
    3. Typy
      1. datetime
      2. datetime-local
      3. week
      4. month
    4. Pseudoklasy
      1. :dir()
    5. Metody
      1. forceSpellCheck
      2. reportValidity

 

Podobnie, jak poprzedni, ten wpis nie będzie należał do najkrótszych, ale … skoro tak rzadko mam czas ostatnio pisać, uznajmy że to na znak rekompensaty 🙂

Testy przeprowadzam na następujących wersjach przeglądarek:

  • Mozilla Firefox 42.0
  • Google Chrome 55.0
  • Opera 41.0

 

Atrybut allowfullscreen

Zapewne kojarzycie taki atrybut chociażby z zagnieżdżonych ramek. Ale tym tutaj rozchodzi się o typ tego atrybutu. Do tej pory spotykaliśmy się zapisami takimi, jak:

allowfullscreen="allowfullscreen"

Przyznam się, że jest to tak samo dziwne jak:

disabled="disabled"

Cóż z twórcami się nie dyskutuje. Wracając do tematu. Pomimo występowania tegoż atrybutu, nie znajdował się on w standardzie HTML5! Zakładam, że stanowił on zabiegi producentów na poczet „draftów” rekomendacji itp. itd. Niemniej wraz z wersją 5.1 pojawił się i jest typu Boolean. Aby mieć możliwość ustawienie iframe w tryb pełnoekranowy (wykorzystując metodę requestFullscreen()) konieczne jest ustawienie tego atrybutu na true.

Żądanie trybu pełnoekranowego można wywołać do dowolnego elementu.

Wszelkie testy jakie na potrzeby wpisu przeprowadziłem spaliły na panewce. Na każdej przeglądarce odniosłem wrażenie jakoby atrybut był ignorowany i został zastąpiony dobrze nam wszystkim znanymi chmurkami pytającymi czy zezwolić na fullscreen, czy blokować.

Może być też tak, że czegoś tutaj nie rozumiem…

 

Autocomplete

Tutaj, aby dojść do sedna zmian musiałem przeanalizować sekcje w rekomendacji 5.0 i 5.1. Ciężko się czyta takie surowe dokumenty. Dodatkowo czytany tekst nie musi mieć pokrycia w rzeczywistości. Cóż, życie!

Do tej pory wartość atrybutu autocomplete była jednym z dwóch słów kluczowych „on” i „off„. Czy i jak to funkcjonowało zapewne wiecie. Przeglądarka podpowiadała wartości wcześniej wprowadzone w input o wskazanym atrybucie name – nie musiało to być z tej samej domeny.

Przynajmniej tak rzecz ma się w Google Chrome. Z tego co widziałem w Firefox temat zapamiętywania danych ograniczony był do danych logowania. Jednak tutaj mogę nie być obiektywnym źródłem informacji, gdyż w testowym środowisku nie miałem danych historycznych, przez co mimo chęci przeglądarka mogła nie mieć zwyczajnie co podpowiedzieć.

Przejdźmy do testów. Bardzo ciekawy przykład znalazłem w dokumentacji W3Cfiddle.

Dla lepszego zrozumienia zajmijmy się fragmentem:

<label> Address: 
  <input name=ba 
     autocomplete="section-blue shipping street-address">
</label>

 

Chrome – autopodpowiedzi

 

Ok, Chrome ładnie podpowiada historyczne adresy. Teraz pytanie, czy Google jest tak cwany i sprawdza oprócz atrybutu autocomplete także wartość elementu label, czy może już teraz grupuje zapamiętane dane zgodnie z rekomendacją? Sprawdźmy.

Zmiana na:

<label> Email:
  <input name=ba 
    autocomplete="section-blue shipping street-address">
</label>

… i nadal podpowiada adresy.

Zatem zróbmy odwrotnie:

<label> Address:
  <input name=ba 
    autocomplete="section-blue shipping email">
</label>

Tym razem podpowiedzi dotyczyły adresów e-mail. Wniosek zatem nasuwa się taki, że przeglądarka już grupuje po specyficznych dla pola tokenach.

Z uwagi na to, że w przykładzie atrybut name jest mocno losowy, nie ma mowy aby on odgrywał rolę w generatorze podpowiedzi. Sprawdźmy teraz czy i jak działa heurystyka przeglądarki. W tym celu zobaczmy poniższe wersje kodu:

<label> Address: <input name=ba autocomplete="on"></label>

<label>Email: <input name=ba autocomplete="on"></label>

<label><input name=address autocomplete="on"> </label>

<label>Email: <input name=address autocomplete="on"></label>

<label>Address: <input name=email autocomplete="on"> </label>

<label>Address: 
  <input name=email 
    autocomplete="section-blue shipping country-name">
</label>

Mamy teraz wszystko jak na talerzu. Poniżej wyniki każdej wersji (kolejno):

  • adres
  • e-mail
  • adres
  • adres
  • e-mail
  • kraj

Dla przeglądarki najwyższy priorytet ma wartość atrybutu autocomplete, następnie name, na końcu treść z elementu label.

Kod:

<label>: <input name=ba autocomplete="on"></label>

spowoduje brak reakcji przy próbie wymuszenia odpowiedzi (brak dopasowań), czemu nie ma co się dziwić.

W celu upewnienia wartość „off” faktycznie blokuje podpowiadanie. Postanowiłem to sprawdzić, gdyż w przeszłości różnie bywało z uznawaniem tej wartości w przeglądarkach (piszę z doświadczenia). Tak, czy inaczej podczas testów „crossowych” warto sprawdzić zachowanie pól – zwłaszcza gdy autocomplete=”off”, gdyż dotyczą one przeważnie danych wrażliwych.

Listę tokenów identyfikacyjnych znajdziecie pod tym adresem. Ciekawostką jest fakt, że możemy przypisać pole do określonej grupy poprzez użycie tokenu w postaci: section-nazwagrupy. Oprócz tego wyznaczono dwa tokeny zbiorcze:

  • shipping (wiąże dane z adresem wysyłki lub danymi kontaktowymi)
  • billing (wiąże dane z adresem rozliczeniowym lub danymi kontaktowymi)

Tokeny są case-insensitive.
Tokeny w atrybucie autocomplete rozdzielamy spacją.

 

Inputmode

Podczas pierwszego zderzenia z tym słowem nie wiedziałem do końca z czym to się je. Jest jednak dużo prostsze wytłumaczenie aniżeli dla poprzednio omawianego atrybutu. Inputmode odnosi się do trybu wejścia w elemencie input. Dla przykładu – można ustalić inputmode na wartość latin i wspierać znaki wyłącznie alfabetu łacińskiego. Pełna tabela wartości inputmode znajduje się tutaj. Jest jednak pewien problem. Wsparcie w przeglądarkach jest wyłącznie wirtualne i na razie wyłącznie w Firefoxie. O losie…

Można skorzystać z funkcji wyłącznie w przypadku zmiany flagi dom.forms.inputmode. Dla testów skorzystam z tej furtki.

Aby dokonać zmian tej flagi należy wpisać w pasku adresu przeglądarki Firefox „about:config”

I po testach 🙂 Pomimo ustawienia flagi na true i testów na fiddle oraz z wykorzystaniem tej strony nie widziałem żadnej różnicy w działaniu pól. Myślę, że dodawania do rekomendacji funkcji będącej w tak głębokim „średniowieczu” po prostu nie przystoi.

 

Nonce

Dodając ten atrybut organizacja spełniła obowiązek, gdyż będący już w zaawansowanym wieku mechanizm CSP wykorzystuje ten parametr w swoim działaniu. O jego wykorzystaniu pisałem w artykule: CSP – sposób na XSS, Clickjacking, CSS-Injection i inne.

 

Typy datetime, datetime-local, month, week

Wsparcie 69,22% (pełne + 9,28% częściowe):

  • Edge 13+
  • Chrome 20+
  • Opera 10.1+
  • iOS Safari 5.1+ (częściowe)
  • Android Browser 4.4+
  • Blackberry Browser 10+
  • Opera Mobile 12+
  • Chrome for Android 54+
  • FF for Android 50+
  • UC Browser for Android 11+
  • Samsung Internet 4+

Brak wsparcia dla IE, IE Mobile, FirefoxaSafari. Nie można powiedzieć, że jest to nieznaczące. Funkcja wydaje się, że zaadoptuje się w standardzie, jednak trudno o optymizm, gdy FirefoxSafari w ogóle nie próbują jej wdrożyć.

Test można uruchomić tutaj. Efekty działania w galerii poniżej:

 

Pseudoklasa :dir()

Wsparcie dla odmiany wyłącznie w Firefoxie (49+, mobilny 50+). Jest ściśle powiązana z atrybutem dir, który jest dziedziczony. Przykład znajduje się tutaj.

Zauważcie, że właściwość direction w arkuszu CSS nie nadpisuje atrybutu!

 

Metoda forceSpellCheck

Żadna przeglądarka jeszcze nie wspiera tej funkcji (w ogóle), co czyni ją szczególną. Rekomendacja zakłada, że dla każdego elementu będzie można sprawdzić pisownię. Ciekawe, jak to będzie wyglądać w praktyce.

 

Metoda reportValidity formularza

Wsparcie na pewno przez Chrome, Firefox, Operę. IE Edge nie przeszło pomyślnie testów. Nie dokopałem się natomiast do szczegółów, od której wersji która przeglądarka obsługuje funkcję reportValidityHTML5 zapewniał funkcję checkValidity, jednak wiąże się ona wyłącznie ze sprawdzeniem bez „wyrzucania” natywnych dymków z informacjami o jej stanie. Dlatego wprowadzono reportValidity, a jej działanie możecie sprawdzić tutaj.

 

Podsumowanie

Bardzo się cieszę, że przeżyłem ostatnie dwa artykuły. Niesamowite jest to ile dowiedziałem się nowych rzeczy na tematy, o których słyszałem, które postanowiłem Wam przedstawić, ale nie mogłem pozwolić sobie na to bez głębokiego sprawdzenia każdego elementu.

Do bardzo pozytywnych zmian zaliczam bezdyskusyjnie element picture wraz z atrybutami srcsetsizes. Niesamowite możliwości tkwią tej nowince. Podobnie rzecz wygląda z atrybutem autocomplete, gdzie otwiera się przed nami możliwość kontroli gdzie i jakie wartości wcześniej wpisane w formularzu (w ramach jednego serwisu) mają zostać podpowiadane. Jednak tutaj jeszcze musimy trochę poczekać na producentów przeglądarek, by wszyscy stanęli na wysokości zadania.

Z kolei do największych błędów rekomendacji zaliczę inputmode (pozornie wspierane wyłącznie przez Firefox) oraz pseudoklasę :dir (chyba że poprawione zostanie zaniechanie właściwości direction).

W ogóle ciekawe jest to z jak wielu funkcjonalności (pierwotnie założonych) zrezygnowaniu w trakcie „draftu”:

  • dialog
  • inert (wyłączenie interakcji dziedziczone wgłąb)
  • sortowania tabeli
  • zakresowe style (scoped styles)
  • seamless iframes (czymkolwiek to miałoby być)

Prace trwają już na wersją 5.2, a w niej przede wszystkim liczę na w/w brakujące elementy aktualnej rekomendacji. Chodzą jednak słuchy, że w wersji 5.2 pojawią się:

  • skrypty typu module (moduły JS wraz z zależnościami)
  • meta tag theme-color (do zmiany UI)
  • element datalist
  • atrybut autocapitalize

Wyczekujemy.

 

Dziękuję, pozdrawiam!