Kurs Web developer od podstaw w 15 dni od Samuraja Programowania

Ostatnio bardzo dużą popularnością cieszą się kursy Samuraja Programowania. Postanowiłem zatem sprawdzić, czy faktycznie za tak dużą popularnością kryje się nadzwyczajna jakość. W tym celu zakupiłem kurs Web developer od podstaw w 15 dni. Jest to pierwszy z sześciu kursów mających przygotować uczącego się do objęcia posady web developera. Zobaczmy zatem, co ciekawego się z niego dowiemy.

Cały kurs jest podzielony na dni: od pierwszego do piętnastego. Z tego też względu pomyślałem, że najlepiej będzie ten artykuł również podzielić na dni, opisując, co się dzieje w każdym z nich.

Dzień 1.

  • Jest to pierwszy dzień kursu, więc zaczynamy od absolutnych podstaw, czyli instalacji edytora i szybkiego zapoznania się z nim. I tutaj nasuwa mi się pierwsza wątpliwość. Mam wrażenie, że autor kursu założył, że wszyscy (a przynajmniej zdecydowana większość) oglądający będą posługiwać się Windowsem. Stąd bardzo dużo szczegółów dotyczących używania edytora i tworzenia katalogu z projektem jest tak naprawdę specyficzna dla Windowsa. Takie założenie byłoby poprawne jeszcze kilka lat temu, ale mamy już 2019 rok i świadomość osób – zwłaszcza zainteresowanych programowaniem – jest obecnie wyższa i coraz częściej osoby takie posługują się systemem macOS lub jedną z dystrybucji Linuksa.

    Dodatkowo odnoszę wrażenie, że omawiania edytora było nieco za dużo. Osobiście jestem jednak zwolennikiem nauki przez indukcję: pokazać daną rzecz raz, a następnie po prostu naturalnie jej używać tak, aby uczący się „oswoił” z nowym narzędziem.

  • Fakt Windowsocentryzmu przejawił się moim zdaniem jeszcze w jednym: zaleceniu, żeby zainstalować Edge, jeśli go nie posiadamy. Rada sensowna, acz całkowicie niepraktyczna, ponieważ Edge nie jest możliwy do zainstalowania na żadnym innym systemie operacyjnym niż Windows 10. Owszem, można skorzystać z maszyn wirtualnych, ale nie jest to najwygodniejsza opcja.

    Osobiście w tym miejscu wprowadziłbym od razu takie usługi jak Browserstack, umożliwiające podgląd strony w różnych przeglądarkach i na różnych urządzeniach. Jestem w stanie zrozumieć, dlaczego tego nie zrobiono (jest to płatna usługa, jeśli nie wykorzystujemy jej do projektów open source), ale z drugiej strony – jest to też najłatwiejszy sposób sprawdzania kompatybilności strony z różnymi przeglądarkami i urządzeniami. I wbrew pozorom nie jest to też trudna w wykorzystaniu usługa, nadaje się nawet dla początkujących.

  • Od samego początku można też odnieść wrażenie, że w tym kursie jako stronę internetową będziemy rozumieli głównie jej design, prezentację. Jest bowiem de facto na wstępie zaznaczone, że HTML-owi poświęcone są tylko 2 pierwsze dni, a pozostałe są o CSS-ie. Jak dla mnie ta dysproporcja jest zdecydowanie za duża. HTML wbrew pozorom nie jest aż tak prostym językiem i z jego używaniem wiąże się sporo kruczków, które mogą powodować, że strona będzie mało dostępna.

    W przeświadczeniu, że kurs będzie dotykał przede wszystkim wizualnej części stron, utwierdziło mnie kilka innych rzeczy. Po pierwsze o semantyce wspomniano przede wszystkim w kontekście SEO – a przecież ten kontekst akurat w przypadku semantyki jest najmniej istotny. Stronę piszemy przede wszystkim dla użytkowników, nie dla wyszukiwarki. Wspomina o tym nawet Google:

    Make pages primarily for users, not for search engines.

    [Twórz stronę przede wszystkim dla użytkowników, nie wyszukiwarek.]

    Z tego samego powodu wspomnienie o tym, że w tytule strony czy nagłówkach można umieścić słowa kluczowe, uważam nie tyle za zbędne, co najzwyczajniej w świecie szkodliwe. W kursach tworzenia stron internetowych tematyka SEO powinna być poruszana na końcu, po omówieniu semantyki, dostępności, wydajności itd. i nie powinna mieć wpływu na te aspekty tworzenia stron, ale być jedynie uzupełnieniem.

    Druga kwestia, jaka utwierdziła mnie w przekonaniu o dominującej roli prezentacji, to fakt, że padło stwierdzenie, iż zła wartość atrybutu html[lang] nie powoduje zmian widocznych dla użytkownika. Problem w tym, że jak najbardziej powoduje – choćby dla użytkowników korzystających z czytników ekranowych, które korzystają z tego atrybutu, by odpowiednio dobrać lektora czytającego tekst strony. W tym wypadku dobór złego języka może spowodować, że dla takich osób strona stanie się całkowicie niezrozumiała. A przecież podnoszenie świadomości dostępności powinno być jednym z głównych zadań tego typu kursów!

  • W trakcie tego pierwszego dnia kursu pojawiło się też wiele nieprawdziwych informacji lub powielanych mitów.

    Na sam początek po raz kolejny pojawiło się stwierdzenie, że DOCTYPE informuje przeglądarce o wykorzystywanej wersji HTML-a. To nieprawda, bo ma on za zadanie tylko i wyłącznie wymuszenie renderowania strony w tzw. trybie standardów zamiast w trybie dziwactw (ang. quirks). Wspominają o tym co najmniej dwie specyfikacje. W specyfikacji HTML czytamy:

    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 specyfikacji DOM czytamy z kolei:

    The mode is only ever changed from the default for documents created by the HTML parser based on the presence, absence, or value of the DOCTYPE string, and by a new browsing context (initial "about:blank").

    [Tryb jest zmieniany z domyślnego tylko dla dokumentów stworzonych przez parser HTML na podstawie obecności, nieobecności lub wartości DOCTYPE oraz dla nowych kontekstów przeglądania (jak np. "about:blank").]

    Co więcej w specyfikacji HTML zawarty jest cały podrozdział dotyczący reguł parsowania HTML-a, powstały na podstawie istniejących implementacji w przeglądarkach. Przeglądarki nie mają kilku parserów, a dokumenty HTML 4.01 są parsowane dokładnie według tych samych reguł co HTML5.

    Kolejnym pojawiającym się mitem jest informacja o tym, że wszystkie przeglądarki mają ten sam domyślny rozmiar fontu. To nieprawda. Nie dość, że niektóre przeglądarki mają inne domyślne rozmiary fonta, to dodatkowo ludzie zmieniają rozmiar domyślnego fonta. Dlatego najlepiej w ogóle go nie zmieniać, a całość obliczeń oprzeć na proporcjach i zakresach. W dobie IWD czy zegarków z przeglądarkami wydaje się to być najrozsądniejszym podejściem.

    Kolejnym nieprawdziwym stwierdzeniem było to, że strona musi zostać w całości wczytana, by zostać wyrenderowana. Nie jest to prawdą. Przeglądarki od lat stosują tzw. spekulatywne parsowanie (ang. speculative parsing) pozwalające przewidywać, jak wygląda dalsza część strony i na tej podstawie konstruować DOM. Co więcej, strony można wczytywać partiami, wykorzystując wiele małych blokujących renderowanie arkuszy CSS. Ba, w przyszłośći możemy doczekać się parsera HTML-a opartego o strumienie.

    Padło też stwierdzenie, że HTML5 zapewnia lepszą współpracę z JS i dzięki niemu szybciej można wpłynąć na stronę. Nie do końca się z tym zgodzę, bo większość interakcji ze stroną zachodzi na poziomie DOM, a ten jest częściowo rozwijany poza HTML5, jako osobna specyfikacja. Dodatkowo duża część specyfikacji łączona z HTML5 jest tak naprawdę osobnymi bytami, jak np. geolokacja.

    Padło też stwierdzenie, że HTML5 w końcu sensownie obsługuje błędy. To prawda, w specyfikacji jest fragment poświęcony błędom. Niemniej żadna z rzeczy podana jako przykład nie jest błędem:

    • Znaczniki pisane dużymi literami nie stanowią błędu składniowego. Za specyfikacją:

      In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element’s tag name; tag names are case-insensitive.

      [W składni HTML nazwy tagów, nawet te dla obcych elementów, mogą być zapisywane przy pomocy dowolnie wymieszanych małych i dużych liter w taki sposób, żeby po konwersji wszystkich znaków na małe, odpowiadały one nazwie elementu; nazwy tagów są niezależne od wielkości liter.]

    • Brak znacznika head również nie stanowi błędu składniowego. Za specyfikacją:

      A head element’s start tag can be omitted if the element is empty, or if the first thing inside the head element is an element.

      A head element’s end tag can be omitted if the head element is not immediately followed by ASCII whitespace or a comment.

      [Otwierający tag elementu head może zostać pominięty, jeśli element jest pusty lub jeśli pierwsza rzecz wewnątrz elementu head jest elementem.

      Zamykający tag elementu head może zostać pominięty, jeśli element head nie poprzedza bezpośrednio białego znaku z zakresu ASCII lub komentarza.]

      Fakt, że przeglądarka generuje dla każdej strony ten sam szkielet DOM wynika z innych fragmentów specyfikacji, a przede wszystkim dokładnego opisu trybów parsowania tokenów.

    • Brak zamknięcia znacznika p również nie jest błędem składniowym. Za specyfikacją:

      A p element’s end tag can be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element.

      [Zamykający tag elementu p może zostać pominięty, jeśli znacznik p poprzeda bezpośrednio element address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table lub ul lub jeśli w elemencie rodzica nie ma więcej treści, a sam rodzic nie jest elementem a, audio, del, ins, map, noscript, video lub niezależnym niestandardowym elementem.]

  • W pierwszym dniu pojawiło się też nieco nieścisłości i niepotrzebnych informacji.

    Padło m.in. stwierdzenie, że po wejściu na dowolny adres, bez podania nazwy plików, domena domyślnie szuka i wyświetla plik index.html. Jest to bardzo mocne nagięcie terminologii technicznej, ponieważ domena stanowi wyłącznie adres, a serwowaniem jakiejkolwiek treści pod tym adresem zajmuje się serwer WWW.

    Dodatkowo pokazano też inne kodowania niż UTF-8, co obecnie jest całkowicie niepotrzebne, ponieważ standardy sieciowe wymuszają kodowanie UTF-8:

    Regardless of whether a character encoding declaration is present or not, the actual character encoding used to encode the document must be UTF-8.

    [Niezależnie od tego, czy deklaracja kodowania znaków jest obecna, czy nie, rzeczywistym kodowaniem znaków użytym do zakodowania dokumentu musi być UTF-8.]

    W kontekście standardu HTML wspomniano wyłącznie o standardzie HTML 5.x od W3C. Obecnie, niestety, prace nad tym standardem są wstrzymane. Wszystko jest spowodowane faktem, że istnieją dwa standardy HTML – i warto o tym wiedzieć.

