Choć termin oficjalnego ukończenia prac nad nowym standardem języka znaczników HTML5 wyznaczony został na rok 2022, to już od wielu miesięcy możemy korzystać z dobrodziejstw jakie niesie ze sobą ta technologia oraz wiele specyfikacji z nią związanych (HTML5 APIs). Możemy, lecz czy naprawdę wykorzystujemy chociaż te elementy języka, które działają stabilnie i w większości przeglądarek?

Obszerne opracowanie HTML5 i jego nowych możliwości znajdziesz w kompleksowym kursie HTML5 na eduweb.pl. Zobaczysz, jak dostosować swoje projekty do nowych standardów oraz jak sworzyć stronę w HTML5 od podstaw.

Artykuł, który masz przed sobą, powstał z prostego powodu. Przeglądając setki stron internetowych, z których wiele to strony agencji reklamowych, web designerów, freelancerów, ale także inne strony sygnowane standardem HTML5, zauważyłem ciekawą zależność. Większość owych witryn łączy jedna rzecz: nie mają one nic wspólnego z HTML5 poza nowym, skróconym znacznikiem DOCTYPE. Nasuwa się zatem pytanie: „Czy użycie nowej deklaracji nagłówka DOCTYPE sprawia, że używamy języka HTML5?”. Odpowiedź nie jest jednoznaczna. Formalnie tak, praktycznie nie. Jeśli projektujesz lub wdrażasz strony internetowe, zapewne zaciekawi Cię dalsza część tego wpisu. Postaram się w maksymalnym uproszczeniu pokazać Ci, których elementów języka HTML5 można i powinno się bez obaw używać, nie od dziś, ale od dawna.

Nowa semantyka HTML5

Mowa tutaj o nowych, mających znaczenie dla maszyn (robotów indeksujących wyszukiwarek, czytników ekranu dla niewidomych) elementach takich jak header, section, footer, aside, nav, hgroup, figure i kilku innych. Tych możemy używać bezpiecznie w każdej przeglądarce. Jeżeli dana przeglądarka nie rozpozna takich elementów, to domyślnie potraktuje je jako elementy liniowe, zatem wszystko co musimy zrobić, aby te elementy były wyświetlane poprawnie, to nadać im style display: block;

Jak to działa? Tak naprawdę możemy w naszym kodzie HTML użyć dowolnego znacznika (jak w przypadku kodu XML). Podany poniżej znacznik, z nadanymi stylami jak wyżej, wyświetli się poprawnie w przeglądarce:

Z tego własnie powodu, przeglądarki, które nie obsługują nowych znaczników, poradzą sobie z ich wyświetleniem. Wyjątkiem jest tutaj jedynie Internet Explorer, który nie zadowoli się wyłącznie nadaniem display: block; w arkuszu stylów. Jednak i na to znalazło się rozwiązanie, otóż wystarczy, że w kodzie JavaScript utworzymy takie elementy (nie musimy ich nawet wstawiać na stronę):

Od tej pory możemy elementy te dowolnie dekorować w naszym arkuszu stylów CSS. Podane wyżej rozwiązanie działa, lecz i tutaj nie musimy nic robić sami. Aktywna społeczność większość rzeczy zdążyła już zrobić za nas, zatem nie krępuj się, by użyć poniższego rozwiązania na każdej swojej stronie:

Komentarz warunkowy, który widzisz, zadziała wyłącznie w przeglądarkach z rodziny Internet Explorer, w wersji starszej niż 9 (która wspiera nowe znaczniki). Wykona się wówczas skrypt z zewnętrznego serwera, który utworzy wszystkie znaczniki i zadba o to, by były poprawnie wyświetlone. Jeśli już wiesz, że bez obaw możesz używać nowych, semantycznych znaczników, zacznij pisanie kolejnej strony przy ich użyciu. Co jednak z innymi technologiami, które napędzają HTML5?

„Wiem, że coś istnieje w HTML5, ale nie wiem czy mogę tego bezpiecznie używać”

