Maciej Rościszewski, Zawód front-end developer. 11 kroków do zostania webmasterem

Ostatnio znajoma zapytała mnie, co sądzę o książce Macieja Rościszewskiego Zawód front-end developer. 11 kroków do zostania webmasterem. Nic nie sądziłem, bo nie czytałem, niemniej postanowiłem nadrobić braki.

• Książka powtarza dokładnie te same mity/nieprawdziwe informacje, co zdecydowana większość kursów w Polsce:

  • DOCTYPE nie jest znacznikiem, to preambuła dokumentu HTML i w żaden sposób nie określa typu dokumentu. Preambuła służy tylko i wyłącznie wymuszeniu renderowania w trybie standardów:

    DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.

    [DOCTYPE jest wymagany z powodu kompatybilności wstecznej. Jeśli się go pominie, przeglądarki często używają innego trybu renderowania, który jest niekompatybilny z pewnymi specyfikacjami. Umieszczenie DOCTYPE w dokumencie zapewnia, że przeglądarka podejmie wszelkie kroki, by ściśle trzymać się odpowiednich specyfikacji.]

    W książce rola DOCTYPE jest jeszcze bardziej rozwinięta i sugeruje się, że bez jego zamieszczenia przeglądarka nie rozpozna, że ma do czynienia z plikiem HTML i ściągnie go na dysk użytkownika. To nieprawda, bo w chwili, gdy przeglądarka zaczyna parsować plik HTML (a więc w momencie, gdy w ogóle ma szansę „zobaczyć” DOCTYPE), typ pliku jest już dawno określony, na podstawie typu MIME.

  • Omijanie zamykających znaczników dla html, body, p nie jest błędem, a zachowaniem dokładnie opisanym w standardzie. Tym samym podawanie tego jako przykład poprawiania błędów przez przeglądarki jest… błędem merytorycznym.

    Natomiast przykładem tego typu naprawiania może być np. zamykanie niezamkniętych znaczników div czy wyrzucanie poza tabelę znaczników, które nie mogą się w niej znaleźć, np:

    <table>
    	<tr>
    		<td>Komórka</td>
    		<span>Nie-komórka</span>
    	</tr>
    </table>

    zostanie w czasie parsowania zmienione na:

    <span>Nie-komórka</span>
    <table>
    	<tbody>
    		<tr>
    			<td>Komórka</td>
    		</tr>
    	</tbody>
    </table>

    Warto tutaj przy okazji zauważyć, że parser HTML sam z siebie wstawił znacznik tbody. Cały proces jest dokładnie opisany w specyfikacji i jest na tyle skomplikowany, że o parserze HTML powstają książki.

  • Używanie h1 więcej niż raz na stronie jest dozwolone z punktu widzenia standardów, ale szkodliwe z punktu widzenia dostępności. Dlatego też zasada używania h1 tylko i wyłącznie do głównego nagłówka strony jest najsensowniejszym wyjściem.

  • b, i, u nie są znacznikami używanymi dawniej. W HTML5 mają swoje unikalne znaczenie. Dodatkowo zarówno one, jak i strong, em, mark nie służą do stylizowania tekstu, tylko dodawania odpowiedniego znaczenia wybranym fragmentom treści.

  • Coś takiego jak znaczniki semantyczne to oksymoron. W HTML prawie wszystkie znaczniki (z drobnymi wyjątkami, np. div, span, template) mają znaczenie – ergo: są semantyczne.

  Naprawdę zastanawia mnie, jakie jest źródło tych informacji. W takiej samej lub podobnej formie pojawiają się niemal we wszystkich polskich kursach. Czyżby ich źródłem było niesławne W3Schools?

• Znacznik ten [<img>] nie ma znacznika zamykającego, gdyż grafika sama w sobie określa szerokość oraz wysokość.

  s. 42

  To wytłumaczenie jest dość niefortunne, bo stoi w sprzeczności do innych tagów bez znaczników zamykających, jak choćby link, meta, br. Prawdę mówiąc nie próbowałbym tłumaczyć, dlaczego dany tag nie ma znacznika zamykającego. W większości przypadków to są tak naprawdę zaszłości historyczne.

• Przy opisywaniu znaczników article, section książka praktycznie pomija kwestię stosowania w nich nagłówków. Prawda jest jednak taka, że znaczniki sekcyjne bez nagłówków nie mają sensu. Sekcję na stronie można wyróżnić właśnie dlatego, że istnieje jakiś nagłówek, oddzielający daną część strony od reszty.