Dzień 2.

  • Ten dzień podzielony był na część teoretyczną i praktyczną. Jeśli do części praktycznej zarzutu mieć nie można, tak część teoretyczna składała się w dużej części z nieprawdziwych lub błędnych informacji.

    Niemniej zanim do nich przejdę, chciałbym zwrócić uwagę na jeszcze jedną rzecz: podejście prowadzącego do problemu semantyki. W pewnym momencie można wręcz usłyszeć słowa, że wybór pomiędzy znacznikami section i div jest tak naprawdę wyłącznie dobrą praktyką, a semantyka jest dla tworców stron, by lepiej rozumieć kod. Co gorsza padają też słowa, że zły dobór znacznika nie zmienia nic w działaniu strony czy wręcz jeśli nie wiemy [jaki znacznik], użyjmy czego chcemy. Także w przypadku hierarchii treści, tworzonej przy pomocy nagłówków, usłyszeć można, że nic złego się nie stanie, jeśli umieścimy je na stronie nie po kolei.

    Takie podejście jest nie tyle niezrozumiałe, co szkodliwe. Sama różnica pomiędzy div a section jest precyzyjnie opisana przez specyfikację i ma swoje odzwierciedlenie w rzeczywistym świecie, choćby w przypadku tego, jak czytniki ekranowe widzą te znaczniki. To samo dotyczy kolejności nagłówków, używanych przez użytkowników czytników ekranowych do nawigacji po stronie. Dlatego też niezwykle ważny jest dobór poprawnych znaczników, najlepiej pasujących do danej sytuacji. Oczywiście, specyfikacja zostawia w tym względzie pewną swobodę, ale nie można twierdzić, że semantyka jest tylko dla nas i można sobie dobierać znaczniki bez większych konsekwencji. Konsekwencją jest to, że nie wszyscy będą w stanie tak samo dobrze skorzystać z naszej strony, jeśli pozbawimy ją warstwy semantycznej lub – co często jest jeszcze gorsze – dobierzemy całkowicie złą semantykę.

    Nie mogę się zgodzić także z tym, że webdeveloperzy nie kłócą się na temat doboru odpowiednich znaczników na stronę. Tak po prawdzie to części z nas wręcz za to płacą, jako ekspertom od dostępności.

  • To, co mnie najbardziej zaskoczyło, to fakt, że w tym dniu bardzo duża część przykładów kodu HTML pochodziła bezpośrednio ze specyfikacji. To bardzo dobrze, niemniej problem polega na tym, że te przykłady często były wykorzystywane wbrew temu, co specyfikacja na dany temat mówi.

    Najdobitniejszym przykładem było pokazanie przykładu z poprawną hierarchią treści, stworzoną na podstawie nagłówków h1 do h6, a następnie na jego podstawie wprowadzenie informacji o tym, że hierarchię nagłówków można rozpoczynać od h1 w każdej sekcji. Jest to nieprawda i mit ten jest obalany od ponad 5 lat. Ten sposób tworzenia hierarchii (osobno dla każdej sekcji) nigdy nie został zaimplementowany w przeglądarkach i używanie więcej niż jednego nagłówka h1 nie jest zalecane. Przestrzega przed tym sama specyfikacja (w wielkiej, czerwonej ramce!):

    There are currently no known native implementations of the outline algorithm in graphical browsers or assistive technology user agents […].

    [Nie istnieją obecnie żadne znane, natywne implementacje algorytmu outline’u w graficznych przeglądarkach lub technologii asystującej […].]

    Niemniej nagłówki zostały potraktowane po macoszemu także w kontekście znacznika section. Tak naprawdę stronę na sekcje powinno się dzielić właśnie według nagłówków. Samo wyodrębnienie znaczeniowej całości na stronie nie czyni z niej jeszcze sekcji. O konieczności używania nagłówków wraz z sekcjami wspomina sama specyfikacja:

    Each section should be identified, typically by including a heading (h1h6 element) as a child of the section element.

    [Każda sekcja powinna być identyfikowana poprzez dołączenie nagłówka (elementu h1h6) jako dziecka elementu section.]

    Kolejną rzeczą, która była niezgodna ze specyfikacją, było stwierdzenie, że znacznika main można użyć więcej niż raz. Choć w wersji HTML LS była to prawda przez wiele, długich lat, to obecnie może być tylko jedno main na stronę. Element ten oznacza główną treść strony.

    Jeszcze inna rzecz, niezgodna ze specyfikacją HTML5, dotyczyła znaczników strong, em, b, i. Zostały użyte ich definicje z HTML 4.01, w którym faktycznie b, i były znacznikami prezentacyjnymi, a strong, em służyły oznaczaniu ważniejszych fragmentów tekstu. W HTML5 wszystkie te znaczniki są znacznikami semantycznymi, różniącymi się zakresem stosowania:

    • znacznik b służy do zaznaczania fragmentów tekstu bez równoczesnego sugerowania, że są ważniejszymi fragmentami i używa się go wówczas, gdy żaden inny znacznik nie pasuje, ale równocześnie dany fragment odgrywa jakąś rolę w tekście (np. jest słowem kluczowym) i nie jest to jedynie wyróżnienie stylistyczne;
    • znacznik i służy do oznaczania fragmentów tekstu o innym wydźwięku, ale także do oznaczania technicznych lub obcojęzycznych terminów, nazw statków itp.;
    • znacznik em służy oznaczaniu fragmentów tekstu, na które kładziony jest inny akcent;
    • znacznik strong służy do oznaczania fragmentów tekstu, które są ważniejsze od reszty otaczającego tekstu.

    Warto też wspomnieć o małej rozbieżności ze specyfikacją w zakresie składni samozamykających się elementów. Specyfikacja HTML bowiem w pełni zezwala na używanie w tym celu slasha (czyli np. <img />):

    1. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.
    2. Finally, start tags must be closed by a U+003E GREATER-THAN SIGN character (>).
    1. [Następnie, jeśli element jest jednym z pustych elementów lub jeśli jest obcym elementem, może wystąpić pojedynczy znak U+002F SOLIDUS (/). Ten znak nie ma efektu na pustych elementach, niemniej dla obcych elementów oznacza ich tag otwierający jako samozamykający się.
    2. Ostatecznie tag otwierający musi zostać zamknięty przez znak U+003E ZNAK WIĘKSZE NIŻ (>).]

    Na sam koniec listy rozbieżności ze specyfikacją warto wspomnieć o tym, że w kursie używane jest stare rozróżnienie na elementy blokowe i liniowe, które było obecne w HTML 4.01. HTML5 wprowadza bardziej szczegółowy podział elementów na kategorie. Warto przy tym zauważyć, że stary sposób podziału elementów nie wynikał z ich zawartości czy roli na stronie, lecz – domyślnych stylów CSS. A to nieco łamało zasadę rozdziału treści od prezentacji. Nie zmienia to jednak, że na najbardziej podstawowym poziomie podział na elementy blokowe i liniowe jest lepszy do wytłumaczenia pewnych różnic. Warto jednak od razu zaznaczyć, że jest to stary sposób podziału elementów.

  • Na sam początek dnia zostało przedstawione kodowanie prostej strony. Pojawiła się tam jedna praktyka zasługująca na szczególne potępienie – zwłaszcza, że wprowadzona została niemal tuż po wspomnieniu roli atrybutu [alt] dla czytników ekranowych: linki, w których jedyną treścią były elementy img z pustym atrybutem [alt]. Tego typu elementy są całkowicie niedostępne i użytkownikom czytników ekranowych są przedstawiane jako linki bez jakiejkolwiek treści! Dlatego też jest niezwykle ważne, żeby wszystkie elementy interaktywne miały tekstową alternatywę.

    Można też wspomnieć, że te same linki były umieszczone w sekcji (nomen omen bez nagłówka), tworząc zbiór linków. A zbiory w HTML-u oznacza się przy pomocy list (ul lub ol). A jeśli już przy listach jesteśmy, to wydaje mi się, że przy omawianiu różnic pomiędzy ul i ol od rodzaju punktora (choć jest to, rzecz jasna, najbardziej widoczna różnica) ważniejszy jest fakt, że listę ol wykorzystuje się wtedy, gdy kolejność punktów listy ma znaczenie.

