Wideokurs EasyCode

Dzisiaj na tapet trafia kurs EasyCode.

Wcześniej ten kurs znajdował się na stronie FrontDevHero.pl, jednak jakiś czas temu przeniósł się na nową domenę.

Dla porządku informuję też, że nie wykupiłem kursu. Do napisania tej recenzji nakłoniła mnie udostępniona za darmo wersja demo kursu. W tym artykule skupiam się wyłącznie na treści kursu. Sama strona kursu zasługuje na osobną recenzję.

Wprowadzenie

UWAGA! Dźwięk w tym filmiku jest niesamowicie głośny. Na tyle głośny, że wręcz nieprzyjemny.

• Mimo najszczerszych chęci, nie jestem w stanie dokładnie powiedzieć, o czym jest ten filmik… To niby wprowadzenie do kursu HTML, ale porusza kilka tematów i żaden nie jest dokładnie wyjaśniony. Ba, to wprowadzenie do kursu HTML, a nie ma tutaj nawet słowa o samej składni HTML-a. Zamiast tego omawiane są niektóre atrybuty.

• Na początku filmiku autor proponuje zainstalowanie IDE. Problem w tym, że żaden z wymienionych programów (oprócz Reactide) nie jest IDE. To zwykłe edytory tekstowe. W przypadku Sublime Text widać to już w samej jego nazwie.

  IDE to bardziej skomplikowany program niż edytor tekstowy, zawierający sporo wbudowanych funkcji ułatwiających development. Wymienione edytory można upodobnić do IDE, ale wymaga to instalacji – często całkiem pokaźnej liczby – pluginów. W tym filmie obydwa te pojęcia są ze sobą błędnie utożsamiane.

• Omówienie DOM jest błędne. To nie jest drzewo HTML-a, tylko drzewo konstruowane przez przeglądarkę na podstawie sparsowanego kodu HTML. DOM wygląda inaczej niż kod HTML i nie można ich utożsamiać. Przykład:

  <table>
  	<tr>
  		<td>Cell</td>
  	</tr>
  </table>

  Powyższy kod HTML po sparsowaniu przez przeglądarkę wygeneruje drzewko DOM tożsame dla tego wygenerowanego dla kodu poniżej:

  <table>
  	<tbody>
  		<tr>
  			<td>Cell</td>
  		</tr>
  	</tbody>
  </table>

  Wynika to bezpośrednio z zasad parsowania kodu HTML.

  Pomijam fakt, że wprowadzenie DOM bez wyjaśnienia zagnieżdżania w sobie znaczników HTML nie ma sensu.

• Większa część tego filmiku to omówienie atrybutu [target]. Jednakże większość informacji o nim jest błędna.

  Zacznijmy od mieszania pojęć karta, witryna i okno. Te występują przy opisie atrybutu [target] i jego wartości. Niemniej błędnie utożsamia się tutaj witrynę z kartą. Witryna to strona internetowa. WebKrytyk jest witryną, Onet jest witryną itd. Natomiast karta to element interfejsu przeglądarki – miejsce, w którym wyświetlane są witryny. W dawnych czasach przeglądarki nie miały kart i ich funkcje pełniły osobne okna. Obecnie wszystkie linki otwierające się w nowych oknach tak naprawdę otwierają się w nowych kartach.

  Pomieszano tutaj zatem pojęcia z dwóch różnych porządków i dodatkowo niepotrzebnie wprowadzono dwa terminy na opis tego samego elementu interfejsu przeglądarki.

  W filmiku padają także inne informacje o [target], np.:

  […] jeżeli chodzi o standardy, to self jest używany, jeśli chcemy stargetować link do nowego okna. Wtedy używamy wyłącznie blanka.

  Ten fragment nie ma sensu, bo _self to wartość atrybutu [target] wymuszająca otwarcie linka w tej samej karcie i nie da się jej połączyć z wartością _blank, wymuszającą otwarcie w nowej karcie.

  Pada też sugestia, że standard zezwala wyłącznie na wartości _blank i _self, ale to nieprawda:

  The target attribute, if present, must be a valid browsing context name or keyword.

  [Atrybut [target], jeśli jest obecny, musi zawierać poprawną nazwę kontekstu przeglądania lub słowo kluczowe.]

  Kontekst przeglądania to w uproszczeniu każde okno/karta przeglądarki oraz ramki, w których jest wczytana jakaś strona WWW. Z kolei słowa kluczowe to _top, _parent, _blank i _self.

