Kurs Wprowadzenie do HTML od Kodilli

Dzisiaj na tapet trafia Kodilla! Nie, nie zapisałem się na bootcamp. Odkryłem, że mają kilka kursów wprowadzających – do HTML-a, CSS-a i JavaScriptu. Dzisiaj przyjrzymy się pierwszemu z nich, kursowi HTML.

Kurs HTML składa się z lekcji podzielonych na 10 segmentów.

Pierwsza lekcja zawiera prezentację opisującą pokrótce, czym jest HTML. I osobiście mam z nią pewien problem terminologiczny: kilkukrotnie pada tam stwierdzenie, że znacznik jest podstawowym elementem HTML-a. I tak, można tak powiedzieć, ale w kontekście HTML-a element ma ściśle określone znaczenie. W skrócie można powiedzieć, że znaczniki określają początek i koniec elementu HTML, natomiast sam element HTML to wszystko od znacznika początkowego do znacznika końcowego. Zresztą samo pojęcie „elementu” jest definiowane przy użyciu konceptów z DOM.

Po prezentacji (bardzo krótkiej, swoją drogą; wyjaśniła jedynie, jak pisać znaczniki) pojawiają się ćwiczenia praktyczne. Bardzo dziwnie wygląda, gdy instrukcje do ćwiczenia są po polsku, ale już tekst na przykładowej stronie, którą mamy zmienić – po angielsku. Niemniej uważam, że o wiele większym problemem jest fakt, że kurs miesza pojęcia struktury i prezentacji. Pada m.in. twierdzenie, że HTML pozwala zmieniać strukturę lub wygląd treści na stronie. To nie jest prawda, HTML nie jest w stanie zmienić wyglądu treści. Za domyślny wygląd poszczególnych elementów HTML odpowiadają domyślne style przeglądarki. To one odpowiadają m.in. za to, że treść w elemencie b jest pogrubiona. Przy okazji warto zauważyć, że nazwa elementu b nie oznacza już bold (ang. pogrubiony). Takie znaczenie ten element miał w czasach HTML 2.0, ale współcześnie można co najwyżej mówić o pochodzeniu nazwy elementu. Zwłaszcza, że specyfikacja zawiera adnotację, że treść w tym elemencie nie musi być pogrubiona:

Style sheets can be used to format b elements, just like any other element can be restyled. Thus, it is not the case that content in b elements will necessarily be boldened.

[Arkusze stylów mogą zostać użyte do formatowania elementów b, które, podobnie jak wszystkie inne elementy, mogą zostać przestylowane. Dlatego też treść w elementach b nie musi być pogrubiona.]

W jaki sposób zatem powinno być to ujęte? Zacznijmy od tego, że zacząłbym od innego elementu – strong. Jego znaczenie jest o wiele łatwiejsze do wyjaśnienia (oznacza ważniejszy fragment tekstu) i nie ma nawet za bardzo możliwości zastanawiać się nad pochodzeniem jego nazwy. Wystarczy więc zdanie typu Możesz użyć elementu strong, żeby pokazać, który fragment tekstu jest najważniejszy. Do tego drugie zdanie, które tłumaczy, że pogrubienie jest tylko domyślnym stylem, który można bez większych przeszkód zmienić. I tyle. Osobiście uważam wręcz, że brak rozdziału między semantyką a domyślnym stylowaniem przy omawianiu HTML-a jest szkodliwy. Przykłady tego zresztą wielokrotnie były już pokazywane na WebKrytyku. Istnieje naprawdę niezliczona liczba stron, na których elementy HTML używane są w całkowitym oderwaniu od ich znaczenia, tylko dlatego, że wyglądają odpowiednio. Jednym z chyba najlepszych przykładów jest stosowanie fieldset + legend do zrobienia ładnej ramki.

I w tym miejscu Kodilla poprosiła mnie o założenie konta, inaczej nie otrzymam dostępu do dalszej części kursu. No ok, jedno konto więcej mi nie zaszkodzi… Problem w tym, że przy rejestracji wymuszana jest zgoda marketingowa, a to nie jest zbyt fajne. Ale dobrze, niech stracę.