Na zdecydowaną większość tego typu pytań odpowiedź niesie serwis CanIuse.com, który w bardzo przejrzysty sposób podpowie nam, które przeglądarki obsługują, lub częściowo obsługują żądaną funkcjonalność, a które zdecydowanie mówią NIE nowym standardom. Na zrzucie ekranu poniżej widzisz jak przedstawia się wsparcie dla nowego elementu video, który pozwala nam dodawać wideo na naszą stronę, bez użycia zewnętrznych pluginów takich jak Flash:
CanIuse Video
Jak widzisz w tabeli, dla tagu video brakuje wsparcia między innymi w przeglądarce IE8, która na dzień dzisiejszy notuje 7.76% na polskim rynku, a więc jej użytkownicy nie powinni być traktowani „gorzej” od tych korzystających z nowych przeglądarek. Stajemy więc przed dylematem: „Użyć nowej technologii i pominąć zwolenników IE, czy z ich powodu nie korzystać z możliwości nowych przeglądarek?”. Na szczęście możemy „zadowolić” zarówno jednych, jak i drugich. Stwórzmy więc stronę, która użytkownikom nowych przeglądarek wyświetli wideo w natywnym formacie, a dla pozostałych użyje Flash‚a. Jak to zrobić? Tutaj kolejny link, który przyda Ci się bardzo często – html5please.com. Na stronie tej wpiszmy zatem „video”, i spójrzmy na wskazówkę na zielonym tle „use with polyfill”, co oznacza mniej więcej „użyj, ale zapewnij też wsparcie starszym przeglądarkom”. Aby dowiedzieć się, jaki jest rekomendowany sposób na wsparcie staruszków (bądźmy szczerzy, na wsparcie dla IE), spójrzmy nieco niżej na „Recommended polyfills:”. To właśnie w tym miejscu widoczny będzie link do narzędzi (zazwyczaj bibliotek JS), które pozwolą nam zapewnić poprawne działanie w każdej przeglądarce.
HTML5Please Video
Niemal każdą nową funkcjonalność HTML5 da się odtworzyć w starszych przeglądarkach z użyciem odpowiednich bibliotek JS, czasem z dodatkowym wsparciem technologii Flash (jak FlashCanvas dla elementu canvas). Dwie podane wyżej strony powinny w zupełności wystarczyć Ci w podjęciu decyzji, czy warto dany element implementować. Na pewno nie warto czekać, aż z rynku znikną przeglądarki nieobsługujące nowych standardów – nie pozwólmy im hamować rozwoju sieci!

Skoro wiesz już, że prawie każdej nowości HTML5, o której usłyszysz, możesz użyć na swojej stronie, sprawdźmy te najprzydatniejsze z nich.

Nowa era formularzy

HTML5 wprowadza ze sobą bardzo wiele nowych typów pól oraz atrybutów dla elementów formularzy. Przyjrzyjmy się najciekawszym z nich, z podziałem na te, których powinieneś używać i te, które nie są jeszcze w pełni wspierane i być może warto jeszcze jakiś czas poczekać.

Nowym, ciekawym typem pola jest między innymi pole email. Pole takie sugeruje, że jego wartość powinna być poprawnym adresem email. Spójrzmy jak je utworzyć:

W przeglądarkach, które obsługują nowe elementy formularzy pole takie będzie miało specjalne znaczenie. Kiedy użytkownik będzie próbował wysłać formularz, a pole to nie zostanie uzupełnione poprawnym adresem e-mail, przeglądarka powiadomi go o tym stosownym dymkiem i wstrzyma akcję wysyłania formularza. Pole to jest również ciekawe w przypadku urządzeń mobilnych, gdzie w momencie wprowadzania do niego danych na ekranie np. telefonu komórkowego, pojawi się zmodyfikowana klawiatura, zawierająca np. znak @. Oczywiście i tutaj nie zadziała to w przypadku każdego urządzenia, ale wówczas element o typie „email” zostanie potraktowany jako zwykły element z typem „text” i w niczym nie zaszkodzi to naszej aplikacji. A oto jak wygląda takie ostrzeżenie w przeglądarce Google Chrome:
Walidacja e-mail Google Chrome
Co jest jednak warte uwagi w przypadku walidacji takiego pola? Fakt, że większość przeglądarek implementuje zadziwiająco minimalistyczną wersję walidacji, co oznacza, że jeśli wpiszemy adres w formacie „asd@asd”, to zostanie on uznany za poprawny, a więc wygląda na to, że ciąg znaków przeszukiwany jest wyłącznie pod kątem znaku „małpki”. Z tego powodu zaleca się jednak wykonywanie walidacji z użyciem JavaScriptu lub po stronie serwera.

Innym ciekawym polem, jest pole typu „number„, które przyjmuje wartości liczbowe (choć oczywiście możemy go oszukać, wpisując ciąg znaków), a wygląda tak:
Pole typu number
Jak widzisz, pole to umożliwia dostosowanie liczby strzałkami, poprzez dodawanie i odejmowanie. Podobnie jak pole typu „email” zostanie ono wyświetlone jako pole typu „text” w przeglądarkach, które nie obsługują tego typu.