• Nieprawdziwą jest także sugestia, że obecnie nie uzywa się iframe. Ramek tych używa się bardzo często, np. w celu osadzenia widgetów społecznościowych. Nie używa się ramek zbudowanych przy pomocy elementów frame.

• Proponowana oglądającemu lista elementów na W3Schools jest niekompletna i błędna.

• Określenie nagłówków jako pogrubionego tekstu podpisanego jako tytuł sugeruje, że to wyłącznie formatowanie. Niemniej to nieprawda, bo nagłówki stanowią podstawowy sposób nawigacji dla użytkowników czytników ekranowych. Dodatkowo tworzą szkielet struktury strony.

  Jak dotąd, niestety, nie spotkałem kursu w Polsce, który by tłumaczył podział strony na warstwy treści/struktury, prezentacji i zachowania. Niemniej wyjaśnienie tego podziału pozwoliłoby na możliwość lepszego tłumaczenia poszczególnych elementów HTML-a. Wówczas bowiem można byłoby omówić nagłówek w oderwaniu od jego wyglądu.

• Nieprawdą jest, że Google woli, gdy na stronie jest jedno h1. To ma znaczenie przede wszystkim z punktu widzenia dostępności. Z racji tego, że użytkownicy czytników ekranowych używają najczęściej nagłówków do nawigacji, istotne jest, by był tylko jeden główny nagłówek strony. To ma także sens z perspektywy semantyki: dana rzecz powinna mieć tylko jeden tytuł.

• „Skrótowe” nazwy tagów nie są skrótowe. Być może kiedyś, faktycznie, rozwijanie tych nazw miało sens. Ale w obecnym HTML-u większość elementów zmieniło swoje znaczenie i np. hr nie jest już dłużej horizontal line, a separatorem tematycznym. W tym momencie „pełna” nazwa jest myląca. Lepiej zostawić takie zaszłości historyczne w przeszłości.

• Nie istnieje też już podział elementów na liniowe i blokowe. To podział z HTML 4. W HTML LS podział jest dokładniejszy. Można co najwyżej mówić o domyślnym sposobie wyświetlania.

• Dobór elementów omawianych w tym odcinku jest dość dziwny. Czemu omawia się akurat mark i del, które są mocno specyficznymi elementami? A skoro już omawiamy del, to czemu już nie ins?

• Opisy poszczególnych elementów są błędne. Element abbr nie służy do opisywania danego tekstu, ale do oznaczania skrótowców. Z kolei em nie służy do pochylania tekstu, ale do wprowadzania zmian akcentowania.

• Po każdej lekcji jest test. Niemniej pytania w teście po tym filmie mają błędne odpowiedzi lub nie przystają do zawartości filmiku.

  Wśród pytań jest pytanie o DOCTYPE, który nie był w filmie ani razu wspomniany. Jest też pytanie o abbr:

  Jaki atrybut należy dodać do abbr aby wyświetlał się prawidłowo?

  Poprawna odpowiedź nie istnieje, ponieważ nie trzeba dodawać żadnego atrybutu do abbr. Ten element zawsze wyświetla się prawidłowo, nie potrzebuje atrybutu [title], wbrew temu, co sugeruje pytanie. Standard dopuszcza możliwość samego oznaczenia skrótowca bez podania jego rozwiniecia:

  The abbr element represents an abbreviation or acronym, optionally with its expansion.

  [Element abbr reprezentuje skrótowiec, opcjonalnie wraz ze swoim rozwinięciem.]

  Również pytanie o head może oglądającemu nastręczyć pewnych trudności, bo rola tego elementu nie została opisana.

  Kolejnym błędnym pytaniem jest to o atrybut [target]:

  Których wartości aktualnie używamy przy określeniu targetu naszego linku?

  Poprawne są wszystkie podane odpowiedzi, zgodnie z wymienionymi przeze mnie dopuszczalnymi wartościami tego atrybutu.

  Z kolei na pytanie Który z poniższych układów nie wymaga modyfikacji? nie da się odpowiedzieć z powodu braku omówienia składni HTML-a i zasad zagnieżdżania elementów.