Tym samym w kursie kończy się omawianie HTML-a (zdecydowanie za krótko!) i rozpoczyna omawianie CSS-a.

Dzień 3.

  • Na samym początku tego dnia pojawiła się informacja, że przeglądarki mają takie same arkusze domyślnych stylów i istnieje standard to wyznaczający. Nie jest to prawda. Taki standard nigdy nie istniał, a jedyne próby ustandaryzowania opierały się o inżynierię wsteczną:

    This style sheet describes the typical formatting of all HTML 4 elements based on extensive research into current UA practice. Developers are encouraged to use it as a default style sheet in their implementations.

    [Ten arkusz stylów opisuje typowe formatowanie wszystkich elementów HTML 4 w oparciu o długotrwałe badania obecnych praktyk przeglądarek. Developerzy są zachęcani, aby używać go jako domyślnego arkusza stylów w swoich implementacjach.]

    O wiele dokładniejsze zasady renderowania elementów znajdują się w specyfikacji HTML, ale one również mają wyłącznie charakter informacyjny:

    User agents are not required to present HTML documents in any particular way.

    [Przeglądarki nie są zobowiązane do prezentowania dokumentów HTML w żaden określony sposób.]

    Co więcej dodatkowe domyślne style rozrzucone są także po różnych specyfikacjach CSS, wciąż jednak będąc tylko sugestią:

    This appendix is informative.

    Potential additions to the base style sheet […].

    [Ten załącznik pełni rolę informacyjną.

    Potencjalne dodatki do bazowego arkusza stylów […].]

    Tym samym domyślne style w dużej mierze zależałyby od tego, jaki zakres funkcji CSS dana przeglądarka zaimplementowała, co samo w sobie sugeruje, że istnieją pewne różnice.

    O tym, że nie istnieją spójne domyślne style między przeglądarkami, można się także przekonać empirycznie. Nie na darmo projekty typu normalize.css czy reset.css są tak popularne. A przecież ich zadaniem jest usuwanie domyślnych stylów przeglądarek lub ich ujednolicanie (normalizacja) pomiędzy różnymi przeglądarkami.

    Przy okazji warto też sprostować informację, jakoby Chrome opierał się na WebKicie. To nieprawda, bo od prawie 6 lat Chrome opiera się o Blink.

  • Pojawiają się też pewne zawirowania terminologiczne, które warto byłoby wyjaśnić.

    Jako przykład kaskady został podany fakt, że selektor .red jest ważniejszy od selektora p. To jak najbardziej prawda, ale najczęściej kaskadę rozumie się jako ważność stylów ze względu na ich źródło. W przypadku selektora klas na scenę wkracza inny mechanizm, specyficzność selektorów. Choć co prawda jest to jeden z elementów kaskady, jest on na tyle rozbudowany i mający na tyle duże znaczenie przy wybieraniu stylów przez przeglądarki, że warto go wyraźnie wspomnieć. Specyficzność jest bowiem podstawą większości dobrych praktyk w CSS.

    Pojawił się też termin pierwszego młodszego brata. Prawdę mówiąc jest to bardzo dziwne tłumaczenie, z którym pierwszy raz się spotykam. Najczęściej selektor next-sibling jest tłumaczony jako – po prostu – selektor brata. Z kolei selektor subsequent-sibling można przetłumaczyć jako selektor rodzeństwa. Nie ma potrzeby wprowadzać słowa „młodszy”, które – moim zdaniem – wprowadza pewien chaos terminologiczny.

  • Wypada też wspomnieć o pokazanym w tym dniu selektorze identyfikatora, przy którym nie wspomniano, dlaczego jest to bardzo zła praktyka, a jedynie powiedziano, że nie jest zbyt popularny.

  • W omówieniu gramatyki CSS-a, która pojawia się w tym dniu, pojawia się informacja, że selektory są zależne od wielkości liter i jako przykład podany jest selektor P, który ma jakoby nie działać, ponieważ w HTML-u znaczniki piszemy małymi literami. Jak już zauważyłem przy pierwszym dniu, nie jest to prawda. HTML zezwala na dowolny zapis znaczników, co sprawia, że html jest tak samo poprawny jak HtMl. Z kolei specyfikacja CSS o wielkości znaków mówi następująco:

    All Selectors syntax is case-insensitive within the ASCII range (i.e. [a-z] and [A-Z] are equivalent), except for the parts that are not under the control of Selectors: specifically, the case-sensitivity of document language element names, attribute names, and attribute values depends on the document language.

    For example, in HTML, element and attribute names are ASCII case-insensitive, but in XML, they are case-sensitive.

    [Składnia wszystkich selektorów jest niezależna od wielkości znaków w zakresie ASCII (np. [a-z] i [A-Z] są równoważne), poza fragmentami, które nie są pod kontrolą selektorów: przede wszystkim wielkość znaków nazw elementów w języku dokumentu, nazwy atrybutów lub wartości atrybutów zależne od języku dokumentu.

    Na przykład, w HTML-u nazwy elementów i atrybutów są niezależne od wielkości znaków ASCII, ale w XML są zależne od wielkości znaków.]

  • Warto też wspomnieć o resecie zaproponowanym w kursie, a opartym na selektorze uniwersalnym – *. Jest to sposób działający, ale niekoniecznie polecany. Nie bez powodu praktycznie wszystkie używane szeroko resety wymieniają wszystkie znaczniki, którym chcemy wyzerować marginesy. Selektor uniwersalny bowiem usuwa marginesy z absolutnie wszystkich elementów, a więc także z wnętrza pól formularzy, przycisków itp., czego zazwyczaj nie chcemy robić. Często bowiem tym elementom pozostawiamy domyślny wygląd, a bez domyślnych marginesów wydają się „zapadnięte”:

    vs

  • Padło też stwierdzenie, że najlepiej dołączać zwykle jeden arkusz stylów. I choć można się do tego przychylić, pokazałem już w tym artykule, dlaczego możemy chcieć posyłać wiele małych arkuszy stylów, opisujących wyłącznie poszczególne fragmenty strony. Dodatkowo warto wziąć pod uwagę, że obecnie coraz większa część ruchu sieciowego jest przesyłana protokołem HTTP/2 (a trwają już prace nad protokołem HTTP/3!), który pozwala wprowadzać optymalizacje przesyłu zasobów. W połączeniu z technologiami, takimi jak Service Worker, złota zasada jednego arkusza powoli przestaje być złota.

Z racji braku dostatecznej ilości czasu zadecydowałem, że kolejnych dni nie będę oglądał w całości, ale będę wybierał jedynie kilka lekcji (głównie teoretycznych), a w dniach projektowych – po prostu spoglądał na kod projektów. Wydaje mi się, że materiału z trzech pierwszych dni i tak jest już wystarczająco, a sama teoria z kolejnych dni pozwoli mi wyciągnąć wnioski co do merytoryczności kursu.

