Artykuł „CSS Grid Poradnik PL – DARMOWY kurs z CSS Grida!”

W połowie czerwca na kilku forach webmasterskich, na których mam przyjemność być administratorem, pojawił się link do artykułu CSS Grid Poradnik PL – DARMOWY kurs z CSS Grida!. Jego tytuł zaciekawił mnie na tyle, że postanowiłem się nad nim chwilę pochylić.

• Już na samym początku dowiadujemy się, że CSS Grid to najbardziej wydajny sposób tworzenia responsywnych szablonów dostępny w CSSie. Nie jest jednak przytoczony żaden dowód na to twierdzenie. A jest ono dość poważne, bo wydajność jest jednym z najważniejszych czynników w dzisiejszym tworzeniu stron WWW. I rozumie się ją już nie tylko jako skrócenie czasu ładowania, ale także – a może przede wszystkim – jako optymalizację samego procesu renderowania.

  Tutaj przydałoby się przytoczenie jakiegokolwiek benchmarku. Niestety, Google wskazuje jedynie na dość stare, jak np. Performance analysis of Grid Layout (ang. Analiza wydajności siatki do tworzenia układu strony – ależ to beznadziejnie brzmi po polsku…). Artykuł ten pokazuje, że w zależności od przypadku CSS grid może być wydajniejszy od flexboxa o 7%, ale także – wolniejszy o 15%. Żeby było jeszcze zabawniej, mniej więcej z tego samego okresu pochodzi benchmark pokazujący, że flexbox jest wolniejszy od display: table.

  I miałoby to logiczne uzasadnienie, bo podobną sytuację można zaobserwować po stronie JS, w którym Array.prototype.forEach jest zwykle wolniejsze niż zwykła pętla for. Uzasadnieniem dla tego faktu może być to, że pewne mechanizmy pojawiły się później, a zatem – było o wiele mniej czasu na ich optymalizację. Bardzo często brakuje także faktycznych przykładów użycia (bo np. zamiast kodu ES6 do przeglądarki trafia wynik transpilacji przez Babela), na podstawie których można optymalizować. To sprawia, że nowsze funkcje przeglądarki muszą swoje „przeżyć”, żeby stać się wydajne. Nie wątpię, że w przypadku grida (czy nawet flexboxa) takich czasów jeszcze dożyjemy. Niemniej na chwilę obecną uważałbym z odważnymi stwierdzeniami, że jest to najwydajniejszy sposób tworzenia layoutów, bo brakuje na to twardych dowodów.

• Jak można zauważyć wsparcie dla CSS Grida jest wysokie. Nieuniknione jest to, że pozostałe przeglądarki, które nie wspierają jeszcze CSS Grida, w najbliższym czasie dołączą do grona zielonych.

  Problem polega na tym, że to nieuniknione nigdy nie nadejdzie, bo wśród przeglądarek, które nie obsługują CSS Grida, są głównie truposze pokroju IE 11 czy Opery Mini.

• Pierwsza linijka ustala ilość kolumn naszej siatki. Możemy wykorzystać tu wartości takie jak auto, fr, px czy %.

  Wymienione wartości wskazują, że grid-template-columns wcale nie określa ilości kolumn, a ich rozmiary. Tak zresztą podaje MDN:

  The grid-template-columns CSS property defines the line names and track sizing functions of the grid columns.

  [Właściwość CSS grid-template-columns definiuje nazwy linii oraz funkcje śledzące rozmiary [nazwa własna zdefiniowana w specyfikacji – przyp. tłum.] kolumn siatki.]

• Czym jest jednostka fr? Jest to elastyczna jednostka – frakcja, gdzie 1 frakcja odpowiada 1 części dostępnej przestrzeni.

  Dość trudno zgodzić się na tłumaczenie fr jako frakcji. Słownik języka polskiego PWN nie notuje takiego wykorzystania. Jest ono określone w Słowniku języka polskiego pod red. Doroszewskiego, a zatem – w słowniku starszym. Jest tam też podane dawne znaczenie – jako ułamek. I wydaje mi się, że właśnie taką nazwę wypada przyjąć dla tej jednostki: ułamek, względnie po prostu część.