Bibliografia elementów

• Informacja o tym, że znacznik html jest niezbędny do funkcjonowania strony, jest nieprawdziwa. Ten znacznik jest opcjonalny:

  Tag omission in text/html:

  An html element’s start tag can be omitted if the first thing inside the html element is not a comment.

  An html element’s end tag can be omitted if the html element is not immediately followed by a comment.

  [Pominięcie tagu w text/html:

  Tag otwierający element html może zostać pominięty, jeśli pierwszą rzeczą wewnątrz elementu html nie jest komentarz.

  Tag zamykający element html może zostać pominięty, jeśli bezpośrednio po elemencie html nie występuje komentarz.]

  To oznacza, że poniższy kod jest całkowicie poprawnym dokumentem HTML:

  <!DOCTYPE html>
  <title>Tytuł strony</title>
  <p>Hello, world!</p>

  Niemniej znacznik html jest zalecany i walidator pokazuje odpowiednią adnotację. Przypomina w niej, że dla zwiększenia dostępności należy określić język dokumentu przy pomocy atrybutu html[lang].

  To jednak oznacza, że zalecany jest tylko znacznik otwierający, a zatem:

  <!DOCTYPE html>
  <html lang="pl">
  	<title>Tytuł strony</title>
  	<p>Hello, world!</p>

  Powyższy kod również jest całkowicie poprawnym HTML-em.

• Informacje o elemencie base są nieprawdziwe. Nie jest on bowiem potrzebny, żeby móc wykorzystywać relatywne URL-e. Przeglądarka ma odpowiednie informacje, żeby takie linki obsłużyć. W końcu każda strona ma swój URL i na podstawie niego tworzone są linki. Tak naprawdę wszystkie linki na stronie, jeśli nie zaczynają się od schemy (często, błędnie, nazywanej protokołem), są traktowane jako relatywne.

  Nieprawdą jest też, że base działa tylko dla linków z / na początku. Działa dla wszystkich linków, które nie mają schemy (czyli dla tych, których atrybut [href] zawiera relatywny URL).

• Wszystko, co zostało powiedziane o hgroup, jest niezaimplementowane w przeglądarkach. Co więcej, wszystko wskazuje na to, że hgroup zostanie wkrótce usunięte ze standardu.

  Niemniej nawet przy założeniu, że hgroup został zaimplementowany, to informacje podane w tym filmie są nieprawdziwe. Element ten bowiem nie służy do informowania, że w danym miejscu jest więcej niż jeden nagłówek. Służy do oznaczania nagłówków z podtytułami. Jak jednak zauważyłem, jest to niezaimplementowane i nie powinno się z tego korzystać!

  Sam przykład wykorzystania hgroup również jest niefortunny, ponieważ autor nie powinien być oznaczany przy pomocy nagłówka.

• Element article nie zastępuje divów! Podczas gdy article reprezentuje samodzielną i niezależną część strony, div służy wyłącznie do grupowania elementów. Zasada kciuka brzmi: jeśli jesteś w stanie wymyślić sensowny nagłówek, to prawdopodobnie jest to article (lub inny element sekcjonujący).

  Również umieszczanie section wewnątrz article ma sens tylko wówczas, gdy w artykule są śródtytuły albo można wydzielić nazwany region.

  Tak samo umieszczenie nav wewnątrz article jest niepoprawne. Co prawda na poziomie składni jest to jak najbardziej dozwolone, ale to nie będzie nawigacja artykułu! Element nav reprezentuje elementy nawigacyjne dla całej strony.