W dalszej części kursu HTML poznajemy zagnieżdżanie elementów oraz element p. I znów jest „rozwinięta” jego nazwa. Co prawda w tym wypadku rozwinięcie pasuje, bo faktycznie akapit po angielsku to paragraph, ale te nazwy to naprawdę wyłącznie zaszłości historyczne. Osobiście bym takie informacje całkowicie pomijał albo zrobił osobną sekcję dla ciekawskich. Pojawia się także wskazówka, że znaczniki należy pisać małymi literami, nie jest jednak wyjaśnione dlaczego. A rada ta nie ma tak naprawdę praktycznego uzasadnienia, bo specyfikacja wprost mówi, że nazwy znaczników można zapisywać zarówno małymi, jak i dużymi literami. Kiedyś taka rada miała uzasadnienie, bo obok HTML-a istniał XHTML, który wymagał pisania małymi literami. Problem w tym, że nie dość, że niemal nikt nie używał prawdziwego XHTML-a, to sam termin został usunięty ze specyfikacji. A w świecie post-XHTML-owym wielkość liter w znacznikach nie ma większego znaczenia, byleby było spójnie. No chyba że się używa HTML-a w trybie XML… ale osobiście nie spotkałem dotąd takich masochistów.

Ogólnie pierwszy segment tego kursu prezentuje kilka elementów, które omawia przede wszystkim jako metody na wprowadzenie określonego stylowania. Oprócz b pojawia się też i (jako kursywa) oraz nagłówki, między którymi różnice zostały sprowadzone do rozmiaru. I choć faktycznie segment ten pozwala zrozumieć podstawy składni HTML, to jednak wprowadza także zamieszanie co do tego, czym faktycznie zajmuje się HTML.

Kolejny segment zaczyna się od omówienia struktury dokumentu HTML i… tradycyjnie zawiera błędne informacje o DOCTYPE. Ani to nie jest znacznik, ani też nie określa, że nasz dokument jest w HTML5. To preambuła dokumentu HTML i jedyne, co robi, to wymusza tryb renderowania zgodny ze standardami. Sama specyfikacja wprost zaznacza, że DOCTYPE istnieje wyłącznie z powodu kompatybilności wstecznej. Jak dotąd chyba nie spotkałem kursu, który by poprawnie określił przeznaczenie tej preambuły. Co jest dość zadziwiające, bo weryfikacja tego zajmuje kilkanaście sekund i sprowadza się do sprawdzenia tego w specyfikacji, względnie MDN, które również zawiera poprawne informacje.

Przy opisie struktury strony brakuje za to informacji o atrybucie html[lang], służącym do określenia języka strony. Jest to istotne zwłaszcza dla użytkowników czytników ekranowych w celu upewnienia się, że czytnik przeczyta treść przy użyciu poprawnej wymowy.

Co więcej, skrypt sprawdzający ćwiczenia niepoprawnie uznaje, że preambuła w całości napisana dużymi literami jest niepoprawna, wymuszając użycie formy <!DOCTYPE html>. Stoi to w sprzeczności ze specyfikacją HTML, która stwierdza, że w DOCTYPE można używać dowolnej wielkości liter. Podobnie rzecz się ma z wymaganiem przez skrypt znaczników html, head i body jako niezbędnych elementów struktury strony HTML. To nie jest prawda, bo specyfikacja zezwala na pomijanie tych znaczników. Jedyny problem z tym związany, a na który wskazuje walidator, to ominięcie atrybutu html[lang]. Oczywiście sam jestem zwolennikiem ich używania, bo sprawiają, że kod jest czytelniejszy, niemniej myślę, że warto to ująć właśnie w taki sposób w kursie, I znów: przydałaby się sekcja dla ciekawskich, w której byłoby napisane, że można te znaczniki pomijać i jakie są tego konsekwencje.