• Samo tłumaczenie znaczenia tej jednostki również wydaje się nieco niejasne:

  Utworzy nam siatkę z trzema kolumnami, każda o rozmiarze jednej frakcji, czyli wolnej przestrzeni.

  To zdanie wygląda na sprzeczne logicznie. Jeśli każda kolumna zajmuje wolną przestrzeń, to znaczy, że zmieści się tylko jedna, a dla reszty owej przestrzeni zabraknie.

• Sekcja Wartości dla grid-column i grid-row jest całkowicie niezrozumiała, ponieważ niemal nie tłumaczy konceptu linii siatki. A jest on kluczowy, by zrozumieć, czemu wartości 1 / 4 i 1 / span 3 oznaczają to samo. Co prawda jest niby obrazek poglądowy, ale jest on po prostu nieczytelny.

• Główną tezą przewijającą się przez cały artykuł jest twierdzenie, że konkurencją dla CSS Grid jest Bootstrap:

  Jednak, gdy pojawił się CSS Grid, Bootstrap tak naprawdę staje się niepotrzebny, ponieważ mając kolumny, rzędy i resztę w CSS Gridzie spokojnie utworzymy z jego wykorzystaniem responsywną stronę i dodatkowe biblioteki nie będą nam do tego potrzebne.

  Jest to jednak twierdzenie z gruntu nieprawdziwe. Bootstrap jest bowiem frameworkiem, który dostarcza dużej liczby gotowych do wykorzystania komponentów. CSS Grid mógłby zastąpić jedynie małą część Bootstrapa, odpowiedzialną za tworzenie siatki.