Dzień 4.

  • W materiale poświęconym kolorom w CSS-ie zostały pokazane 4 podstawowe sposoby definiowania kolorów. Niemniej zostały pokazane w swoich starych formach. Od pewnego czasu bowiem funkcja rgb() jest tożsama z funkcją rgba():

    Also for legacy reasons, an rgba() function also exists, with an identical grammar and behavior to rgb().

    [Dodatkowo ze względów na kompatybilność wsteczną, istnieje również funkcja rgba(), o identycznej gramatyce i zachowaniu jak rgb().]

    Dodatkowo format heksadecymalny również doczekał się możliwości zapisywania przezroczystości:

    8 digits
    The first 6 digits are interpreted identically to the 6-digit notation. The last pair of digits, interpreted as a hexadecimal number, specifies the alpha channel of the color, where 00 represents a fully transparent color and ff represent a fully opaque color […].
    4 digits
    This is a shorter variant of the 8-digit notation, „expanded” in the same way as the 3-digit notation is. […]
    [8 cyfr
    Sześć pierwszych cyfr jest interpretowanych identycznie do sześciocyfrowej notacji. Ostatnia para cyfr, interpretowana jako liczba szesnastkowa, określa kanał alfa koloru, gdzie 00 oznacza całkowicie przezroczysty kolor, a ff całkowicie nieprzezroczysty kolor […].
    4 cyfry
    To krótszy wariant ośmiocyfrowej notacji, „rozwijany” w taki sam sposób, jak trzycyfrowa notacja. […]]

    Warto przy okazji wspomnieć, że CSS przewiduje o wiele więcej systemów zapisu kolorów, jak np. HSL, HWB czy kolory niezależne od urządzenia. Wypada wspomnieć o tych systemach zapisu kolorów choćby dlatego, że RGB niekoniecznie jest najbardziej intuicyjny.

  • Przy definiowaniu jednostki em pojawiła się definicja, że jest to 100% rodzica. Definicja ta jest błędna, bo em definiowane jest na podstawie rozmiaru tekstu:

    Equal to the computed value of the font-size property of the element on which it is used.

    [[Jednostka] równa obliczonej wartości własności font-size elementu, na którym jest użyta.]

    Zauważmy, że em jest definiowany nie względem rodzica, ale względem elementu, który stylujemy. Ma to sens w przypadku używania tej jednostki do własności innych niż rozmiar tekstu (np. width, height). Jedyne przypadki, kiedy em w rzeczywistości odwołuje się do wielkości czcionki u rodzica, zachodzą wtedy, gdy na stylowanym elemencie nie ma własności font-size i jej wartość jest dziedziczona lub gdy używamy em właśnie do ustawienia wartości font-size.

  • Pojawia się też przykład ze zmianą wielkości czcionki dla html na 10px. Ten problem był już poruszony w tym artykule, ale powtórzę raz jeszcze: ustawianie domyślnej wielkości czcionki uznać można za złą praktyką. Głównie z powodu tego, że część użytkowników może ustawić sobie inny rozmiar czcionki niż domyślny, co wówczas oznacza, że możemy nadpisać ustawienia użytkownika. Z podobnego powodu część stron stosuje czcionki systemowe.

    Pomijam już fakt, że 10px jest poniżej progu czytelności, więc tego typu ustawienie czcionki pomaga wyłącznie w… obliczaniu wartości rem/em dla pozostałych elementów. Równocześnie jednak wymusza nadanie czcionki praktycznie wszystkim innym elementom, inaczej tekst na stronie może być nieczytelny.

Dzień 5.

  • W tym dniu pada informacja, że przeglądarki używają pewnych domyślnych czcionek dla wartości font-family: serif i font-size: sans-serif. Jako czcionka szeryfowa zostaje wymieniony Times New Roman, a jako bezszeryfowe – Arial i Tahoma. Prawda jest jednak taka, że żadna z tych czcionek nie jest domyślnie zainstalowana na Linuksie (mówię tutaj o dystrybucjach Ubuntowych) i trzeba je dodatkowo zainstalować. To tylko pokazuje, że w przypadku webdevelopmentu nie da się praktycznie nic przewidzieć czy założyć, bo zawsze znajdzie się część użytkowników, którzy nie wpiszą się w nasze przewidywania. Stąd też powstał pomysł wspomniany już wyżej – wykorzystania domyślnych czcionek systemowych.

  • Przy omawianiu dołączania czcionek przy pomocy Google Fonts prowadzący zasugerował, że nie trzeba się zbytnio martwić czasem pobierania arkusza stylów z czcionkami. Nie zgodziłbym się z tym. Obecnie wydajność jest jednym z najważniejszych wyznaczników jakości strony, a także staje się częścią dyskusji o etyce programistycznej. Wypada od samego początku nieustannie powtarzać, jak ważny to jest temat i jak można sprawić, żeby strona była jak najbardziej wydajna. Dlatego sugerowanie, że jeden niekrytyczny arkusz stylów więcej nie szkodzi niekoniecznie jest właściwym podejściem. Zwłaszcza, że obecnie zapewnienie wydajności wczytywania czcionek wcale nie jest takie trudne. Tym bardziej dzięki najnowszemu font-display

Dzień 6.

  • W tym dniu pojawił się temat domyślnych wartości nadawanych wszystkim elementom HTML, gdy nie istnieją żadne style (również te domyślne przeglądarki). W tym kontekście wspomniano o DOM. Niemniej nie jest to do końca precyzyjna informacja, ponieważ DOM stanowi jedynie reprezentację kodu HTML. Kod CSS jest z kolei reprezentowany przez CSSOM. Wydaje mi się, że o tym rozróżnieniu wypadałoby wspomnieć już teraz, tym bardziej, że przeglądarka musi stworzyć obydwa drzewa w celu wyrenderowania strony.

  • Po raz kolejny przewinął się też temat zmiany domyślnej wielkości czcionki. Zostało tu powiedziane, że domyślna wartość dla własności font-size wynosi medium, czyli w praktyce 16px. To stwierdzenie nie jest jednak oparte na żadnym standardzie. Oficjalna definicja wielkości medium brzmi:

    An <absolute-size> keyword refers to an entry in a table of font sizes computed and kept by the user agent.

    [Słowo kluczowe <absolute-size> odnosi się do wpisu w tabeli wielkości czcionek obliczonych i przechowywanych przez przeglądarkę.]

    Rzeczona tabelka wielkości określa wyłącznie przy pomocy ich relacji do wartości medium, które jest uznane za wartość bazową (1). Dokładnej wartości liczbowej jednak nie podano i na próżno jej szukać w specyfikacji. Tym samym fakt, że większość przeglądarek dla wartości medium przyjmuje 16px, jest jedynie nieoficjalną (acz powszechną) praktyką. Przeglądarka, która ustawiałaby w tym miejscu inną wielkość (np. 20px), wciąż byłaby zgodna ze standardem i nie można byłoby mieć do niej pretensji, że nasze obliczenia spełzły na niczym. Dlatego – co powtarzam po raz kolejny w tym artykule – uważam, że powinno się myśleć relacjami i proporcjami poszczególnych elementów, a nie ich sztywnymi wymiarami.

  • Specyficzność selektorów (chociaż ta nazwa tak naprawdę nie pada!) została wyjaśniona na podstawie klasyfikacji medalowej. Choć co prawda sposób taki jest faktycznie niezwykle praktyczny, zabrakło tutaj pewnych teoretycznych podstaw. Zgodnie ze specyfikacją bowiem specyficzność opisuje się przy pomocy 4 wartości liczbowych.

    Ogólnie mam wrażenie, że w tym kursie bardzo duży nacisk kładzie się na praktykę, rozumianą jako stworzenie działającej strony WWW. Ba, w pewnym momencie pada wręcz stwierdzenie, że wiedza teoretyczna stanowi niejako dodatek do tej praktycznej. Trudno mi się z tym zgodzić, zwłaszcza, jeśli zaczniemy analizować, co rozumie się pod pojęciem „działającej strony WWW”. Jeśli bierzemy pod uwagę wyłącznie fakt, że wyświetla się poprawnie w graficznych przeglądarkach, to tak naprawdę skupiamy się wyłącznie na aspekcie prezentacji. Dlaczego może być to podejście szkodliwe, pisałem już wielokrotnie i zwracałem na to uwagę, również na początku tego artykułu.

    Oczywiście nie oznacza to, że praktyka nie jest ważna. Jest, jak najbardziej – w końcu dzięki niej zarabiamy. Niemniej „luźne” podejście do teorii może powodować pewne luki w wiedzy, które z kolei przekładać się mogą na obniżenie dostępności czy użyteczności tworzonych stron WWW.

  • W tym dniu został też stworzony podstawowy reset. Wydaje mi się jednak, że w tym miejscu powinna być też wyjaśniona różnica pomiędzy resetem i normalizacją – zwłaszcza, że to drugie podejście jest o wiele popularniejsze obecnie. Warto też zwrócić uwagę na sposób wykorzystania własności box-sizing, który nieco odbiega od obecnie przyjętej najlepszej praktyki.

  • I na koniec coś, co mocno drażni moje polonistyczne ucho: nie ma czegoś takiego jak styli. Tylko i wyłącznie stylów.