Zresztą widać, że skrypt ten powstał dla angielskiej wersji kursu i nie został specjalnie przystosowany do polskiej. W jednym z ćwiczeń jest choćby wymagane, by jeden z nagłówków miał treść About me. Przydałoby się to jednak spolszczyć. Zwłaszcza, że późniejsze ćwiczenia wymagają posługiwania się choćby angielskimi nazwami miesięcy czy kolorów.

Jeden z segmentów poświęcony jest tworzeniu strony o sobie. I pojawia się tam zadanie, by stworzyć listę swoich umiejętności przy wykorzystaniu… myślników i elementu br. To tylko potwierdza moją wcześniejszą obserwację, że kurs ten niedostatecznie duży nacisk kładzie na to, że HTML jest od semantyki, nie zaś – wyglądu. Wprowadzenie na potrzeby tego ćwiczenia elementu ul byłoby o wiele lepszym rozwiązaniem. Co prawda informacja o tym, że takie listy istnieją, jest od razu w kolejnej lekcji, ale… po co w takim razie pokazywać o wiele gorszy sposób tylko po to, by po chwili wprowadzić poprawny?

W lekcji o tabelach jest wprowadzony podział na nagłówek tabeli oraz jej ciało. Nie ma jednak za bardzo informacji o tym, jakie korzyści daje tak naprawdę dodanie nagłówka do tabeli. Stwierdzenie, że zwiększają przejrzystość i czytelność, jest mocno ogólne i nie tłumaczy za dużo. Jak dla mnie o wiele lepiej brzmiałoby stwierdzenie, że dzięki nagłówkom można nadać nazwy kolumnom i wierszom w tabeli. Można by też wspomnieć o tym, że część czytników ekranowych odczytuje te informacje. Ogólnie kwestie semantyki i dostępności zdają się w tym kursie być potraktowane mocno powierzchownie i o wiele ważniejszy jest wizualny efekt użycia kodu HTML.

W lekcji poświęconej hiperłączom jest wzmianka o tym, że W3C ustala standardy m.in. dla HTML-a. Otóż już nie. HTML jest standardem rozwijanym przez WHATWG a W3C jedynie współuczestniczy w tych pracach. Niemniej trzeba przyznać, że zależności pomiędzy poszczególnymi organizacjami standaryzacyjnymi i obszary, jakimi się zajmują, to jeden wielki bajzel.

W segmencie poświęconym linkom mieszane są też koncepty URL-ów absolutnych (bezwzględnych) i relatywnych (względnych) oraz ścieżek absolutnych i relatywnych. To są dwie całkowicie różne rzeczy. Absolutny URL to w uproszczeniu URL zaczynający się od http lub https (tzw. schemy). Z kolei relatywny URL to URL bez schemy. Natomiast obok tego istnieją URL-e zawierające ścieżki absolutne i relatywne. URL-e ze ścieżkami absolutnymi to URL-e, w których adres zaczyna się od /. Z kolei URL-e ze ścieżkami relatywnymi to adresy zawierające ścieżkę do pliku, która nie zaczyna się od /. Są to podobne zasady jak te obowiązujące w systemach uniksowych: / oznacza główny katalog i jeśli ścieżka się zaczyna od tego znaku, to znaczy, że jest absolutna. Natomiast ścieżka niezaczynająca się od / to ścieżka relatywna. Podstawową różnicą między tymi ścieżkami jest sposób ich rozwiązywania. Absolutna ścieżka zawsze będzie wskazywać na ten sam plik (bo mamy dokładny jego adres, od samego początku systemu plików, aż do samego pliku). Natomiast ścieżka relatywna będzie rozwiązywana względem miejsca, w którym się aktualnie znajdujemy (bo zawiera tylko część adresu pliku, więc reszta jest „zgadywana” na podstawie naszej obecnej pozycji). Taka sama zasada obowiązuje w URL-ach: absolutny URL zawiera pełny adres (schemę, domenę, ścieżkę do pliku itd.), natomiast relatywny – tylko fragment adresu, który ma sens jedynie po odniesieniu go do aktualnego adresu strony.

