Tworzenie stron WWW to nieustannie rozwijająca się branża. Z tego też powodu powstają coraz to nowsze artykuły opisujące coraz to nowsze techniki tworzenia stron. Takim artykułem próbuje też być
HTML5, czyli nowe możliwości tworzenia stron WWW.
- Zgrzyt następuje już w samym tytule artykułu. HTML5 to wcale nie takie nowe możliwości, zważając na fakt, że początki tego standardu sięgają roku 2004, a pierwsza, stabilna wersja to okolice roku 2010.
- W artykule jest dużo błędów ortograficznych, gramatycznych i interpunkcyjnych, przez co przy wielu fragmentach trzeba się zastanawiać, co autor miał na myśli.
-
Większość dzisiejszych stron – ich elementy graficzne są wyprodukowane w języku programowania – JavaScript.
Owszem, w JS istnieją możliwości generowania grafiki – wystarczy wspomnieć
canvas
i WebGL. Niemniej twierdzenie, że większość stron ma elementy graficzne tworzone dynamicznie przy pomocy JS, to jednak nieprawda. Wciąż najpopularniejszymi formatami są JPG czy PNG, które najczęściej są serwowane jako statyczne zasoby. Istnieje także format SVG, który może zawierać w sobie kod JS, ale działa on na tej samej zasadzie, co w kodzie HTML.Poza tym generowanie dynamicznie grafiki przy pomocy JS mimo wszystko jest mniej wydajne niż serwowanie statycznego obrazka i sprawdza się wyłącznie przy generowaniu wykresów czy przy grach przeglądarkowych.
-
JavaScript daje nam możliwości pełnej kontroli HTML DOM po jego załadowaniu jak i w trakcie ładowania.
Dość trudno mieć kontrolę nad DOM w trakcie jego ładowania z dość prozaicznej przyczyny: nie bardzo jest nad czym mieć kontrolę. Można jedynie modyfikować te węzły, które przeglądarka już wczytała.
-
HTML5 jest jakby stworzony pod JavaScript.
HTML5 daje dokładnie te same możliwości w zakresie interakcji z JS, co starsze wersje HTML. Jedynymi punktami stycznymi są DOM API oraz pozostałość po DOM0, jakim są atrybuty
[on…]
. Cała reszta, wrzucana do worka HTML5, to tak naprawdę całkowicie oddzielne APIs. -
Pisząc ostatnio backend dla jednego z klientów postanowiłem skupić się bardziej na wykorzystaniu wszystkich funkcji jakie daje nam HTML5.
Dość dziwne sformułowanie, zważając na fakt, że HTML5 jest odpowiedzialny za frontend, nie backend.
-
Ale skupmy się tutaj na JavaScript. Po pierwsze funkcja „contenteditable(true/false)”.
[contenteditable]
jest atrybutem HTML i własnością DOM, nie zaś funkcją. Posiada tak naprawdę trzy wartości:true
,false
oraz pustą wartość tekstową. Dodatkowo ten atrybut był po raz pierwszy użyty w IE 5, więc o lata wyprzedza standard HTML5. Zresztą wystarczy popatrzeć na daty powstania najpopularniejszych edytorów WYSIWYG na Sieci: CKEditor powstał w 2003 roku, a TinyMCE – w 2004. W ramach HTML5 próbowano po prostu ustandaryzować to, co już istniało, co jest bardzo nieudolną próbą, zważając na liczne różnice pomiędzy przeglądarkami. -
W przypadku gdy drzewo generowane jest na podstawie normalnego zastosowania PHP możemy użyć dodatkowo w tej komórce funkcji onBlur i zastosować własną funkcję np. save, czyli onBlur=’save();’. W funkcji save robimy odczyt zawartości komórki $(this).text(); i przekazujemy ją do zapisu metodą POST do bazy danych przez funkcję Ajax(). Czyli tak naprawdę redukujemy 70% kodu javascript dzięki użyciu HTML5 !
Totalne pomieszanie pojęć. Drzewko DOM nie jest generowane przez języki backendowe. Kod PHP może co najwyżej służyć do wygenerowania odpowiedniego kodu HTML – nic więcej. Dodatkowo
funkcja
nie istnieje. Ajax jest nazwą zbioru technologii służących do asynchronicznej komunikacji z serwerem. Możliwe, że chodziło oAjax()
jQuery.ajax
, na co wskazywałoby użycie$(this).text();
, które jest wykorzystaniem właśnie tej biblioteki, nie zaś JS. Dochodzi do tego polecenie atrybutu[onblur]
(warto zwrócić uwagę, że zapis[onBlur]
działa wyłącznie dlatego, że atrybuty w HTML są case-insensitive), co zaburza podział na warstwy aplikacji i sprawia problemy przy stosowaniu CSP. -
Wspomnę jeszcze dla programistów, którzy generują tabelę po przez zapytanie i wynik funkcji Ajax(), wtedy musimy zastosować funkcję onBlur w samym javascripcie, aby odnosił się do danego ID po załadowaniu i zmianie drzewa DOM, $(document)….
onblur
nie jest funkcją, jest własnością DOM. Dodatkowo należy zauważyć, że – w przeciwieństwie do HTML-a – w JS jedyną poprawną formą jest formaonblur
, nie zaśonBlur
. Nie jest też prawdą, że trzeba zastosować tę własność dla każdego generowanego pola. Można użyć albo przechwycenia zdarzeniablur
, albo zdarzeniafocusout
.Pomijam fakt, że, z powodu skrótów myślowych i interpunkcji, ten fragment jest niemal niezrozumiały.
-
Do wyżej wymienionego przykładu warto zastosować element biblioteki jQuery – jQuery colors. Daje ona możliwość animacji kolorami na drzewie DOM, np. mignięcie kolorem zielonym tła danej komórki. To sprawdza się po dodaniu jej do funkcji zapisu danych save(), tak aby użytkownik wiedział że wszystko poszło dobrze i dane zostały zapisane. Dlaczego tak? ponieważ contenteditable nie narzuca do drzewa tagu <input>, a więc użytkownik po niekąd nie widzi czy onBlur zadziałał, chociaż na upartego można dodać też funkcję onChange i zastosować jakiś CSS dla tej akcji.
To nie jest prawda. Elementy z
[contenteditable]
mają domyślnie nadane style zoutline
, przez co widać, kiedy są sfocusowane. Owszem, dodanie animacji i efektu polepszy UX, niemniej nie jest niezbędne. Dodatkowo warto zauważyć, że poinformowanie użytkownika o sukcesie wyłącznie kolorem jest złamaniem wytycznych WCAG.jQuery Color (nie zaś colors) z kolei nie jest elementem biblioteki jQuery, a pluginem. Niemniej obecnie przejścia pomiędzy kolorami można zrobić w samym CSS.
-
Walidacja w HTML5 jest tak prosta, że na pierwszy rzut oka to jej wcale nie widać w formularzu 🙂 Oczywiście jest, użyto dwie funkcje: data-rule=”” oraz data-msg=”” i to tyle 🙂
To totalnie nie ma nic wspólnego z walidacją formularzy w HTML5 i w dodatku nie działa. Ba, nawet wspomniany w artykule plugin jQuery Validation używa faktycznej walidacji w HTML5.
Natomiast w HTML5 wbudowane jest Constraint Validation API, które akurat jest najsłabszą częścią całego standardu.
-
Flash po prostu był ciężki, a html5 to całkowicie inna bajka, wystarczy dodać źródło i włączyć opcje playera lub dodatkowe cechy jakie ma posiadać i to wszystko.
Trudno, żeby język znaczników był cięższy od całej platformy programistyczno-designerskiej i jej środowiska uruchomieniowego.
-
HTML5 bardzo fajnie sprawdza się w pisaniu zaplecz, naprawdę polecam zagłębić się na inne ciekawe opcje jakei daje w połączeniu z JavaScriptem. Przede wszystkim pozycjonowanie stron internetowych z przejrzystym i lekkim kodem źródłowym to największa zaleta stosowania HTML5.
To jest totalna bzdura, która najprawdopodobniej wynika z całkowitego niezrozumienia, po co istnieje HTML. Nie, nie służy on do pozycjonowania stron, a do przekazywania znaczenia treści.
Wydawałoby się, że w roku 2018 nie ma już miejsca na szerzenie mitów i zabobonów o HTML5. A jednak…
Na początku myślałem iż uparłeś się na autora, ale wraz z kolejnymi fragmentami stwierdzam iż faktycznie agencja nie wie czym się zajmuje 😀
Zawsze wydawało mi się że HTML5 to taki worek (buzzword) stworzony przez marketingowców (a nie tylko standard), do którego wrzuca się wszystkie API jakie są dodawane do przeglądarek. Czy Intersection albo Mutation Observer to też HTML5?
Oczywiście, że nie. Intersection Observer to całkowicie odrębny standard. Mutation Observer z kolei to część specyfikacji DOM.
Czasy, gdy HTML5 był buzzwordem, IMO już dawno przeminęły i w końcu to pojęcie oznacza to, co ma oznaczać: standard HTML. Ostatni większy podryg to było słynne HTML Logo, które do worka HTML5 wrzucało nawet CSS3. Od tamtego jednak czasu sukcesywnie terminu HTML5 unikano i dzisiaj jako buzzword widzę go naprawdę rzadko i niemal nigdy w profesjonalnych, branżowych artykułach. No bo nie oszukujmy się: HTML5 nie jest już nowością, to i nie jest taki ciekawy.
” Nie, nie służy on do pozycjonowania stron, a do przekazywania znaczenia treści.” Tutaj absolutnie się z Tobą zgadzam. Nie wiem skąd to często spotykane przeświadczenie, że jakość kodu ma tak potężny związek z tzw. pozycjonowaniem… Wiem z własnego doświadczenia, że nawet strona z masakrycznym kodem może być wysoko w google jeśli zawiera dobre i unikalne treści. Dzisiaj w pozycjonowaniu liczy się treść, a wszystko pozostałe (czytaj „programistyczne”) to tylko wg mnie dodatki, które owszem pewnie w jakimś stopniu pomogą, ale ich wpływ liczyłbym w małym procencie w stosunku do treści. Obecnie warto też tworzyć strony RWD ponieważ google zauważam, że rozdziela chyba pozycjonowanie dla mobilek i PC, ale w dzisiejszych czasach rwd to już chyba standard.
A o tych nowościach to chyba troszkę jak z pisaniem, że nadal ES6 jest super extra nowością gdy już wyszły dwa kolejne standardy 🙂 (fakt, że wprowadzają znacznie mniej zmian ale liczy się sam fakt kolejnych edycji)
A propo html5. Comandeer chciałem się Ciebie o coś zapytać. Załóżmy, że trzeba stworzyć jakiś image slider, którego zdjęcie jak i reszta wygląda mniej więcej tak:
https://prntscr.com/ib1k7f
Wiadomo, że skoro slider to pakujemy to w article. Nagłówek w h2 w którym umieszczamy image slider, a jeśli strona jest w języku polskim to jak poprawnie się tłumaczy image slider, galeria zdjęć? Dobra, ukrywamy nagłówek za pomocą visuallyhidden bo przeważnie projekt graficzny nie ma na niego miejsca, i teraz co w środku? Wpakowałbyś ten tekst w section, później h3 i pod spodem w tagu p resztę treści? Czy wpakowałbyś to w figure, cały tekst w figcaption a to co wygląda jak nagłówek wpakować w span i odróżnić od reszty?
Jeśli chodzi o mnie to ja wpakowałbym to w opcję z figure. Tak naprawdę nie ma większego sensu dla zdjęcia tworzyć nowy nagłówek. Z czytnikami ekranowymi nie ma problemu bo czy figure czy section i nagłówek to obydwa zostaną przeczytane, ale rozchodzi się poprawną semantykę. Z drugiej strony opcja z section i nagłówkiem też nie jest tutaj jakimś wielkim grzechem. Co o tym myślisz?
Zapewne się nie zdziwisz, że powiem: „to zależy” 😉 Jeśli slider da się podzielić na niezależne części i każdą z tych części (obrazek + opis) przenieść na osobną podstronę, wówczas
figure
sprawdzi się doskonale. Jeśli jednak slidera na takie części podzielić się nie da, wówczas pomyślałbym nad sekcjami lub najzwyczajniejszą w świecie listą zdjęć.Zastanowiłbym się jednak, czy podział na sekcje nie wskazywałby, że do slidera wepchaliśmy za dużo. Wg mnie powinien on być raczej dodatkiem do treści, zajawką, nie zaś – faktycznym nośnikiem treści.
Ważna jest także sprawa różnicy pomiędzy
figure
a sekcjami (czyli elementami z nagłówkami) dla czytnika ekranowego. Te pierwsze nie tworzą punktu nawigacyjnego, podczas gdy w przypadku sekcji stanowią je nagłówki.No i ostatnia kwestia: nagłówek dla całego slidera. Zastanowiłbym się, czy „Galeria zdjęć” to odpowiedni tytuł? W tym wypadku wskazywałby na to, że wewnątrz slidera mamy dość monolityczną zawartość (zbiór zdjęć). Jeśli np. byłby to przegląd świadczonych usług, wówczas dałbym odpowiedni tytuł (np. „Przegląd usług” właśnie).
Comandeer przepraszam, że odgrzewam ten temat, ale o jedną rzecz jeszcze się chcę Ciebie zapytać odnośnie tego image-slidera, bo mam zapisaną Twoją powyższą odpowiedź, ale ja oczywiście jak czegoś nie mam czarno na białym to do końca nie wiem co zrobić i potem mi to siedzi w głowie. Pytanie dalej dotyczy tego samego slidera, którego przykład znajduje się wyżej lub pod tym linkiem https://prnt.sc/ib1k7f Zapytałem się Ciebie wyżej tak:
„Wiadomo, że skoro slider to pakujemy to w article. Nagłówek w h2 w którym umieszczamy image slider, a jeśli strona jest w języku polskim to jak poprawnie się tłumaczy image slider, galeria zdjęć? Dobra, ukrywamy nagłówek za pomocą visuallyhidden bo przeważnie projekt graficzny nie ma na niego miejsca, i teraz co w środku? Wpakowałbyś ten tekst w section, później h3 i pod spodem w tagu p resztę treści? Czy wpakowałbyś to w figure, cały tekst w figcaption a to co wygląda jak nagłówek wpakować w span i odróżnić od reszty?”
a Ty odpisałeś:
„Zapewne się nie zdziwisz, że powiem: „to zależy” 😉 Jeśli slider da się podzielić na niezależne części i każdą z tych części (obrazek + opis) przenieść na osobną podstronę, wówczas figure sprawdzi się doskonale. Jeśli jednak slidera na takie części podzielić się nie da, wówczas pomyślałbym nad sekcjami lub najzwyczajniejszą w świecie listą zdjęć.”
i chciałem się Ciebie zapytać bo odpisałeś, że „wówczas pomyślałbym nad sekcjami lub najzwyczajniejszą w świecie listą zdjęć”jeśli byłyby to sekcje to wiadomo, że wypadałoby tam wsadzić nagłówki h3, ale jeśli zrobić z tego listę zdjęć to tak samo dałbyś tam nagłówki? Czyli wyglądałoby to mnie więcej tak:
ul
li
h3 Jakis tytuł /h3
p Jakis tekst /p
/li
/ul
czy inaczej?
To zależy… 😉 Ale tak, najprawdopodobniej po prostu wsadziłbym nagłówki w elementy listy. Nie ma żadnego przeciwskazania.
Dziękiii bardzo.
Dzięki. Rozjaśniło mi to ten problem.
Fakt jest taki, że sporo osób trzymało się za 4 wersję i nie chciało iść w nogę z czasem../
Comandeer chciałem się jeszcze Ciebie zapytać o alt w takich zdjęciach w sliderze? Chodzi mi o taki typowy slider gdzie, załóżmy, że u góry jest slider, który ma kilka zdjęć z wakacji w Grecji a niżej nagłówek: „Wakacje w Grecji”, a poniżejkrótki opis w paragrafie: „I tak właśnie w sierpniu tego roku, wybraliśmy się na piękne wakacje do Grecji by pozwiedzać trochę to piękne starożytne państwo…”. Alt w takich zdjęciach zostawiłbyś pusty czy nie? Bo ja bym zostawił pusty. Nie są one powiązane z treścią. Sam slider i te zdjęcia to taki raczej dodatek i bajer niż jakiś artykuł w którym zdjęcia mają jakieś znaczenie.
A ja bym mimo wszystko dał jakieś opisy. Sam slider zwykle jest odpowiednio oznaczony dla czytników ekranowych, więc puste [alt] w środku mogą być mocno mylące.