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…?

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

  1. Napisz swoją książkę na ten temat i tyle! Wprowadzi się ją do kanonu polskiego web developmentu i ilość powielanych błędów znacząco spadnie. I tak kto śledzi choć trochę polską społeczność to wie, że jesteś jednym z najlepszych speców w kraju a już napewno w kwestiach HTML. Kto ma robić takie rzeczy jak nie ludzie tacy jak Ty 🙂

    1. Główna zasada WebKrytyka brzmi, że pojawiają się tutaj tylko strony polskie. Co prawda kilka razy ta zasada została złamana (np. W3Schools czy Angular.js), niemniej ogólnie obowiązuje. Dlatego raczej nie, chociaż nie wykluczam, że kiedyś może się pojawić.

  2. Tomasz, a jakbym miał, dajmy na to, bloga publicystycznego o IT, polityce albo sporcie, i sprzedawał z sukcesem jakieś produkty, nie wiem, moje książki, płyty, rysunki, cokolwiek, zaznaczam z sukcesem, i przekornie użył floata do zrobienia sobie 3-kolumnowego bloga, a nagłówki zrobił w postaci Headline no albo Headline. Blog natomiast byłby ładny, solidnie zaprojektowany przez kolegę designera. Co by się wtedy stało? Czy przestałbym zarabiać pieniądze? Czy ludzie przestaliby dzielić się moimi wpisami na Fejsie? Przestaliby rozmawiać – zakładając, że byłbym interesującym autorem – o moich treściach? Moim blogiem zajmowałbym się ja osobiście albo jakiś kolega, nie musiałbym wprowadzać zbyt często zmian, bo nie miałbym na to czasu, a poza tym ludzie przychodziliby po posty, książki i inne produkty. Na Google’a nie zwracałbym uwagi, bo już dawno wypracowałbym sobie target, który powiększa się offlinowo albo przez pocztę pantoflową w social mediach/w realu.

    Pytam przekornie, jestem ciekaw Twojej odpowiedzi i zmierzenia się z tym.

    1. Nie bardzo rozumiem, z czym miałbym się tu „zmierzyć”. To jest dyskusja na całkowicie inny temat, zahaczający o etykę biznesu. A tutaj mówimy o uczeniu tworzenia stron.

  3. Może ci co piszą takie książki i kursy poznali temat jeszcze na studiach, a tam to wszystko jest przestarzałe bo wykładowcy uczyli się tego bardzo dawno temu i zazwyczaj nie mają praktyki albo nie znają tych nawet nie tak nowych nowinek. Wiec jak taki autor uczył się na studiach i wtedy jeszcze sam się dokształcał to wtedy to musiało być dawno temu. Pewnie ci co siedzią w tym i znają nowości nie piszą książek i kursów bo robią strony, a ci co nie robią stron i się nie uczą piszą książki bo mają czas.

    Więc tak jak napisał Bartek warto by byś napisał swoją książkę. Jeśli by była o semantycznym HTML i dobrych praktykach CSS to na pewno bym z chęcią kupił i przeczytał.

  4. @ferrante
    Zaskoczyłeś mnie tym komentarzem… i to znana osoba of frontendu…
    Ogólnie, to tu cyrki się wyprawiają w komentarzach pod tymi artykułami…
    Z roku na rok, coraz więcej osób neguje Dostępność stron…

  5. Hej. Jestem początkującym web devem i mam takie pytanko. Czy jest może jakaś strona na której było by wszystko napisane o semantyce i jak pisać kod, żeby strona była jak najlepiej dostępna? Z góry dzięki.

  6. @ferrante
    Nie wiem czemu miał służyć Twój post. Chyba miałeś wtedy zły dzień, albo nie podoba Ci się to co robi Tomek, czego nie rozumiem, bo on nikomu nie chce zaszkodzić, a po prostu pomóc. Chłop ma naprawdę złote serce oraz ogromną wiedzę i jeszcze się nią dzieli co jest bardzo rzadko spotykane w dzisiejszych czasach.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.