W kursie jest też pewien problem nomenklaturowy. Elementy takie jak br czy img są nazywane elementami samozamykająćymi się. Problem pojawia się już w nazwie, ponieważ powinno się mówić raczej o elementach posiadających samozamykające się znaczniki. Niemniej takie elementy nie istnieją w HTML-u. Istnieją jedynie tzw. puste elementy (void elements), które po prostu nie mają znacznika końcowego. Z kolei samozamykające się znaczniki istnieją w XML-u i praktycznie każdy element może takie mieć. Co oznacza, że samozamykające się znaczniki mogą mieć tzw. obce elementy (foreign elements), pochodzące z takich języków jak SVG czy MathML. To, że w XML-u istnieją samozamykające się znaczniki, wynika z wymogu składniowego w tym języku, by każdy element miał znacznik końcowy. W przypadku elementów pozbawionych treści, oba znaczniki można złączyć w jeden, tworząc tym samym samozamykający się znacznik.

W segmencie poświęconym obrazkom bardzo mało uwagi poświęca się znaczeniu atrybutu [alt]. Jest on sprowadzony do wyświetlania tekstu alternatywnego, gdy obrazek nie może zostać wczytany. To, według mnie, wręcz szkodliwe spłycenie tematu, bo atrybut ten służy przede wszystkim do dostarczania treści alternatywnej dla osób, które obrazka nie mogą zobaczyć z różnych przyczyn, np. są niewidome. Specyfikacja HTML ma wielki rozdział odnośnie odpowiedniego doboru atrybutu [alt] i warto byłoby o tym wspomnieć już na samym początku poznawania tego atrybutu.

W tym samym segmencie pojawia się też lekcja poświęcona atrybutowi [align], który obecnie jest uznany za przestarzały i zalecane jest używanie CSS-a zamiast niego. Ten atrybut powinien być, moim zdaniem, pominięty, bo o wiele większe możliwości daje CSS. No i dodatkowo po raz kolejny wprowadzane jest mylne wrażenie, że HTML służy także do zmiany wyglądu treści.

Wrażenie to jest wzmacniane także przez fakt, że kolejny segment jest poświęcony atrybutowi [style], przy pomocy którego wprowadza się do HTML-a style CSS. Problem w tym, że to kurs HTML i nie ma za bardzo potrzeby, aby mieszać do niego CSS – i to w dodatku w sposób, który zaciera wyraźną granicę między HTML-em a CSS-em.

Kolejnym problemem terminologicznym w kursie jest utożsamianie paddingu (czyli marginesu wewnętrznego) z wcięciami. Wcięcie to jednak coś zupełnie innego i jest osobna reguła CSS od niego, text-indent.

Pojawia się także opis podziału elementów HTML na blokowe i liniowe, który jest podziałem anachronicznym, z czasów HTML 4.01. W obecnej specyfikacji HTML podział elementów jest zdecydowanie dokładniejszy i oparty na zawartości poszczególnych elementów. Podział na elementy blokowe i liniowe został sprowadzony do nadania domyślnych stylów poszczególnym elementom.

Podsumowanie

W gruncie rzeczy kurs ten wygląda bardzo podobnie do tych oferowanych przez Codengę. Niemniej jest od nich o wiele bardziej rozbudowany, choć równocześnie muska jedynie powierzchnię tematu. Największym zarzutem jest zdecydowanie sprowadzenie HTML-a do roli formatowania tekstu, co skutkować może brakiem świadomości sporej liczby problemów związanych z inkluzywnością i dostępnością. Kuleje też nomenklatura. No i wreszcie ten nieszczęsny DOCTYPE, który powraca jak bumerang przy okazji praktycznie każdego kursu…

Sama forma ćwiczeń jest całkiem dobrym pomysłem. Problem polega na tym, że – podobnie jak u Codengi – warstwa teoretyczna mocno niedomaga.