Dzień 7.

  • Wśród elementów blokowych została wymieniona tabela oraz li. Obydwa te elementy nie są elementami blokowymi.

    Tabela ma swój własny specyficzny sposób wyświetlania, display: table. Dodatkowo okazuje się, że jest on istotny dla właściwego przedstawiania tabeli w drzewku dostępności. Stąd też blokowa tabela jest niedostępna i nie powinno się jej wykorzystywać.

    Elementy li również mają swój własny sposób wyświetlania – display: list-item. Dzięki temu zachowują się jak elementy blokowe, ale można im dodatkowo nadać punktor.

    Problemem jest tutaj nieprecyzyjna terminologia. Jeśli za elementy blokowe uznajemy elementy z display: block;, wówczas zarówno table, jak i li, takimi elementami nie są. Jeśli jednak za elementy blokowe uznajemy elementy, które tworzą wokół siebie przejścia do nowej linii, wówczas table i li można uznać za blokowe. Niemniej jest to terminologia dość myląca. Żeby jeszcze bardziej sprawę zagmatwać, specyfikacja CSS Display Module wprowadza zewnętrzne i wewnętrzne tryby wyświetlania elementu. To jeszcze bardziej spycha na margines dawny podział elementów, proponowany w HTML 4.01.

    Tego typu podział jest dobry do tłumaczenia podstawowych różnic pomiędzy tym, jak wyświetla się div i span, niemniej jednak w kontekcie omawiania własności display wprowadza jedynie niepotrzebny zamęt i niejasność.

  • W tym dniu była też poruszana kwestia tzw. margin collapsing. Niemniej była ona poruszana od tej najbardziej praktycznej strony i zabrakło mi nieco teoretycznej podwaliny.

Dzień 8.

To dzień poświęcony na część praktyczną, składającą się z kilku małych projektów. Wybrałem jeden z nich i rzuciłem okiem na kod.

  • W projekcie występuje nawigacja stworzona bez listy (nav > a). Niemniej w jednej z kolejnych lekcji w tym dniu jest omawiany alternatywny sposób tworzenia menu. Pomyślałem zatem, że być może najpierw stworzono tego typu menu, a następnie pokazano, czemu nie jest to najlepszy sposób. Jednak nie, gdyż w rzeczonej lekcji pada stwierdzenie, że menu bez listy to nic złego i jest zgodne ze specyfikacją…

    Owszem, jest to jak najbardziej zgodne ze specyfikacją, ale warto zauważyć, że przykłady w specyfikacji niemal zawsze zawierają listę w nawigacji. Jedyny przykład bez listy jest mocno specyficzny i przedstawia fragment tekstu, w którym linki do poszczególnych części strony są tak naprawdę częścią narracji. Nie jest to zatem menu, a bardzo specyficzny twór. Co więcej, najlepszą obecnie praktyką jest umieszczanie menu nawigacyjnego w liście. A łamanie dobrych praktyk – wyrosłych na kanwie wieloletnich badań i dowodów empirycznych – jest jak najbardziej złe.

  • nav a.reservation:hover – tego typu selektory są niezgodne z najlepszymi praktykami w branży – i to od wielu, wielu lat. Rozumiem, czemu prowadzący nie chciał wprowadzać całkowicie płaskiej specyficzności opartej na klasach, niemniej zapis typu element.klasa jest praktycznie niespotykany w nowoczesnym kodzie i nie ma sensownego uzasadnienia. Ten selektor bez problemu powinien wyglądać tak: nav .reservation:hover. A jeśli ta klasa występuje wyłącznie w menu, to .reservation:hover. Podnoszenie specyficzności bez powodu jest samo w sobie złą praktyką.

  • Dziwi mnie też fakt, że cały układ strony został stworzony przy pomocy display: inline-block. Owszem, jak najbardziej się da (co ten przykład zresztą udowadnia), ale nie jest to najprzyjemniejszy i najłatwiejszy w utrzymaniu sposób. Mamy rok 2019 i standardem jest obecnie flexbox, wypierany już w niektórych obszarach przez jeszcze bardziej zaawansowany CSS Grid. Obydwa rozwiązania mają naprawdę dobre wsparcie przeglądarek (95% dla flexboxa i 88% dla CSS Grida) i obydwa zachowują się o wiele logiczniej niż display: inline-block. A dodatkowo ładnie się degradują, po prostu ustawiając wszystkie elementy strony pod sobą, gdy przeglądarka ich nie wspiera.

Dzień 9.

Nie bardzo rozumiem, czemu jako podstawowe narzędzie do tworzenia layoutów stron, które jest tłumaczone w kursie dla najbardziej początkujących, wybrano float. Ta własność CSS nigdy nie miała służyć do tworzenia layoutów, a jedynie do tworzenia prostych efektów opływania (jak np. obrazek opływany przez tekst). Fakt, że przez długie lata była używana w tym celu, wynika wyłącznie z tego, że nie istniała inna metoda. Nie istniał wówczas ani flexbox, ani CSS Grid. Tym samym webdeveloperzy byli zmuszeni używać floattak samo jak jeszcze wcześniej tabel.

Obecnie de facto standardem w branży jest flexbox. Stworzono go od podstaw właśnie po to, by służył tworzeniu layoutów stron. Dlatego też nie cierpi na dziwne przypadłości float (wyciąganie elementów z obiegu, potrzeba używania clear/overflow itd.) i jest o wiele bardziej logiczny. Nie ma potrzeby używać prehistorycznego sposobu tworzenia stron WWW.

Opływanie można dzisiaj bez problemu zastąpić lepszymi rozwiązaniami, takimi jak już wspomniane flexbox i CSS Grid, ale także m.in. układy wielokolumnowe. Nie ma absolutnie żadnego powodu, by uczyć float jako sposobu tworzenia layoutów.

Dzień 10.

To dzień poświęcony na część praktyczną, składającą się z małego projektu. Rzuciłem okiem na kod.

  • Gotowy projekt jest doskonałym przykładem, dlaczego float został już praktycznie wyparty przez flexboksa czy grida: niemal każdy element strony ma dołączonego clearfixa, żeby układ strony się nie rozpadł. Nie bardzo widzę sens walki z zardzewiałym narzędziem na każdym kroku, podczas gdy na wyciągnięcie ręki dostępne są o wiele lepsze, pozłacane narzędzia.

  • Na stronie zastosowany jest algorytm outline’u i każdy artykuł ma nagłówek h1. Temat ten był już poruszany kilkukrotnie w tym artykule, więc jedynie przypomnę: to sprawia, że strona staje się niedostępna. Dla użytkowników czytników ekranowych znaczy to mniej więcej tyle, że na stronie jest kilka głównych nagłówków (czyli w teorii opisujących zawartość całej strony).

  • Pojawia się też znany wzorzec listy z danymi kontaktowymi z ikonkami:

    <ul>
    	<li><i class="fas fa-envelope"></i>kontakt@mojemeil.pl</li>
    	[…]
    </ul>

    W tym kontekście ikonka niesie informację o tym, jakiego typu dana kontaktowa po niej następuje, stąd wypadałoby, by miała tekstową alternatywę. Dodatkowo można się pokusić o przedstawienie tego jako address > dl.

Dzień 11.

W tym dniu poruszony został temat własności position z CSS. Tak jak i w pozostałej części kursu, pokazana została przede wszystkim przy pomocy praktycznych przykładów – co się jak najbardziej chwali. Nie mam praktycznie żadnych zastrzeżeń co do tego dnia, a sama własność została wyczerpująco przedstawiona.

Jedyna rzecz, jakiej brakowało w tym dniu, to omówienie piątej wartości position, czyli najnowszego position: sticky. Jest to wartość zachowująca się jak połączenie wartości relative i fixed. Gdy okno przeglądarki zostaje przewinięte do elementu z position: sticky, zostaje on przyklejony do odpowiedniej krawędzi okna i przewija się dalej wraz ze stroną. MDN ma bardzo fajny przykład.

Dzień 12.

Pozwolę sobie sparafrazować klasyka: jakie tło jest, każdy widzi. Ot, szybkie i praktyczne omówienie własności związanych z tłem elementów strony WWW. Jedyne zastrzeżenie, jakie można mieć, to fakt, że samemu tłu został poświęcony cały, osobny dzień. W porównaniu do tematów poruszanych w trakcie innych dni, wydaje się to czymś zupełnie innego kalibru.