Kiedy chcemy upewnić się, że pola formularza zostały wypełnione przed wysłaniem, możemy nadać im atrybut required w ten sposób:

W tym przypadku, przeglądarka zadba o to, by wartość w polu była liczbą oraz nie była pusta.
By niepotrzebnie nie wydłużać tego wpisu, nie będę omawiał wszystkich nowych typów pól dostępnych w HTML5, ale warto abyś wiedział, że znajdują się wśród nich takie typy jak date, który umożliwia wybranie daty (tutaj wsparciem może być biblioteka jQuery UI, która oferuje taki widget), typ tel (dzięki któremu na urządzeniach mobilnych wyświetli się klawiatura numeryczna), url (dla wprowadzania adresów URL), range (dla przedziałów liczbowych) czy np. color (umożliwiający wybranie koloru). Oczywiście nie wszystkie te elementy działają poprawnie, ale zdecydowanie polecam użycie takich jak email, tel czy url. Mogą one ułatwić użytkownikowi interakcję ze stroną, ale na pewno nie utrudnią jej innym.

Wspomniałem wyżej o atrybucie required, który sprawia, że pole staje się wymaganym. Otóż, w większości przypadków atrybutu tego używa się w połączeniu z kolejnym, nazwanym pattern. Ten atrybut z kolei pozwala nam zdefiniować za pomocą wyrażeń regularnych wzór, z jakim zostanie porównana wartość wpisana przez użytkownika. Spójrz na przykład:

Wymuszamy więc na użytkowniku podanie słowa zaczynającego się od litery s, a następnie przynajmniej jednego dowolnego znaku. Jeśli podana wartość będzie inna, wyświetli się dymek z powiadomieniem. Metody walidacji są na pewno czymś ciekawym, jednak do mnie nie przemawiają z prostego powodu. Możemy je zbyt łatwo edytować. Wystarczy, że element taki zbadamy np. przez Firebug‚a czy Chrome Developer Tools i zmienimy wartość atrybutu pattern w ten sposób:
Edycja treści HTML w Chrome Developer Tools
W tym przypadku pozwalamy na wpisanie wartości zaczynających się od litery g, lecz mogliśmy nawet całkowicie usunąć atrybut required i wpisać dowolną wartość. Z tego powodu zalecana jest jednak dodatkowa walidacja, po stronie klienta i najlepiej kolejna po stronie serwera.

Innym, bardzo przydatnym atrybutem dostępnym w HTML5 jest atrybut placeholder. Pozwala nam on zdefiniować domyślny tekst, który wyświetlany będzie w polu dopóki użytkownik nie wprowadzi nowej wartości. Atrybut dodajemy w standardowy sposób:

a w przeglądarce wygląda to następująco:
HTML5 Placeholder
Ostatnim atrybutem wartym uwagi jest atrybut autofocus, który sprawi, że pole będzie domyślnie zaznaczone. Jest to przydatne np. w przypadku, gdy przekierujemy użytkownika na stronę wyszukiwarki i chcemy by kursor od razu znalazł się w polu do wpisywania słów kluczowych. Atrybut nie przyjmuje żadnych wartości, zatem dodajemy go tak samo, jak np. atrybut required.

Wykrywanie wsparcia dla danej funkcjonalności

Jeśli chcemy, aby nasz kod reagował idealnie na wszystkie zaistniałe okoliczności, powinniśmy zadbać również o detekcję specyficznych funkcjonalności. Biblioteki, które wspomniałem wyżej, czyli tzw. „polyfills” właśnie w taki sposób działają. Sprawdzają np. czy przeglądarka obsługuje element video i na tej podstawie decydują, czy wyświetlić natywny format, czy posłużyć się np. wtyczką Flash. Jeśli piszesz dla swoich witryn skrypty JavaScript, to warto wiedzieć, że można stosunkowo łatwo wykryć każdy obsługiwany element nowych technologii. Jak zatem sprawdzić czy przeglądarka obsługuje natywne video? Nic prostszego:

Tworzymy więc element video i sprawdzamy czy jest w nim dostępna jedna z jego metod canPlayType. Za pomocą notacji !! zmieniamy wartości prawdziwe lub fałszywe na prawdę lub fałsz. W przypadku przeglądarek nieobsługujących tego elementu, zostanie on utworzony, jednak nie będzie zawierał w sobie metody canPlayType, a więc otrzymamy wartość false.

Jak z kolei sprawdzić czy przeglądarka obsługuje np. typ „email” pola input? Spójrz:

Tworzymy element input i przypisujemy mu atrybut type = „email”. Następnie sprawdzamy, czy atrybut type jest równy „email”. Wiem, wydaje się to dziwne, lecz jeśli przeglądarka nie obsługuje takiego typu, to przypisze mu wartość „text” i return zwróci nam w efekcie porównania false.

Na temat detekcji różnych cech można by jeszcze wiele napisać, jednak w tym miejscu warto wspomnieć, że znów nie musimy tego robić sami. Z pomocą przychodzi nam biblioteka Modernizr, która zrobi wszystko za nas. Po załadowaniu skryptu w tagu head naszej strony, do elementu html dodane zostaną stosowne klasy, które pozwolą nam dokładnie ostylować elementy witryny. Wszystko to podejrzeć możemy z pomocą Firebuga, czy Chrome Developer Tools. Oprócz tego, z poziomu skryptów JS będziemy mieli dostęp do obiektu Modernizr, który przechowuje wszystkie potrzebne nam informacje. Jeśli chcemy wiedzieć, czy wspomniany wyżej element video działa w naszej przeglądarce, możemy użyć prostego zapisu:

Biblioteka ta pozwala na wykrycie ogromnej ilości funkcjonalności, w tym również wsparcia dla CSS3, dlatego miej ją na uwadze przy kolejnym projekcie!

Podsumowanie

HTML5 to wiele nowych możliwości, ja opisałem skrótowo tylko kilka z nich, lecz na temat każdej można by napisać obszerny artykuł. Nie miałem na celu nauczyć Cię, jak posługiwać się nowymi elementami, lecz pokazać, że są one dostępne i gotowe do użycia już od jakiegoś czasu, a z każdym dniem przeglądarki obsługują coraz więcej z nich, konkurując ze sobą. Jeśli jesteś ciekaw, jak zmieniało się wsparcie dla nowych technologii na przełomie ostatnich lat, zajrzyj na ciekawą stronę html5readiness.com, gdzie w interaktywny sposób wyświetlane są informacje dla poszczególnych lat oraz poziom wsparcia dla wymienionych przeglądarek. Wiesz już, że język HTML5 jest na tyle gotowy, by korzystać z niego już dziś. Szczególnie z semantycznych znaczników, nowych pól input, ale także z technologii takich jak Canvas czy LocalStorage. Jeśli jednak nie wiesz jak wykorzystywać wspomniane znaczniki zgodnie z ich przeznaczeniem, lub nurtują Cię inne kwestie, to polecam Ci gorąco kurs HTML5 dostępny na eduweb.pl, który z pewnością je rozwieje.

  • HTML5 osiągneło status Candidate Recommendation i już jest Working Draft HTML5.1. Czy trzeba teraz powiększyć logo HTML5? ;)

    Pozdrawiam

  • Według mnie stosowanie HTML 5 wymaga większej ilości pracy, bo trzeba bardziej skupić się na semantyce : ) O ile w przypadku większości stron pakowane są DIVy jeden na drugim, tak tutaj projektując musimy się zastanowić, czy ma to być article, section a może aside?:) Ktoś kto nie będzie miał podstawowej wiedzy w tym zakresie polegnie : ) Może spowoduje to, że w końcu z rynku znikną pseudo webdizajnerzy : ) Tym bardziej, że HTML 5 daje możliwości ciekawej współpracy z JS – a ten język już nie każdy zna : ) Idąc dalej – możliwe, że sieć stanie się bardziej przyjazna dla usera, a nie wygodniejsza tylko dla projektanta : )

  • @Paweł
    Zgadzam się całkowicie, ale jestem przekonany, że warto poświęcić czas na przyswojenie wiedzy, jak korzystać z semantycznych znaczników. Specyfikacja mówi jedno, ale tak czy siak, większość zależy od nas i to w jakim kierunku idzie sieć jest dyktowane głównie przez osoby tworzące strony, a nie przez niewielką grupę osób, która ma swoją wizję w W3C. Kiedy już wiemy jak odpowiednio używać nowych tagów, to praca idzie bardzo szybko.

    A nowe API dla DOM i innych technologii jest oczywiście krokiem milowym w rozwoju sieci, ale to jest kwestia oddzielna i nie związana z samą semantyką kodu.

    ps. a co do DIVów – one nie znikną, bo tam gdzie jest potrzeba grupowania elementów na potrzeby stylów czyli wyglądu strony, zawsze należy ich używać ;)

  • Brawo Piotrek :) Świetny artykuł :) Dużo z niego można się nauczyć…

  • nie jest poprawne w html5