• Znaczenie niektórych innych znaczników zostało z kolei spłycone, jak np. footer, który został potraktowany wyłącznie jako stopka strony. Nie jest to prawda, bo footer może być umieszczany także w znacznikach sekcyjnych:

  The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. […] When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page.

  [Element footer reprezentuje stopkę dla najbliższego przodka, który jest treścią typu sekcyjnego lub korzeniem sekcji. […] Jeśli najbliższym tego typu przodkiem jest element body, wówczas stopka należy do całej strony.]

• Niektóre znaczniki zostały pomylone, jak np. informacja, że obecnie nie używa się ramek iframe. Owszem, dzisiaj nie używa się ramek, ale frameset.

• Bardzo często ignorowane są dobre praktyki:

  • Nie wszystkie pola formularzy mają label. Ten znacznik tak po prawdzie pojawia się tylko w kontekście pól wyboru.

  • Do stylowania bardzo często używany jest [id], co od dawna jest uznawane za złą praktykę. Bardzo często pojawiają się też wieloelementowe selektory (np. aside ul li a), które ściśle wiążą CSS ze strukturą HTML-a, co utrudnia wprowadzanie zmian.

  • Przy opisie atrybutu [target] nie wspomina się o kwestiach bezpieczeństwa.

  • Przy walidacji formularza w przykładowym projekcie jest przyjęte założenie, że użytkownik wprowadzi znaki specjalne tylko w ostatnim polu, a w pozostałych – nie:

    Nie uważam, żeby przy wprowadzaniu imienia lub nazwiska mogły się pojawić znaki specjalne.

    s. 437

    To bardzo złudne założenie, które stanowi lukę w zabezpieczeniach strony. Absolutnie wszystkie dane pochodzące od użytkownika powinny być odpowiednio filtrowane.

  • W książce omawiane są podstawy animacji i przejść w CSS, niemniej brakuje informacji o tym, jak wydajnie animować.

• Oprócz pomijania dobrych praktyk w książce znajduje się też szereg przestarzałych praktyk:

  • Układ strony wciąż budowany jest na float, mimo że od dawna istnieją zarówno flexbox, jak i CSS Grid, które są o wiele logiczniejszymi – i tym samym: prostszymi do zrozumienia – sposobami tworzenia układu strony.

  • W książce wciąż stosowany jest model pudełkowy zaproponowany przez W3C, który wymusza dokonywanie dodatkowych obliczeń przy tworzeniu układu strony (w celu odjęcia marginesów wewnętrznych od szerokości i wysokości elementu). Jest to o tyle niezrozumiałe, że dobre praktyki związane z box-sizing ugruntowały się dobre 5 lat temu.

  • W przykładowym projekcie stosowany jest reset stylów, bez wspomnienia o o wiele bardziej dzisiaj popularnej normalizacji stylów.

  • W kodzie CSS używane są licznie przedrostki, mimo że są używane do tych własności CSS, które tych przedrostków od wielu lat nie potrzebują (jak np. box-shadow). Co więcej, wersje z przedrostkami są umieszczane w kodzie po wersji bez przedrostków, co powoduje nadpisywanie zgodnej ze standardami implementacji danej własności eksperymentalną implementacją danej przeglądarki.

• Większość książki stanowi tak naprawdę encyklopedyczne przedstawienie znaczników HTML i własności CSS. To, czego mi tutaj brakuje, to wykorzystanie tej wiedzy w realnym projekcie. Owszem, taki projekt jest tworzony w książce, niemniej spora część wiedzy przedstawianej w reszcie książki nie jest w nim wykorzystywana. Zamiast tego pokazywana jest na bardzo prostych, oderwanych od reszty przykładach. A szkoda. Osobiście wprowadzałbym tylko te elementy, które służyłyby do stworzenia konkretnego projektu, i na ich podstawie pokazał, jak się pracuje z HTML-em i CSS-em. Nie widzę sensu w powielaniu dokumentacji, z której każdy i tak powinien korzystać po przepracowaniu książki.

  Co więcej, informacje o części własności CSS są niekompletne, jak np. o wartościach własności display czy position (w tym drugim przypadku brakuje wartości sticky).