Dzień 13.

  • Ten dzień był poświęcony responsywności. Niemniej osobiście uważam, że temat ten został bardzo spłycony. Poruszono bowiem wyłącznie kwestię różnicy pomiędzy urządzeniami desktopowymi (rozumianymi jako urządzenia posiadające duży ekran, myszkę i klawiaturę) a urządzeniami mobilnymi, czy jeszcze wężej – smartphone’ami (rozumianymi jako urządzenia posiadające mały ekran i obsługę dotykiem). A przecież zakres możliwych urządzeń, na których możemy oglądać strony internetowe, jest wielokrotnie większy. Co z hybrydami, laptopami z ekranami dotykowymi? Co z urządzeniami mobilnymi z dołączanymi klawiaturami? Co z urządzeniami sterowanymi głosem (jak choćby urządzenia pokroju Google Glass)? Co z przeglądarkami na konsolach do gier? Co ze wspomnianymi już w tym artykule inteligentnymi zegarkami? Co z przeglądarkami w smart TV? Co z komputerami z monitorami 4k? Co z całym spektrum innych urządzeń, o których pewnie nawet nigdy nie słyszałem?

    Jeśli zawężamy problematykę responsywności do prostej opozycji urządzeń desktopowych i urządzeń mobilnych, wykluczamy całe grupy różnych użytkowników. Pojęcie responsywności powinno być rozumiane jak najszerzej, by włączyć w to jak najwięcej użytkowników. Bo tak naprawdę responsywny design jest designem inkluzywnym i jako taki powinniśmy go traktować. Stąd lepiej jest brać jako czynnik pod uwagę nie tylko ekran, co jest bardzo dobrym pierwszym krokiem do stworzenia bardziej dostępnych stron i aplikacji internetowych.

    Dlatego rownocześnie lubię zaznaczać, że podejście mobile first (najpierw mobilne urządzenia) ma według mnie złą nazwę. Sugeruje bowiem, że piszemy pod konkretny rodzaj urządzenia, a przecież Sieć jest niezależna od urządzenia. Stąd warto moim zdaniem to podejście nazywać content first (najpierw treść). Bo przecież o to chodzi w podejściu mobile first: stworzenie najprostszego layoutu, który w czytelny sposób prezentować będzie konkretną treść. I dopiero, gdy urządzenie na to pozwala, to do strony dokładane są kolejne elementy, ulepszające niejako najprostszą wersję layoutu – zupełnie jak w Progressive Enhancement. I choć obecnie content first wyewoluowało do osobnej gałęzi designu, to stworzenie spójnego podejścia, łączącego cechy mobile first i obecnie rozumianego content first wydaje się eliminować sporą część problemów związanych z dostosowywaniem strony do jak najszerszej grupy użytkowników.

  • Nie zgodziłbym się też z tym, że media queries są najlepszym sposobem robienia responsywności. W dzisiejszych czasach, gdy mamy tak szeroki zakres wszelakich urządzeń i sposobów przeglądania Sieci, coraz częściej o wiele lepiej jest myśleć proporcjami i relacjami pomiędzy poszczególnymi elementami strony niż wymiarami jako takimi. Dodatkowo, w dobie IWD i technologii pokroju flexboxa czy CSS Grida, możliwe jest budowanie faktycznie responsywnych stron bez konieczności używania media queries. Te z kolei zostają tak naprawdę wyłącznie do tworzenia prawdziwych breakpointów, czyli reguł dla elementów, które od pewnej rozdzielczości wyglądają źle i nie da się tego naprawić narzędziami dostępnymi choćby we flexboxie/gridzie (jak zawijanie siatki do nowych linii).

    Owszem, każdy ma wolność wyboru i może robić, jak chce, ale byłbym ostrożny z mówieniem, że liczy się wyłącznie efekt końcowy. Zwłaszcza, że w tym wypadku po raz kolejny jest to wyłącznie prezentacja. Jak już zostało zauważone w tym artykule, często CSS może zmieniać semantykę elementów (np. zmiana display dla tabel), a równocześnie – technologia asystująca najczęściej czyta stronę w kolejności, w jakiej elementy znajdują się w DOM, nie zaś tak, jak jest faktycznie wyświetlana. Stąd podejście do problemu jest często tak samo ważne, jak ostateczny efekt końcowy.

Dni 14. i 15.

Z racji tego, że w tych dniach powstaje ostatni projekt w kursie, pozwoliłem sobie je połączyć razem i po prostu spojrzeć na ostateczny projekt. Oto krótka garść uwag:

  • Zwracałem na to uwagę w tym artykule wielokrotnie, ale zwrócę raz jeszcze: hierarchia nagłówków powinna być budowana dla całej strony, nie dla każdej sekcji osobno. Zwłaszcza, że osoby z czytnikami ekranowymi wolą, gdy h1 opisuje wyłącznie witrynę/stronę. I dopóki algorytm outline’u nie zostanie zaimplementowany (a nie zanosi się na to), używanie h1 dla poszczególnych sekcji obniża dostępność strony. Inna rzecz, że wysoka popularność Internet Explorera 11 wśród użytkowników czytników ekranowych dodatkowo utrudni potencjalną adaptację nowego rozwiązania.

  • <h1>jestem Adam Kowalski</h1>
    <h2>web developer - freelancer</h2>

    I znów: taki zapis ma sens tylko w przypadku, gdy algorytm outline jest zaimplementowany i możemy wykorzystać znacznik hgroup do odizolowania nagłówka h2 od hierarchii treści na stronie (obecnie jest on traktowany przez przeglądarki tak samo jak div). Nie wnosi bowiem nic do niej, jest jedynie dookreśleniem treści nagłówka h1. Dlatego dopóki nie zostanie zaimplementowany algorytm outline’u, podtytułów nie należy robić na nagłówkach.

  • <div>
    	<img src="images/services1.png" alt="loga html js i css">
    	<h2>Jakiś nagłówek</h2>
    	<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Cum earum maiores dolores fugit, soluta? Sed repudiandae, fugit provident suscipit cum architecto asperiores, sequi obcaecati, alias sunt ea. Soluta, rerum, perspiciatis.</p>
    </div>

    Przy tego typu strukturze obrazek nie stanowi dodatkowej treści czy uzupełnienia tekstu będącego w jego pobliżu. Jest typowym ozdobnikiem dodanym ot tak, a informacja, że zawiera logo HTML, CSS i JS, jest całkowicie nieistotna. Dlatego tego typu obrazki powinny mieć pusty [alt].

    Dodatkowo ten div można z powodzeniem zamienić na section, gdyż posiada własny nagłówek.

  • <section>
    	<div>
    		<h1>Moje życiowe motto</h1>
    		<p class="text">Lorem ipsum dolor sit amet, consectetur adipisicing elit. Fuga id architecto harum sint at alias. </p>
    		<p class="author">Jan Nowak</p>
    	</div>
    </section>

    Tutaj z kolei mamy klasyczny przykład, w którym skupiamy się wyłącznie na prezentacji, z pominięciem semantyki konkretnego elementu. Od cytatów jest bowiem znacznik blockquote, który można połączyć z cite, by oznaczyć autora:

    <section>
    	<h2>Moje życiowe motto</h2>
    	<blockquote>
    		<p class="text">Lorem ipsum dolor sit amet, consectetur adipisicing elit. Fuga id architecto harum sint at alias.</p>
    		<p class="author"><cite>Jan Nowak</cite></p>
    	</blockquote>
    </section>

    W niektórych przypadkach można się nawet pokusić o bardziej rozbudowany kod cytatów.

  • <section class="hobby clearfix">
    	<h1>W wolnym czasie uwielbiam</h1>
    	<div class="item">
    		<p>Chodzić po górach</p>
    	</div>
    	<div class="item">
    		<p>Patrzeć wysoko</p>
    	</div>
    	<div class="item">
    		<p>Zmieniać świat</p>
    	</div>
    	<div class="item">
    		<p>Jeść owoce i warzywa</p>
    	</div>
    </section>

    Tutaj wręcz zbrodnią jest nie użyć listy, gdyż jest to wręcz książkowy przykład jej użycia: wyliczenie naszych zainteresowań. Ten kod o wiele lepiej wyglądałby jako:

    <section class="hobby clearfix">
    	<h2>W wolnym czasie uwielbiam</h2>
    
    	<ul>
    		<li class="item">
    			<p>Chodzić po górach</p>
    		</li>
    		<li class="item">
    			<p>Patrzeć wysoko</p>
    		</li>
    		<li class="item">
    			<p>Zmieniać świat</p>
    		</li>
    		<li class="item">
    			<p>Jeść owoce i warzywa</p>
    		</li>
    	</ul>
    </section>
  • No i na koniec nieśmiertelny klasyk: formularz bez label.

I tym sposobem dobrnęliśmy do końca kursu!

I żeby nie było, że oszukuję czy coś – posiadam oficjalny certfikat ukończenia kursu.

Podsumowanie

Kurs Samuraja bez wątpienia jest kursem, w którym główny nacisk położono na praktykę i to, jak wykorzystać nowo zdobytą wiedzę do tworzenia działających stron WWW. To, co jest największą zaletą tego kursu, jest też równocześnie jego największym problemem. Nacisk położony na praktykę jest bowiem za duży, a lekceważące podejście do teorii bardzo łatwo przełożyć może się na tworzenie mało dostępnych i mało użytecznych doświadczeń dla użytkowników. Niniejszy artykuł chyba właśnie to pokazuje: ową mocną dysproporcję pomiędzy praktyką a teorią, skutkującą – moim zdaniem – umocnieniem współczesnego trendu tworzenia stron WWW głównie po to, by wyglądały. Zbyt dużo tutaj skoro działa, to działa i za mało refleksji nad podstawami i potrzebą dostosowania swojego sposobu myślenia do tak dynamicznego środowiska, jakim jest Sieć. Projektowanie i tworzenie dla Internetu bowiem nie jest zadaniem prostym, gdyż tutaj wszystkie założenia i przewidywania są błędne. I bez odpowiedniego podłoża teoretycznego zbyt łatwo nadziać się na minę.