• Następnie następuje porównanie CSS Grida do Bootstrapa.

  • kod HTML przy użyciu CSS Grida jest DUŻO PROSTSZY (brak zbędnych divów, klas)

    To jest zarówno zaleta, jak i wada. Obecnie nie ma wsparcia dla subgrida (podsiatki), co powoduje, że trzeba najczęściej spłaszczać strukturę HTML-a. A to już bardzo prosta droga do niesemantycznego HTML-a. Sytuację w niektórych przypadkach ratuje display: contents;, ale nie zawsze da się go zastosować, a i wsparcie nie jest idealne.

    Problemem CSS Grida nie jest to, że umożliwia pisanie prostego kodu. Problemem jest to, że w wielu przypadkach wymusza stosowanie płaskiej struktury HTML, by uzyskać konkretny efekt.

  • omijamy korzystanie z dokumentacji Boostrapa, wystarczy znać kilka podstawowych właściwości do pisania layoutu w CSS Gridzie

    Wątpię, by ktoś uczył się na pamięć regułek związanych z CSS Gridem, gdy istnieją tak dobre dokumentacje jak choćby MDN. Nie sztuką jest pamiętać wszystko, sztuką jest umieć to szybko znaleźć w dokumentacji.

    Poza tym: dokumentacja Bootstrapa zawiera bardzo liczne przykłady komponentów napisanych z uwzględnieniem wymogów dotyczących dostępności. A to wykracza daleko poza obszar CSS Grida, przeznaczonego wyłącznie do tworzenia układu strony.

  • brak kodu „boilerplate” w CSS Gridzie (dużo zbędnego kodu dla prostej rzeczy jak to bywa w przypadku Boostrapa),

    Boilerplate nie jest „zbędnym kodem”. To kod będący podstawowym szablonem do tworzenia konkretnych projektów na jego podstawie. I wbrew pozorom taki Bootstrap wcale nie ma jakiegoś superrozbuchanego podstawowego szablonu. Główną różnicą jest fakt, że Bootstrap wymaga dość sporej ilości JS-a – bynajmniej jednak nie do tworzenia układu strony.

    I dla porównania: kod HTML5 Boilerplate.

    Jeśli jednak rozumiemy boilerplate jako „zbędny kod”, to wówczas trzeba przyznać, że w wielu przypadkach kod Bootstrapa można by uprościć.

  • CSS Grid jest bardziej elastyczny przy dokonywaniu zmian,

    Jeśli bierzemy pod uwagę jedynie układ strony, to wydaje mi się, że zarówno Bootstrap, jak i CSS Grid, są mniej więcej tak samo elastyczne. Główna różnica polega na tym, że w przypadku CSS Grida dokonujemy zmian w CSS-ie, natomiast w przypadku Bootstrapa – w kodzie HTML (zmieniając klasy .col-*).

  • dowolna ilość kolumn (szablon może mieć 1, 2, 5, 12 czy 24 kolumny – tyle ile potrzebujemy),

    W przypadku Bootstrapa również można zdefiniować dowolną liczbę kolumn. Udostępnia on odpowiedni mixin.

  • już 88% przeglądarek wspiera CSS Grida (będzie ich tylko więcej),

    Jak już wspominałem, CSS Gridowi de facto skończył się zakres przeglądarek, na które może jeszcze trafić. I nigdy nie uzyska tak szerokiego wsparcia jak Bootstrap 4 (nie wspominając już o wsparciu Bootstrapa 3, który wciąż jest używany w sporej liczbie projektów).

  • strona działa dużo szybciej (nie ładujemy żadnych dodatkowych bibliotek, skryptów, aby utworzyć szablon),

    Czas ładowania to tylko jeden z czynników wpływających na wydajność. Poza tym w przypadku Bootstrapa również nie ładujemy dodatkowych bibliotek i skryptów, by utworzyć szablon. Ładujemy je po to, by zapewnić warstwę zachowania dla poszczególnych komponentów.

    Jeśli chcemy porównywać w ten sposób Bootstrapa i CSS Grida, to wypadałoby porównywać wyłącznie grida z Bootstrapa do natywnej siatki. To pozwoliłoby w sensowny sposób uzyskać wynik, który z tych dwóch sposobów tworzenia układu strony jest faktycznie wydajniejszy.

  • CSS Grid staje się przyszłością tworzenia szablonów stron

    Obawiam się, że to twierdzenie z rodzaju tych, których nie da się sensownie udowodnić.

  • nie musimy podpinać do strony dodatkowych bibliotek i innych elementów,

    Po raz kolejny zostaje powtórzony argument odnośnie wydajności.

  • możemy dokonywać zmian np. położenia elementów na telefonach z poziomu CSSa, bez dotykania HTMLa,

    W zależności od projektu to może być zaleta lub wada. Warto wspomnieć tutaj o inicjatywie ACSS. Co prawda sam jestem z grona zwolenników definiowania całej prezentacji w CSS-ie, niemniej rozumiem, dlaczego spora część webdeveloperów woli raczej zmieniać HTML.

  • omijamy korzystanie z całego Boostrapa, w którym zazwyczaj tylko używaliśmy gridu czy ostylowania przycisków :),

    Ten argument dałoby się utrzymać, gdyby nie istniał sensowny sposób na podzielenie Bootstrapa na części. Co prawda to narzędzie przeznaczone jest dla Bootstrapa 3, niemniej w przypadku Bootstrapa 4 jest to wciąż możliwe na poziomie kodu źródłowego.

  • najważniejsze – pisanie layoutu w CSS Gridzie jest szybsze, prostsze i dużo przyjemniejsze

    Po tym jak się już pozna i zrozumie odpowiednie właściwości CSS. A w przypadku Bootstrapa często wystarczy po prostu skopiować gotowca z dokumentacji.

• Jednak jeśli chcielibyście bardziej zagłębić się w tematykę CSS Grida […], powinniście sięgnąć po poniższe źródła:

  • w3school – powtórzenie podstaw […]

  Nie, nie powinniście.

Cały artykuł wydaje się za „szybki”, pomijając istotne szczegóły i sprawiając bardzo chaotyczne wrażenie. W dodatku jego główne założenie wydaje się z gruntu błędne, utożsamiając Bootstrapa wyłącznie z narzędziem do tworzenia układu strony.