• Element footer nie musi być na samym dole strony i sama specyfikacja to zaznacza:

  Footers don’t necessarily have to appear at the end of a section, though they usually do.

  [Stopka nie musi się koniecznie znajdować na końcu sekcji, ale tam zazwyczaj się ją umieszcza.]

  Nazwa tego elementu (jak i zresztą headera) jest o tyle niefortunna, że tak naprawdę oznacza element z dodatkowymi metadanymi odnośnie sekcji, w jakim się znajduje, nie zaś – dosłownie stopkę.

• Nazwanie aside odrębną częścią strony nie jest do końca precyzjne, bo taką osobną częścią jest też choćby article czy figure. Z kolei aside to sekcja zawierająca treść poboczną, czyli w luźny sposób związaną z treścią główną. Zasada kciuka brzmi: jeśli daną treść można usunąć i nie zmieni to w żaden sposób sensu treści głównej, to można to uznać za aside.

  Nie ma też żadnych przeciwskazań do stosowania więcej niż jednego elementu aside na stronie.

• Twierdzenie, że figure i figcaption to jedno i to samo jest nieprawdziwe. Element figure oznacza niezależną „ilustrację” (rozumianą nie tylko jako obrazek, ale wszystko to, co w książce zaprezentowane zostałoby z podpisem). Z kolei element figcaption to podpis takiej „ilustracji”. Zasada kciuka jest taka: jeśli do danej rzeczy odwołujemy się z głównej treści i można ją w całości wydzielić, a w książce znalazłaby się w indeksie ilustracji/wykresów/zdjęć/map itp., to można zastosować figure. Tym samym nieprawdziwe jest też twierdzenie, że element ten jest używany wyłącznie do obrazków. W CKEditorze używamy go m.in do oznaczania cytatów blokowych czy tabelek.

• Twierdzenie, że i jest używane do wstawiania ikonek, jest całkowicie nieprawdziwe. W tej kwestii wypowiadało się nawet W3C. Ten element ma ściśle określone znaczenie i służy m.in. do oznaczania terminów w obcym języku lub terminów technicznych.

• Dziwi także marginalizacja znaczenia niektórych elementów, np. time. Osobiście używałem go wielokrotnie – za każdym razem, gdy musiałem oznaczyć jakąś datę czy czas. Z kolei elementów sub i sup nie użyłem praktycznie ani razu, podczas gdy w tym filmie poświęca im się naprawdę sporo uwagi, jako jednym z ważniejszych elementów.

• Odważnym jest też twierdzenie, że z multimediów używa się obecnie głównie elementu img. Wypada wspomnieć choćby o elemencie picture, który jest wykorzystywany m.in. do warunkowego wczytywania nowych formatów obrazków.

