O responsywności i wsparciu przeglądarek

Arleta HTML i CSS od postaw 20 kwietnia, 2020 | 1

Czasy, kiedy do korzystania z internetu używało się prawie wyłącznie komputera stacjonarnego lub laptopa odeszły bezpowrotnie. Ilość urządzeń, które pozwalają na przeglądanie stron i aplikacji internetowych rośnie z każdym dniem. Na każdym z tych urządzeń z reguły można uruchomić więcej niż jedną przeglądarkę internetową. Jak sobie zatem poradzić z obsługą tylu możliwości bez pisania tysięcy linii kodu?

Karuzela możliwości

„Jeszcze się taki nie urodził, co by wszystkim dogodził” – tym krótkim powiedzonkiem można spointować wysiłki front-end developerów w nierównej walce z wszelkiej maści laptopami, tabletami, smartfonami, fabletami, czytnikami ebooków, inteligentnymi lodówkami i toną innego sprzętu, na którym można wyświetlić stronę internetową. Na tych urządzeniach bywają zainstalowane różne systemy operacyjne oraz różne przeglądarki internetowe.

W idealnym świecie (dla użytkowników) każda strona i aplikacji wspierałaby wyświetlanie na wszelkich możliwych urządzeniach, systemach i przeglądarkach. Z wiadomych przyczyn jest to nierealne do zrealizowania, dlatego wybór zakresu wsparcia jest często efektem pewnego konsensusu pomiędzy preferencjami docelowej grupy użytkowników oraz zasobnością portfela właściciela produktu, lub po prostu jest to inwencja autora strony.

Jakie przeglądarki wspierać?

Na coś się jednak trzeba zdecydować (i odpowiedzieć na nurtujące, legendarne pytanie o Internet Exporer) i fajnie byłoby podeprzeć się jakimiś danymi przy dokonywaniu tego wyboru. W internecie znajduje się wiele miejsc, z których można czerpać informacje o statystykach dotyczących użycia wybranych systemów operacyjnych i przeglądarek. Jednym z nich jest StatCounter, który daje duże możliwości edytowania niezbędnych danych.

Warto dobrze zastanowić się nad grupą docelową strony czy aplikacji. Dla przykładu: jeżeli użytkownikami produktu mają być również osoby starsze i będą z niego korzystać w swoim miejscu pracy, które niekoniecznie gwarantuje dostęp do nowoczesnego sprzętu (np. urzędy czy publiczne przychodnie), to w mojej opinii warto byłoby rozważyć wsparcie starszych wersji przeglądarek oraz niesławną domyślną przeglądarkę poprzednich wersji systemu Windows.

Jeżeli jednak korzystać z produktu będzie np. głównie młodzież na swoich smartfonach, to wybór wsparcia powinien obejmować przeglądarki i urządzenia inne niż wymienione w poprzednim przykładzie.

Responsive web design – co to takiego?

Cytując Wikipedię:

RWD – technika takiego projektowania strony WWW, aby jej układ dostosowywał się samoczynnie do rozmiaru okna przeglądarki, na której jest wyświetlany np. przeglądarki, smartfonów czy tabletów. Strona utworzona tą techniką jest uniwersalna: wyświetla się dobrze na dużych ekranach oraz na smartfonach i tabletach.
https://pl.wikipedia.org/wiki/Responsive_web_design

Dalej artykuł informuje, że do wdrażania RWD stosuje się media queries (omówione niżej), jednak żeby mogły działać, należy zmienić ustawienia skalowania strony poprzez dodanie w pliku index.html w sekcji <head> poniższego tagu:

<meta name="viewport" content="width=device-width, initial-scale=1">

Mobile first czy desktop first?

Na mojej (prawie) każdej rozmowie rekrutacyjnej musiało pojawić się to pytanie. Prawidłową odpowiedzią było (prawie) zawsze mobile first i powiedzieć inaczej to prawie jak obrazić papieża. Ale czy na pewno?

Jeżeli produkt, nad którym pracujemy ma służyć w głównej mierze pracownikom biurowym w ich pracy przy komputerze, a klient dla którego wykonujemy produkt dostarcza makiety skoncentrowane na funkcjonalnościach dla desktopu to czy jesteśmy zobligowani do traktowania urządzeń mobilnych jako priorytetowych dla projektu? Nie jestem przekonana.

Oczywiście z czasem może okazać się, że zastosowanie produktu ulegnie zmianie, dlatego totalne olanie wersji mobilnej byłoby złym pomysłem (chyba, że klient mówi o tym wprost). Jednak żadne inne wyjątki od mobile first nie przychodzą mi do głowy.

Narzędzia

Programiści front-end do swojej dyspozycji mają kilka narzędzi, które ułatwiają tworzenie responsywnych stron i aplikacji.

Media queries

Media query to narzędzie służące różnicowaniu stylów CSS dla wybranego medium oraz jego parametrów. Brzmi dość zawile, ale za chwilę okaże się, że nie jest to tak skomplikowane, jak się wydaje.

Sposoby użycia

Media queries można używać albo jako atrybut elementu <link> dla konkretnego arkusza stylów, np.:

<link rel="stylesheet" media="(max-width: 800px)" href="example.css" />

albo wewnątrz arkusza stylów jako coś na kształt selektora medium:

@media (max-width: 600px) {
  .facet_sidebar {
    display: none;
  }
}

Jeżeli warunki zawarte w query zostaną spełnione, wtedy kod CSS zostanie załadowany.

Składnia

Media query składa się z opcjonalnego typu medium oraz dowolnej liczby media features, które definiują warunek konieczny do uruchomienia reguł CSS. Bardzo często można natknąć się na kod podobny do poniższego:

@media screen and (min-width: 576px) {
  .footer {
    display: block;
  }
}

co oznacza, że deklaracja display: block; dla elementów o klasie .footer zostanie wykonana tylko dla urządzeń ekranowych o szerokości większej lub równej 576 pikseli. Listę dostępnych mediów oraz media features można wraz z opisami można znaleźć tutaj.

Warto zwrócić uwagę na możliwość stosowania operatorów logicznych przy konstruowaniu media query (and, or, not).

Operator logiczny not

Operator logiczny not neguje całe media query, co oznacza że poniższy kod:

@media not all and (monochrome) { … }

będzie interpretowany jako:

@media not (all and (monochrome)) { … }

Frameworki

We wpisie o frameworku Bootstrap rozpisałam breakpointy dla poszczególnych szerokości, które teraz powtórzę:

XS (extra small) < 576px
S (small) ≥ 576px
MD (medium) ≥ 768px
L (large) ≥ 992px
XL (extra large) ≥ 1200px

Bootstrap został stworzony zgodnie z podejściem mobile first, zatem domyślne wartości to zawsze te liczone od najmniejszych, zatem zmiana wartości właściwości polega na nadpisywaniu wartościami dla większych rozmiarów.

Zatem jeżeli naszym celem byłoby stworzenie akapitu, który dla ekranów o szerokości poniżej 567 pikseli miałby zajmować całą szerokość strony, dla tych o szerokości do 768 pikseli połowę szerokości strony, a dla jeszcze większych – 25% szerokości strony, to wówczas moglibyśmy opisać te życzenia a następujący sposów:

<div class="row">
  <p class="col-12 col-sm-6 col-md-3">Lorem ipsum...</p>
</div>

Bootstrap również dostosowuje media queries do swoich beakpointów. Tak oto media query o treści

@media (min-width: 576px) { … }

można zapisać (przy użyciu Scss pamiętając o koniecznych importach) jako

@include media-breakpoint-up(xs) { … }

Po więcej przykładów odsyłam tutaj.

Vendor prefixes

Prefiksy były konieczne do wykorzystania eksperymentalnych funkcji CSS. Do dziś w wielu projektach można zobaczyć podobny kod:

.transition-item {
  -webkit-transition: all 3s linear;
  -moz-transition: all 3s linear;
  -ms-transition: all 3s linear;
  -o-transition: all 3s linear;
  transition: all 3s linear;
}

Kolejne przedrostki oznaczają:

webkit – Chrome, Safari, nowsze wersje Opera, prawie wszystkie przeglądarki na iOS, w tym Firefox na iOS; praktycznie wszystkie przeglądarki oparte na WebKit
moz – Firefox
o – stare przed-WebKitowe wersje przeglądarki Opera
ms – Internet Explorer oraz Microsoft Edge

Na szczęście w 2020 wystarczy, że napiszemy

.transition-item {
  transition: all 3s linear;
}

Nie oznacza to jednak, że nigdy nie będziemy potrzebować przedrostków. Na szczęście zamiast buszować w poszukiwaniu informacji o wybranej właściwości CSS, można użyć narzędzia takiego jak np. Autoprefixer.

Supports

Poszukując narzędzi służących do implementacji RWD natknęłam się na @supports, czyli narzędzie stosowane w CSS do warunkowego uruchomienia kodu po zbadaniu czy dana przeglądarka wspiera wybraną funkcjonalność, np. grid. Składnia @supports wygląda prawie identycznie jak w przypadku media queries.

Nigdy nie korzystałam z tego rozwiązania i po przeczytaniu kilku artykułów na ten temat nie bardzo widzę dla niego zastosowanie w mojej codziennej pracy. Bo tak po prawdzie: jeżeli przeglądarka nie wspiera danej funkcjonalności to i tak nie uruchomi kodu, który jest z nią związany, zatem poniższy kod jest w mojej opinii trochę „od czapy”:

@supports (display: grid) {
  .main {
    display: grid;
  }
}

Zapewne jednak (jak to zwykle bywa) istnieją przypadki, w których użycie tego narzędzia będzie uzasadnione, dlatego zainteresowanych odsyłam po więcej informacji do MDN, a ciekawskich do analizy na CSS-tricks.

Testy

Kiedy już napiszemy nasz reposonsywny CSS, fajnie byłoby go jakoś przetestować. Oczywiście klika różnych przeglądarek zainstalowanych na komputerze front-end deva to chleb powszedni, możemy jednak sobie pomóc używając narzędzi dedykowanych do tzw. testów cross-platform i cross-browser. Mało kto ma możliwość i ochotę sprawdzać stronę i aplikację na 5 przeglądarkach na każdym systemie operacyjnych i wielu urządzeniach.

Z reguły tego typu narzędzia są jednak dość drogie, a ich „darmowe” alternatywy za darmo udostępniają jedynie część funkcjonalności (por. np. tutaj). Szczególnie problematyczne może być testowanie strony na Safari jeżeli nie mamy dostępu do Maca.

Sporym ułatwieniem testów są symulatory urządzeń dostępne w ramach urządzeń developerskich w przeglądarkach. Chrome np. potrafi symulować wybrane telefony i tablety, zarówno te z jabłuszkiem jak i bez. Nieźle imituje również dotknięcia zamiast kliknięć. Jest to jednak nadal symulacja i należy liczyć się z pewnymi ograniczeniami tej usługi.

Jedna odpowiedź

Łukasz pisze:

22 kwietnia, 2020 o 11:54 am

Strona która nie jest RDW to martwa strona !!:) nie wiem czy w ogóle takie powstają, ale jak tak to chyba Pan Andrzej 60lat takie coś robi.

Odpowiedz