Breakpoints

Praktycznie od samego początku istnienia RWD towarzyszyły mu tzw. breakpoints. W najbardziej zamierzchłych czasach, jeszcze przed pojawieniem się nowych systemów layoutowych, były tak naprawdę jedynym sposobem zapewniania faktycznej responsywności. Jednak wraz z rozwojem CSS-a ich rola sukcesywnie malała i dzisiaj często można ich uniknąć albo przynajmniej zminimalizować liczbę użyć.

Breakpoint, czyli łamanie w imię designu

Nigdy nie zaistniał oficjalny polski odpowiednik tego angielskiego terminu. Najprawdopodobniej najbliżej prawdy byłoby sformułowanie “punkty przełamania”. I można to tłumaczyć dwojako. Z jednej strony, breakpoints wyznaczają miejsca, w których musi dojść do przełamania layoutu, żeby strona się nie rozpadła. Z drugiej: to właśnie te rozpadające się miejsca.

Ale czemu layout miałby się rozpaść? Wypada tutaj wrócić do fundamentalnego założenia RWD: strona ma być responsywna. Zatem dostosowywać się do warunków, w jakich będzie wyświetlana. W samych początkach RWD te warunki tak naprawdę sprowadzały się tylko do jednej kwestii – wielkości viewportu. Dość logicznym wydaje się założenie, że strona na ekranie laptopa powinna wyglądać jednak inaczej, niż na ekranie smartfona. Choćby dlatego, że jest na nim więcej miejsca i można np. wcisnąć dodatkową kolumnę obok treści z ~reklamami~ przydatnymi linkami. Na smartfonie z kolei taka kolumna się nie zmieści i trzeba ją przenieść gdzie indziej, np. pod główną treść strony. I I tutaj mamy właśnie breakpoint – czyli media query wymuszające zmianę layoutu ze względu na wielkość viewportu:

/*
Domyślnie sidebar siedzi sobie spokojnie pod treścią i ma margines górny.
*/
.sidebar {
    margin-top: 1.5em;
}

/*
Ale jeśli szerokość viewportu jest odpowiednio duża, wciśnijmy go z prawej strony.
*/
@media screen and ( min-width: 768px ) {
    .sidebar {
        float: right;
        margin-top: 0;
    }
}

Bardzo szybko (bo już jakieś 3 lata po ukuciu terminu RWD) pojawiły się dwie szkoły breakpointów.

Szkoła 1: piszmy pod najpopularniejsze urządzenia

Nie mam na to żadnych statystyk ani twardych danych, ale zaryzykuję twierdzenie, że ta szkoła była zdecydowanie popularniejsza. Zwłaszcza, jeśli weźmie się pod uwagę popularność Bootstrapa w okolicach 2015 roku. Na swój sposób stał się jQuery frameworków CSS-owych. Podstawowym założeniem responsywności w Bootstrapie było stworzenie listy breakpointów. Miały one odzwierciedlać najpopularniejsze wielkości viewportów urządzeń z różnych klas. To miało umożliwić tworzenie layoutów dostosowujących się do różnych urządzeń, np. dla tabletów (czyli viewportów poniżej 768px) pojawiało się menu hamburgerowe, zamiast nawigacji przeznaczonej na desktopy.

Takie rozwiązanie jednak trudno nazwać w pełni responsywnym. W rzeczywistości bowiem stworzona strona “zmienia się” jedynie w ściśle określonych momentach. Nie dostosowuje się w pełni do viewportu osoby użytkowniczej, a jedynie do najbliższego jej breakpointu. Tym samym layout staje się niejako ważniejszy od treści. To nie ona wpływa na to, w których miejscach layout musi zostać “przełamany”. Layout zawsze łamie się w taki sam sposób i wynika to z arbitralnej decyzji osoby webdeveloperskiej.

W obecnych czasach takie rozwiązanie napotyka na jeszcze inny problem: urządzeń na rynku jest naprawdę dużo. Coś takiego jak “najpopularniejsze viewporty” nie ma większego sensu, bo urządzenia różnią się od siebie coraz bardziej i ich różnorodność wzrasta skokowo.

Szkoła 2: przełamujmy jedynie tam, gdzie naprawdę potrzeba

Dlatego istnieje też druga szkoła, która breakpointy zostawia do przełamywania layoutu wtedy, gdy naprawdę trzeba. Wróćmy do przykładu ze zmianą nawigacji z rozwinętej formy, pokazującej poszczególne pozycje, do menu ukrytego za hamburgerem. W przypadku pierwszej szkoły ta zmiana następowała, gdy osoba użytkownicza korzystała z urządzenia o małym viewporcie (w domyśle: urządzenia mobilnego). Druga szkoła dodałaby breakpoint jedynie w przypadku, gdyby zabrakło miejsca na wyświetlenie wszystkich linków w nawigacji. Jeśli zatem na smartfonie linki dalej by się mieściły, nie byłoby żadnego powodu, by pojawiał się tam breakpoint.

W tym podejściu to treść decyduje o layoucie. Dzięki temu do ustalania breakpointów posługiwać się można kryteriami takimi jak np. czytelność. Sama liczba breakpointów również powinna być mniejsza. Nie są bowiem narzucone z góry, arbitralnie. Raczej są konsekwencją treści, którą chcemy przekazać użytkownikowi.

Współczesne alternatywy

Obecnie, w dobie flexboksa i grida, liczbę breakpointów można znacząco ograniczyć. Przy odpowiednim kodzie CSS nowoczesne layouty są w stanie same się dopasowywać do dostępnego miejsca bez potrzeby ręcznej ingerencji w większości przypadków. Breakpointy przydają się głównie do większych ingerencji (jak właśnie zamiana nawigacji w hamburgerową wersję).

Warto także zauważyć, że obecnie często mamy bardziej wyrafinowane narzędzia, niż breakpointy oparte na wielkości viewportu. Może się okazać, że lepszym wyborem będzie np. sprawdzenie, czy użytkownik posługuje się urządzeniem dotykowym, niż, czy urządzenie ma mały viewport. Mały viewport może mieć też małe okienko przeglądarki wciśnięte gdzieś z boku wielgachnego monitora 4K. Założenie, że mały viewport oznacza urządzenie mobilne (czyli de facto dotykowe), może prowadzić do oferowania interfejsu dotykowego osobom użytkowniczym, które go nie potrzebują. I na odwrót: duży viewport niekoniecznie oznacza, że urządzenie nie jest dotykowe. Dlatego breakpointy oparte na wielkości viewportu często warto zastąpić innymi media queries.

No i warto także na koniec wspomnieć, że nawet breakpointy wynikające z treści dostały swojego konkurenta we współczesnym CSS-ie – container queries. Dzięki nim można przenieść breakpointy z poziomu całego viewportu na poziom konkretnego komponentu.

Źródła

Dodatkowe materiały