• […] większość poważnych firm używa flexa. A może Janusze Internetu robią to gridem, żeby pokazać, że są fajni.

  Takie słowa nie powinny paść w kursie. Choćby dlatego, że są najzwyczajniej w świecie nieprofesjonalne i nie niosą żadnej merytorycznej wartości. A drugim, może ważniejszym powodem, jest ich całkowite oderwanie od rzeczywistości. Bo owymi Januszami są m.in. Jen Simmons, twórczyni terminu Intrinsic Web Design, czy Rachel Andrew, członkini CSS WG i redaktorka naczelna Smashing Magazine’u.

  Także twierdzenie, że flex ma lepsze wsparcie, jest błędne. Flex i grid mają najlepsze wsparcie, jakie mogą mieć. Według Can I Use? CSS Grid ma wsparcie wszędzie, oprócz Opery Mini. Nawet w starym IE11 jest szczątkowa obsługa grida w starszej wersji. Globalnie przekłada się to na wsparcie powyżej 95%. A jedyne przeglądarki, które nie wspierają grida, są de facto martwe i nierozwijane. Nie ma na co czekać – lepiej i tak nie będzie.

  Założenie, że nie można używać danej technologii, zanim nie będzie miała wsparcia we wszystkich przeglądarkach, oznacza zabetonowanie technologii sieciowych na poziomie tych z czasów starych Internet Explorerów. To de facto oznacza blokowanie całej Sieci i o wiele lepszym podejściem jest nieoptymalizowanie pod stare przeglądarki. Zwłaszcza, że standardy sieciowe są tworzone według określonych reguł i mają zapewnioną jak najwyższą kompatybilność wsteczną. Jeśli dana przeglądarka nie obsługuje grida, layout zostanie po prostu wyświetlony w jednej kolumnie. Strony nie muszą wyglądać wszędzie tak samo, muszą być przede wszystkim użyteczne. Ci, którzy z różnych przyczyn korzystają z archaicznych przeglądarek, wciąż będą mieli dostęp do strony. Natomiast cała reszta (czyli ponad 95% użytkowników!) dostanie najlepsze z możliwych doświadczeń.

  Dodatkowo argument o wsparciu dla wszystkich przeglądarek bardzo łatwo sprowadzić do absurdu. Bo takiego wsparcia nigdy nie będziemy w stanie zapewnić. Choćby dlatego, że istnieje taka przeglądarka jak Lynx.

  Przy okazji: znamienne jest to, że ta dygresja została wtrącona przy tabelkach. Czyżby autor pamiętał zamierzchłe czasy?

• W quizie po tym filmiku również są błędy, np.

  Który z elementów może znajdować się wewnątrz section?

  Poprawne są dwie odpowiedzi: article i div. Nieprawdą jest bowiem, że sekcje mogą się znajdować w artykułach, ale nie na odwrót. Wszystko zależy od relacji między poszczególnymi sekcjami strony.

Elementy semantyczne

• Osobiście stoję na twardym stanowisku, że element semantyczny to pleonazm.

• Opozycja b do strong jest fałszywa, bo zasadza się na błędnym przekonaniu, że taka sama domyślna prezentacja dwóch elementów oznacza, że robią to samo. Jak już wspominałem w tym artykule, prezentacja nie jest częścią HTML-a. HTML należy rozpatrywać na punkcie semantyki. I na tym gruncie te elementy są zupełnie różne: element b oznacza fragment, który został wyróżniony z powodów praktycznych, ale bez zaznaczania jego dodatkowej ważności (np. lead artykułu), z kolei element strong oznacza ważniejszy od swojego otoczenia fragment treści.

  Opozycja, o jakiej mowa w filmie (niesemantyczny vs semantyczny element) istniała w HTML 4. W nim, owszem, element b był niezalecany i proponowano zamiast niego użycie arkuszy stylów. Z kolei strong definiowano jako silniejszą emfazę. W HTML LS nastąpiło jednak zaktualizowanie znaczenia większości znaczników i element b stał się na powrót elementem mającym znaczenie.