• Niektóre pojęcia są tłumaczone w bardzo uproszczony lub spłycony sposób:

  • Responsywność jest ograniczona wyłącznie do urządzeń mobilnych i w książce strony przystosowanej dla telewizora 16:9 lub do druku nie nazywa się już responsywną. A przecież to są przykłady responsywności! Responsywność zakłada jak najpełniejsze przystosowanie się treści do medium, w którym jest wyświetlana – czy to będzie ekran urządzenia mobilnego, czy telewizor 4k, czy interfejs głosowy w inteligentnych okularach, czy nawet druk.

  • nth-child() […] polega na liczeniu wszystkich elementów znajdujących się na tej samej pozycji co element, do którego przypisana jest pseudoklasa.

    s. 171

    Taka definicja jest całkowicie niezrozumiała. Nie bardzo wiadomo, co to ta sama pozycja co element. Definicja na MDN o wiele lepiej sobie radzi z tym określeniem, używając bardzo podobnego słownictwa:

    The :nth-child() CSS pseudo-class matches elements based on their position in a group of siblings.

    [Pseudoklada CSS :nth-child() dopasowuje elementy na podstawie ich pozycji w grupie rodzeństwa.

  • W internecie, jak w każdej dziedzinie życia, istnieje moda, która nazywa się web design, czyli w wolnym tłumaczeniu — styl internetu.

    s. 214

    To naprawdę wolne tłumaczenie. Design nie jest żadną modą czy stylem, lecz – procesem projektowania doświadczenia użytkownika.

  • W książce pojęcia biblioteki i frameworka są uznawane za synonimy i stosowane zamiennie. To spore nadużycie terminologiczne, bo znaczą one jednak coś zgoła innego. Biblioteka jest zbiorem funkcji, pomagającym tworzyć aplikację. Framework z kolei jest rozwiązaniem będącym szkieletem architektonicznym aplikacji. To są pojęcia operujące na totalnie różnych poziomach abstrakcji.

• Do książki były dołączone przykłady na FTP, w których zawarty jest cały projekt strony, jaki powstaje w trakcie czytania. Niemniej – jak już wspominałem – w książce powtarzają się praktycznie te same błędy, co w większości innych kursów w Polsce. Tym samym nie bardzo widzę sens powtarzania dokładnie tego samego dla kolejnego projektu.

  Są jednak dwa fragmenty tego projektu, które zasługują na krótkie spojrzenie. Pierwszym z nich jest menu, w którym nie mamy poprawnych a[href=#]:

  <ul class="linki_menu">
  	<li><a href="#" class="top_strony_link">Główna</a></li>
  	<li><a href="#" class="kon_oferta_link">Oferta</a></li>
  	<li><a href="#" class="kon_dietetyk_link">Dietetyk</a></li>
  	<li><a href="#" class="mapa_link">Dojazd</a></li>
  	<li><a href="#" class="kon_kontakt_link">Kontakt</a></li>
  </ul>

  Całość obsługi tego typu linków znajduje się w kodzie JS. To oznacza, że jeśli ktoś spróbuje np. otworzyć dany link w nowej karcie (przez kliknięcie kółkiem myszy), zostanie mu otwarta cała strona raz jeszcze, bez przewinięcia w określone miejsce. Stworzenie poprawnych linków rozwiązałoby wszelkie problemy związane z tego typu menu.

  Drugim fragmentem kodu jest formularz kontaktowy wysyłany Ajaksem. Co ciekawe, przed dodaniem Ajaksu formularz miał poprawne atrybuty [method], [action], ale zostały one usunięte przy dodaniu kodu JS. To nie ma sensu – i to nie tylko dlatego, że JS może nie zadziałać. Jak chwilę wcześniej zauważyliśmy w przypadku menu, nie trzeba odtwarzać wszystkiego w kodzie JS. Posiadanie semantycznego kodu HTML pozwala nam znacząco uprościć kod JS. Tym samym można spokojnie pobrać informację o tym, gdzie wysłać formularz, bezpośrednio z formularza. Co więcej, gdybyśmy zastosowali natywną walidację pól formularza z HTML5, moglibyśmy także uprościć niemal cały kod walidacji. Wprowadzenie JS-a nie oznacza zniszczenia HTML-a (bo tym właśnie są takie zmiany). Można bez problemu nadbudować JS na istniejącym kodzie HTML – co od lat z powodzeniem pokazuje Progressive Enhancement.

W trakcie czytania książki zauważyłem, że autor pisze, że powstawała pod koniec 2017 roku. Nie bardzo zatem rozumiem, dlaczego wyszła dopiero teraz, w kwietniu 2019. Niemniej nie to frapuje mnie najbardziej. Cały czas zastanawiam się, czemu w polskich kursach nieustannie powtarza się błędne informacje – niemal zawsze te same i niemal zawsze bardzo proste do empirycznej weryfikacji. Odnoszę wrażenie, jakby istniało jakieś nieznane mi źródło wiedzy, w którym tego typu rzeczy zapisano wieki temu i od tego czasu wszyscy adepci webdevu w Polsce z tego źródła czerpią, zdając się wyłącznie na jego autorytet i tym samym nie weryfikując pewnych rzeczy. I prawdę mówiąc nie wydaje mi się, żeby tym źródłem było W3Schools – mimo sporego podobieństwa w pewnych aspektach. Ale jeśli nie W3Schools, to co…?