Dlatego też nie mogę polecić kursu Samuraja.

46 myśli na temat “Kurs Web developer od podstaw w 15 dni od Samuraja Programowania”

  1. To ja w sumie nie rozumiem. Jakie kursy polecasz ?
    Bo każdy kurs widzę sprawdzasz i zawsze coś tam skrytykujesz :D.

    Pozdrawiam
    Piotr

    1. No właśnie w tym problem, że żadnych 😉 Polski rynek kursów wydaje się w tej chwili jeszcze po prostu niedojrzały i nie dobił do poziomu kursów zagranicznych. Na szczęście z roku na rok jest coraz lepiej.

      O dziwo najbardziej z polskich kursów przypadł mi do głowy kurs ES6 od Strefy Kursów, który też opisywałem. Bardzo fajne materiały miało Kodu.je (np. kurs flexboxa), ale sama inicjatywa umarła – a szkoda. Na YT w siłę rośnie teraz Hello, Roman, ale ten z kolei nie ma typowych kursów. Jest też kanał Overment i po szybkim rzucie oka wydaje się porządny.

          1. Niestety, nie znam, więc nic nie myślę. Ale przeglądając listę nauczycieli, widać naprawdę mocne nazwiska: Crockford, Larkin, Sutton, Simpson, Weyl, You… Jeśli faktycznie są tam ich kursy, to z jakością raczej nie powinno być problemów.

    2. Zgadzam się z tobą, Ja zaczynam co prawda swoją przygodę z programowaniem i uczę się z kursów Samuraja. Jest świetnym prowadzącym, potrafi przekazać wiedzę w ciekawy i interesujący sposób. Facet ma talent, a krytykowanie nic nie wnosi. Można ewentualnie napisać do prowadzącego dany kurs na co warto zwrócić uwagę nowym adeptom, tyle 🙂

      1. Dlaczego nic nie wnosi? Jeśli krytyka jest oparta na merytorycznych, obiektywnych (lub przynajmniej intersubiektywnych) argumentach, to dochodzi do stworzenia sensownego dyskursu. Dzięki temu wypracować można nową jakość.

        Brak działania z kolei w żaden sposób nie zmienia zastanej rzeczywistości i nie wpływa w żaden sposób na jakość tego typu kursów.

        1. Rozumiem że skoro mówisz że jednak taka krytyka wpływa na kurs to wysłałeś ten tekst do autora? Jeżeli nie, to nic nie zmieniasz a tylko oceniasz co na nic nie wpływa.

          1. Zrobiłeś dokładnie to samo – oceniłeś.

            Ja tych tekstów nie piszę tylko dla autorów kursów, ale także – a raczej: przede wszystkim – kursantów. Mają dzięki temu szansę skonfrontować opinię autora kursu z moją opinią czy też bezpośrednio z przytaczanymi standardami sieciowymi. A autorzy kursów prędzej czy później na te teksty i tak trafią, gdy wejdą do szerszego obiegu. Tak już nieraz się stało z tekstami tutaj.

      2. Krytykowanie, o ile jest konstruktywne (a w tym wypadku to wręcz idealny przykład) wnosi bardzo dużo. Stawiam pierwsze kroki we frontendzie i obecnie przerabiam kurs Samuraja. Wczoraj Tomek podlinkował tą recenzję komuś na grupie na facebooku. Przeczytałem i się załamałem ;D. Tyle wypunktowanych błędów i nieścisłości, odnośniki do dokumentacji i fachowych artykułów, „Ta technika już od 5 lat jest dobrą praktyką a tamta od 3”, OMG. Myślę sobie, cholera ten cały frontend to nie taka łatwa sprawa. Ale o dziwo ten artykuł mnie niesamowicie zainspirował do wnikania w to wszystko jeszcze głębiej. Dzięki Tomek!

  2. Świetny artykuł, niby recenzja, a sporo można się nauczyć. Wkradła się drobna literówka/niedopatrzenie: ‚Kod CSS jest z kolei reprezentowany przez . ‚

  3. Zauważyłem, że w zagranicznych kursach również brnie się przez float, a dopiero potem prezentuje flexboxa. Przykładowo Cold Steele robi to w identyczny sposób, potem nawet uczy starszej wersji bootstrapa i tłumaczy flexboxa przy okazji bootstrapa 4.
    Również ukończyłem kurs samuraja, a raczej dwa, bo także część drugą: Frontend zaawansowany – może i tu byś zrobił jakąś recenzję?
    Sposób przekazywania wiedzy przez Samuraja przypadł mi osobiście do gustu i sporo rzeczy się wyjaśniło, niemniej taka recenzja jak Twoja pokazuje dobitnie jak wiele jeszcze trzeba się douczyć, a i część wiedzy skorygować.
    Kursy Samuraja, a także ten od Cold’a Steel są polecane na flynerd.pl i tak na nie trafiłem. Obecnie The Complete 2019 Web Development Bootcamp jest numerem jeden wśród polecanych, ale nie miałem z nim styczności.
    Dzięki za tę recenzję, a szczególnie za odnośniki.

  4. ciekawa recenzja ale przyczepilbym sie do jednej rzeczy… krytykujesz zaa windowizacę ale wg mnie i tego co czytam to jest to kurs programowania webowego, a nie kurs obsługi edytora… jak ktoś nie zna edytorów to wg mnie powinien sobie poszukać info o tym sam, w sieci jest mnóstwo informacji. Ja bym wspomniał tylko np. o motepad++, vsc i webstormie z info o licencjach dla studentow i tyle, sorry ale jak ktoś chce programować a nie potrafi zainstalować i ustawić edytora to chyba cienki z niego informatyk 🙂

  5. Panie Tomaszu, sledzd Pana od dawna i w polskim internetowym IT jest Pan dla niejednej osoby autorytetem. Chcialbym zapytać o jedną rzecz mianowicie, po co uczyć od razu kogoś o dostępności stron na czytnikach ekranowych oraz dlaczego jest Pan aż takim fanatykiem (w pozytywnym tego słowa znaczeniu) dostępności. Bardzo często w Pana postach można zauważyć zwracanie na to uwagi.
    Pozdrawiam

    1. Po pierwsze, żaden tam pan ze mnie – Comandeer, względnie Tomek 😉

      Co do tego fanatyzmu: prawdopodobnie dlatego, że sam mam spore problemy ze wzrokiem i powoli, acz nieubłaganie widzę coraz słabiej. Innymi słowy, jestem takim fanatykiem z mocno egoistycznych pobudek – i jest to paradoksalnie dość znane podejście w branży, nazywane samolubną dostępnością.

      A podstawowa dostępność dla takich czytników to po prostu dbanie o to, by kod był semantyczny, była odpowiednia struktura nagłówków i obrazki miały odpowiedni [alt]. Innymi słowy: pisanie wysokiej jakości kodu HTML. Dlatego nie widzę nic zdrożnego w uczeniu tego, zwłaszcza, że nie jest to jakaś nie wiadomo jaka nadmiarowa praca.

      1. Zawsze zastanawialiśmy się nad tym ze znajomym, dlaczego akurat to accessibility jest takie istotne dla Ciebie (okej, będę pisał na Ty :)). Ogólnie artykuł mega merytoryczny i jestem pod wrażeniem czasu włożonego w jego napisanie. Aktualnie Twój blog jest moim ulubionym i szkoda, że tak rzadko pojawiają się wpisy. Bardzo dziękuję za odpowiedź.

        Pozdrawiam serdecznie!

  6. Comandeer dzięki za ten artkuł. Sam oglądałem cały kurs Samuraja i wiadomo, nie jest on doskonały.
    Natomiast dziwi mnie, to że jest jakoby zarzut uczenia display inline-block, a nie flexbox. Owszem kto sie nauczy flexa, raczej nie będzie chciał się męczyć inline-block, lecz w drugiej części jego kursu jest i flexbox i Grid. A nauczenie kogoś starych praktyk jest jak najbardziej ok, zwłaszcza jak pójdzie się do roboty, gdzie trzeba utrzymywać stary kod, lub go przerobić. Wtedy łatwiej idzie zrozumieć. Choć wiadomo, świat frontu stale się rozwija, trzeba podążać za nowościami. Pozdrawiam 🙂

    1. Jak sam zauważasz: „w drugiej części kursu”. Powiem więcej: w drugim kursie z sześciu, które stanowią jego program. Pozwolę sobie zacytować samego Samuraja:

      Wybierz, czy chcesz zrobić ze mną całą ścieżkę nauki, czy może tylko pojedyńczy kurs.

      Dlatego też oceniam tylko pierwszy kurs, a w nim jest float.

      Utrzymywanie starego kodu jako argument dałoby się utrzymać (pun intended) tylko pod warunkiem, gdyby utrzymywanie starego kodu polegało na utrzymywaniu starego layoutu. A to akurat jest to, co najczęściej się w takich aplikacjach zmienia. W dobrze zrobionej aplikacji sam layout można wymienić bez żadnego problemu. Inna rzecz, że stary kod jest pisany z myślą o starszych przeglądarkach, co powoduje, że trzeba mieć o wiele szerszą wiedzę niż w przypadku pisania nowego kodu. Dlatego utrzymywanie starego kodu IMO nie jest najlepszym zadaniem dla juniora.

  7. Websamuraj jest najlepiej tłumaczącym w Polsce kwestie programowania. W świetle tego faktu wspomniane w recenzji sprawy to drobiazgi. Zwłaszcza,że mówimy o kursie dla początkujących, gdzie i tak nikt nie zagłębiał by się w większość z tych kwestii.
    Nie rozumiem tez tego czepiania się floatów?Przecież Samuraj wyraźnie i wielokrotnie we wszystkich kursach i nagraniach wideo na ten temat mówi, że to nie jest prawidłowa technika,że pokazuje to, żeby ludzie to znali bo mnóstwo osób to wykorzystuje. To jest potrzebna wiedza, bo potem trafiasz na projekt, gdzie ktoś tak budował stronę i nie wiesz o co chodzi. Co innego, gdyby w kursi uczył,że to super metoda i polecał. Piszesz też,że selektor uniwersalny * jest niepolecany, tymczasem uczą go w bardzo wielu kursach, między innymi w każdym projekcie z html/css na jednym z głównych bootcampów w Polsce. Więc może i nie polecany, ale przez kogo?
    Jeśli chodzi o JS, to samuraj na swoich bezpłatnych nagraniach na YT, oraz w kursie jako pierwszy mi super rozjaśnił pewne kwestie związane z closure czy hoistingiem. Może nie jest perfekcjonistą, ale jest świetnym nauczycielem.

    1. Podawanie nieprawdziwych informacji to drobiazg? Czy nauczyciel matematyki, który sprawia, że wszyscy z zapartym tchem słuchają go przez 45 minut, a informacje same się zapisują w mózgach, ale równocześnie uczy, że 2+2=5, jest dobrym nauczycielem? Nie da się odłączyć dydaktyki od merytoryki, bo w tym momencie tracimy esencję nauki – czyli przekazywanie pewnej, sprawdzonej wiedzy. Skoro zatem takiego nauczyciela matematyki prędzej nazwalibyśmy szarlatanem niż faktycznym nauczycielem, to czemu w stosunku do webdevu stosujemy takie podwójne standardy i przyzwalamy na głoszenie największych herezji? Skończmy w końcu przyzwalać na bylejakość, bo ostatecznie to my wszyscy oberwiemy rykoszetem, gdy Sieć stanie się niedostępna i nieużyteczna.

      Dodatkowo to, że te kursy są najlepsze, nie oznacza automatycznie, że są dobre. Porównujemy je bowiem wobec tego, co jest na polskim rynku, a – nie oszukujmy się – najlepiej nie jest. To paradoks skali ocen. Jeśli w klasie najlepszą oceną ze sprawdzianu jest 3, to fakt, że ktoś dostał 2 nie wygląda specjalnie źle. Niemniej jeśli przyłożymy te oceny do obiektywnej skali ocen (czyli szkolnej 1-6), to z przerażeniem stwierdzimy, że w tej klasie jest po prostu tragicznie. Zwłaszcza, jeśli w pozostałych klasach w szkole średnia z tego sprawdzianu wynosiła 5. A taka przecież sytuacja jest na rynku kursów, gdzie polskie są bardzo słabej jakości, a zagraniczne – zdecydowanie lepsze.

      Co do floatów i utrzymawania kodu, już o tym mówiłem. Dodam tylko, że skoro jest to wiedza potrzebna tylko do utrzymywania projektów, to równie dobrze można ją podać w osobnym kursie mówiącym o utrzymywaniu projektów. Podstawową wiedzą powinien być flexbox i grid, nie stare techniki do utrzymywania starego kodu. Chyba że juniorzy w Polsce po prostu chcą utrzymywać wieloletni kod, zamiast rozwijać nowe produkty – to proszę bardzo. Niemniej nie bardzo widzę jakąkolwiek wartość w takim podejściu. Inna rzecz, że w artykule przytoczyłem przecież wypowiedź Samuraja, który stwierdził, że float wciąż jest efektywny w budowaniu layoutów. A to stwierdzenie w roku 2019 nie jest już prawdą.

      Co do selektora uniwersalnego: „miliony much nie mogą się mylić”. Podałem argumenty, dlaczego nie powinno się używać selektora uniwersalnego do resetu, więc dodatkowo zmieniłeś kontekst tej porady, doprowadzając ją do absurdu. To, przez kogo niepolecany w tym konkretnym przypadku, również zawarte jest w artykule.

  8. Recenzja, z której sporo się nauczyłam! Super!
    Praktyka jest bardzo ważna, to w sumie cel i najważniejsza część tego, co robimy, ale często na tych kursach brakuje mi teorii. Właśnie tych szczegółów, precyzyjnych definicji i wspomnienia o dobrych praktykach. Co ciekawe najwięcej o dostępności i ważnych teoretycznych niuansach przeczytałam w książce. Dlatego cieszę się, że mimo wszystko zdecydowałam się na wspomaganie nauki tradycyjnym podręcznikiem, choć niewiele osób wspomina o książkach w kontekście nauki tworzenia stron internetowych. Ale niestety czytam wydanie z 2014 roku i wiem, że kilka rzeczy jest nieaktualnych i muszę na bieżąco wyszukiwać i sprawdzać co się zmieniło, to pewna trudność. Z jednej strony forma kilkusetstronnicowej książki pozwala na opisanie wszystkiego bardzo dokładnie, ale z drugiej strony trudno tutaj o aktualność, szczególnie jeżeli chodzi o polskie wydania.
    Kursu Samuraja w sumie nie przerabiałam, ale zaglądałam do kilku jego filmów. Staram się jednak głównie szukać tutoriali po angielsku. Bardzo lubię kanał Kevin’a Powell’a, dobrze tłumaczy 🙂

  9. Witam. Czy mógłbyś napisać coś o szkole programowania Codeberry?Właśnie ją przerabiam i chciałbym przeczytać opinie profesjonalisty. Dzięki.

    1. Witam, niestety, nigdy nie miałem z nią żadnej styczności, więc trudno mi cokolwiek o niej powiedzieć. Widzę, że jest opcja dostępu za darmo – ale to oznacza, że, recenzja najwcześniej ukazałaby się w marcu/kwietniu.

  10. A co Pan powie na temat kanału pasja informatyki na YT? Moim zdaniem Mirek Zelent to number 1 w Polsce jeśli chodzi o te kursy dla początkujących.

  11. Jestem zielony w webdevie, właśnie kończę ten kurs i takie wpisy są na wagę złota. Domyślam się, że sporo czasu i pracy zajęło Ci napisanie tego posta. Wielkie dzięki!

    Te kursy są dość popularne, więc fajnie byłoby gdybyś znalazł czas, żeby sprawdzać pozostałe od Samuraja (web dev zaawansowany, js, react). Myślę, że to przydałoby się wielu ludziom (a już na pewno mi 😊 bo mam je wykupione i pewnie będę je przerabiał uzupełniając wiedzę ze źródeł, które podałeś w którymś z komentarzy).

    1. A może by tak poświęcić 10 sekund na risercz i znaleźć tutoriale, książkę, artykuły, nawet filmiki na YouTube?

      Poza tym argument, że nie można krytykować, jeśli się samemu czegoś nie robi, jest tak bardzo zły, że naprawdę nie wiem, czemu ktoś go jeszcze stosuje.

      1. Ale ja nie powiedziałem, że nie można krytykować. Jestem pełen szacunku dla wnikliwej analizy kursu. Po prostu uważam, że czas który Pan poświęcił na wyszukiwanie błędów w kursie który ktoś zrobił, lepiej byłby spożytkowany na stworzenie idealnego wg Pana kursu. Sam chętnie kupiłbym taki idealny kurs. Tym bardziej, że dobrych kursów po polsku jest jak na lekarstwo. Oczywiście jest to moja subiektywna opinia.

        1. W takim razie przepraszam, całkowicie inaczej odebrałem Twój poprzedni komentarz.

          Jeśli chodzi o taki pełnoprawny kurs, problemem z nim jest to, że wymaga zdecydowanie większych nakładów pracy niż napisanie tutorialu czy choćby zrobienie takiej analizy. W chwili obecnej dość trudno mi jest wygospodarować odpowiednią ilość czasu na tego typu rzeczy. Niemniej kurs gdzieś tam mi się przez cały czas kołacze z tyłu głowy.

  12. Nie ma problemu. Chodziło mi o to że, kurs Samuraja nie jest idealny, ale jednak jest. A jeżeli Pański kurs „przejdzie z tyłu głowy do przodu” to będę pierwszy który go kupi. Pozdrawiam. 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.