• Niektóre przeglądarki chciały być troszeczkę dalej i np. stworzyły syntezatory mowy, które po prostu mówią nam, co znajduje się na stronie. I one właśnie takie znaczniki [semantyczne] wykorzystują tak, żeby osoby niewidome też mogły się zapoznać z naszą stroną […]

  W tym fragmencie źle jest absolutnie wszystko.

  HTML5 nie powstał w wyniku konkurencji przeglądarek, ale właśnie w wyniku ich wspólnego buntu przeciwko planom W3C co do XHTML 2. Dlatego powołano WHATWG i zaczęto pracować nad nową wersją HTML-a. Tę historię można przeczytać bezpośrednio w specyfikacji. Co więcej, elementy w HTML5 powstały z jednej strony przez skopiowanie części rzeczy z XHTML 2, z drugiej – sporo z nich wymyślił Ian „Hixie” Hickson. Wspomina o tym m.in. w wywiadzie dla HTML5 Doctora czy w wypowiedzi udzielonej do książki The Truth About HTML5. Książka ta dobrze dokumentuje fakt, że wiele z elementów w HTML-u było wymyślonych na podstawie nieprecyzyjnych badań i arbitralnych decyzji. I to jest w sumie jedyne, co ta książka robi dobrze. W wielu innych miejscach jest dziwnie podobna do recenzowanego kursu.

  Przeglądarki nie stworzyły czytników ekranowych (uparcie tutaj nazywanych syntezatorami mowy, co jest całkowicie błędne; syntezatorem mowy jest choćby Web Speech API – zupełnie inna technologia). To zupełnie oddzielne produkty (jak JAWS czy NVDA), a jedynym punktem stycznym przeglądarek i czytników ekranu jest drzewko dostępności. Przeglądarki generują to drzewko na podstawie drzewka renderowania, dzięki czemu czytnik (ale i też inne technologie asystujące) mogą dowiedzieć się, co znajduje się na stronie. Czytniki ekranowe zatem nie wykorzystują elementów HTML wprost i nie mają dostępu do tego, co nie jest częścią drzewka dostępności.

  Przykładem elementu, którego nie ma w drzewku, jest element strong, który w dalszej części tego filmiku jest podany błędnie jako przykład działania czytnika ekranowego. Czytnik nie moduluje głosu po natrafieniu na strong, bo tego elementu nie ma w drzewku i trwają dyskusje, czy i jak go reprezentować.

  Warto też wspomnieć, że czytników ekranowych nie używają tylko osoby niewidome.

• Nieprawdą jest twierdzenie, że elementy z HTML5 mają wsparcie od IE9. Pełne wsparcie oznacza nie tylko wsparcie dla stylowania, ale przede wszystkim – wsparcie dla reprezentacji elementów w drzewku dostępności. Sporej części takiego wsparcia brakuje nawet w IE11.

  Inna rzecz, że wsparcie stylowania elementów z HTML5 w IE8 można łatwo uzyskać przy pomocy html5shiva lub, jeśli chcemy się też zabezpieczyć przed użytkownikami IE8 z wyłączonym JS-em, poprzez stylowanie divów wewnątrz elementów z HTML5.

• Sugerowanie w 2021 roku, żeby nie używać „nowych” elementów z powodu braku wsparcia w części przeglądarek, automatycznie dyskwalifikuje ten kurs. Jedyną przeglądarką, jaka nie wspiera tych elementów, jest Internet Explorer, który, według danych statcountera, miał w lutym porywające 0.81% udziału w rynku. W danych Gemiusa IE nie jest już nawet odnotowywany. I z powodu przeglądarki, która ma niespełna 1% udziału w rynku, w tym kursie rekomenduje się nieużywanie od lat uznanych i wspieranych rozwiązań.

  Nawet jeśli sytuacja wyglądałaby tak, jak jest to podane w kursie (co najmniej 5% użytkowników), to wciąż oznacza, że 95% użytkowników serwujemy gorsze doświadczenie. Nie tędy droga! Nawet Wikipedia już nie optymalizuje pod Internet Explorera. W zupełności dla tej (praktycznie nieistniejącej już na rynku!) przeglądarki starczy wspomniany html5shiv czy technika ze stylowaniem divów wewnątrz innych znaczników. A cała reszta (czyli ponad 99% użytkowników) niech spokojnie korzysta z dobroci, jaką oferują „nowe” elementy HTML.

Podsumowanie

Ten kurs jest niesamowicie szkodliwy i nie ma nic wspólnego z tworzeniem nowoczesnych, użytecznych i dostępnych witryn.

Trudno mi znaleźć inne słowo do opisu tego, co można usłyszeć w demonstracyjnych lekcjach, jak żenujące. Praktycznie do każdego zdania wypowiadanego przez prowadzącego można by zrobić przypis ze sprostowaniem. Oglądnąłem tylko 3 filmiki z 10 dostępnych w wersji demonstracyjnej i powiem szczerze, że więcej mi się najzwyczajniej w świecie nie chce. Zwłaszcza, że materiału na artykuł i tak zebrało się aż nadto. Nie sądziłem, że kiedyś to powiem, ale ten kurs stoi na niższym poziomie niż materiały W3Schools. A to naprawdę spore osiągnięcie…