WordPress - motywy, wtyczki, informacje, programowanie

Serwisy responsywne – Responsive Web Design i Media Queries

Nie mogę się nadziwić jak wiele osób na co dzień tworzących serwisy internetowe, albo nie słyszało nigdy o Responsive Web Design, albo zignorowało go jako jedną z wielu nowinek o przeciętnym znaczeniu. Tymczasem to jeden z najważniejszych konceptów jakie się pojawiły w ostatnich latach i coś, czego niewątpliwie wszyscy będą musieli się nauczyć.
Jeśli jeszcze nie wiesz, co to jest Responsive Web Design (RWD), ten tekst jest przede wszystkim dla Ciebie.

Powiększ okno przeglądarki z otwartym WPinternals.pl i skaluj je na szerokość obserwując jak zachowują się poszczególne elementy strony. Nie tylko zmieniają się ich szerokości, ale też ich wzajemne położenie, niektóre mogą znikać. I to wszystko bez jednej linijki JavaScriptu.

Powrót do źródeł?

Kiedy w moje głowie dojrzewał pomysł zrobienia WPinternals.pl, wpadł mi w ręce prosty i dość niepozorny motyw Yoko. To był tak naprawdę pierwszy responsywny motyw, któremu poświęciłem więcej uwagi i to był ten moment, kiedy RWD, dotąd jedna z ciekawostek, o której wiedziałem, ale która niespecjalnie mnie interesowała, stała się dla mnie jedną z najważniejszych.

Pamiętam dawne czasy, drugą poławę lat 90-tych kiedy robiłem pierwsze swoje strony WWW. Powszechne były wtedy płynne layouty, w których tekst rozlewał się w zależności od szerokości okna przeglądarki. To nie był przypadek tylko konsekwencja logiki, która leżała u podstaw HTML’a. Jest to język, którego zadaniem jest reprezentacja struktury tekstu – określenie co w nim jest tytułem, co nagłówkiem rozdziału lub podrozdziału, co jest warte podkreślenia, a co jest cytatem oraz określenie powiązań między dokumentami albo wieloma miejscami tego samego dokumentu.

NCSA Mosaic

NCSA Mosaic dla Windows, wersja 1.0

Reprezentacja tekstu miała być uniwersalna, oderwana od przeglądarki, a trzeba pamiętać, że w tym czasie wciąż używało się jeszcze NCSA Mosaic, Netscape raczkował, Internet Explorer w ogóle się nie liczył, a stosunkowo często używany był Lynx, czyli przeglądarka działająca pod Unixem w trybie tekstowym. W tamtym czasie wszystkie strony sprawdzało się pod Lynxem i musiały być czytelne. Dziś mało kto to robi, chociaż poprawne i użyteczne renderowanie strony w Lynxie jest dobrym sygnałem chociażby na to, że strona zostanie dobrze zinterperetowana i odczytana przez oprogramowanie dla niewidomych i niedowidzących, albo że Google Bot poprawnie ją rozumie i zindeksuje.

Lynx

Serwis WPinternals.pl we współczesnej wersji przeglądarki Lynx (Debian, Gnome Terminal)

Utrzymanie tej kompatybilności między przeglądarkami nie było kilkanaście lat temu jakąś wyszukaną praktyką, po prostu możliwości określania wyglądu stron były bardzo niewielkie, a wymagania estetyczne użytkowników raczej umiarkowane. Strony były proste. Przypominały dzisiejsze blogi, takie ja ten, Składały się z listy zajawek, jakiejś nawigacji i strony artykułu.

Potem jednak wszystko zaczęło się zmieniać, ewoluował HTML. Pierwsze implementacje CSS (IE3, potem Netscape Navigator 4, były koszmarem i panowała powszechna opinia, że to jakiś poroniony wynalazek, ale z czasem CSS dojrzał i w jakimś momencie obudziliśmy się w Internecie, który niemal cały był (w dużej części wciąż jest) poskładany jak gazeta – „do piksla”, ze skomplikowanymi układami modułów, tak jakby był wydrukowany na niezmiennym i nie wymagającym adaptacji papierze.

I nagle się okazało, że prawie z dnia na dzień chcemy ten Internet oglądać na urządzeniach o bardzo różnych rozdzielczościach. To już nie są dwie czy trzy szerokości ekranu jak dawniej – 640, 800 i 1024, z których dwie tak naprawdę były w użyciu. Pojawiły się setki urządzeń mobilnych, za pośrednictwem których ludzie korzystają z sieci. Największa powszechnie używana szerokość ekranu to 1920, takie monitory kosztują już zaledwie kilkaset złotych. Szerokości tanich monitorów i laptopów to okolice 1300px. Najmniejsze to 320 – tryb portrait iPhona i wielu innych komórek.

Nigdy jeszcze nie było takiej rozpiętości w możliwościach urządzeń, a jednocześnie wiemy, że ta różnorodność nie zmniejszy się, wszystkie te urządzenia będą w powszechnym użyciu. W dodatku dziś przyzwyczajenia estetyczne i wymagania funkcjonalne użytkowników nie pozwalają tworzyć stron tak prostych jak kiedyś. Samo skalowanie strony, czyli zwężanie głównej kolumny tekstu do jakichś rozsądnych granic, już nie wystarcza. Żadna strona z płynnym layoutem, mająca więcej niż jedną kolumnę nie będzie dobrze wyglądać i przy szerokości 320px, i po rozciągnięciu do, powiedzmy, 1200px.

RWD rozwiązuje ten problem, ponieważ pozwala nie tylko na skalowanie poszczególnych modułów czy zdjęć na ekranie, ale także na zmianę ich wzajemnego położenia, zmianę wielkości czionek, a nawet ukrywanie niektórych elementów layoutu, bez dotykania HTMLa i tego jak strona jest w nim opisana, bez konieczności używania JavaSciptu, tylko w oparciu o CSS3 i media queries.

Jak działa Responsive Web Design?

Technika RWD jest możliwa dzięki CSS3 media queries. Pozwalają one powiedzieć przeglądarce, że pewien kawałek naszego arkusza styli powinien być zastosowany tyko dla pewnych szerokości ekranu. Na przykład:

#something {
    width: 80%;
}

@media only screen and (max-width: 800px) {
    #something {
        width: 100%
    }
}

Obiekt HTML o identyfikatorze #something będzie miał 80% szerokości, dla szerokości ekranu powyżej 800px. Jeśli będzie wyświetlany na węższym ekranie będzie zajmował 100% jego szerokości. Co ważne, aby przeglądarka zmieniła style nie musimy przeładowywać strony. Wystarczy że szerokośc okna się zmieni, na przykład dlatego, że zwęzimy okno przeglądarki, albo dlatego, że obrócimy naszego iPada z położenia landscape w położenie portrait i zostaną zastosowane style dla danej szerokości.

Oczywiście w naszym arkuszu styli możemy umieścić wiele takich media queries, możemy też określić minimalną szerokość dla danego stylu. Przypatrzmy się bardziej złożonemu przykładowi. Zacznijmy od pliku HTML:

<!doctype html>
<html lang="pl-PL" xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <meta name="viewport" content="width=device-width">
</head>
<body>

<div id="just-one-div">
	<p>Zwężaj i rozszerzaj okienko podziwiając kolorki.</p>
</div>

</body>
</html>

Linia 5 dotyczy Microsoft Internet Explorera i mówi, że ma on użyć najnowszego silnika do renderowania strony oraz  żeby załadował rozszerzenie Chrome Frame, jeśli jest zainstalowane. Nawet ze starych wersji Explorera robi ono sensowna przeglądarkę. W linii 6 informujemy przeglądarkę, żeby nie skalowała (nie pomniejszała) strony, tak by zmieściła się cała na ekranie (tak działają niektóre przeglądarki mobilne). Mamy tutaj jednego DIVa o identyfikatorze #just-one-div i zobaczymy najprościej jak zmienia się w zależności od szerokości okna.

Kliknij aby zobaczyć przykład 1.

Arkusz styli dla tej strony wygląda następująco:

body {
	background: #efefef;
}

#just-one-div {
	width: 50%;
	padding: 20px;
	margin: 50px auto;
	text-align: center;
	background: white;
	border: 2px solid black;
	font: bold 20px Arial, sans-serif;
	color: black;
}

@media only screen and (max-width: 900px) {
	#just-one-div {
		background: #FFB658;
	}
}

@media only screen and (max-width: 800px) {
	#just-one-div {
		background: #4D6F82;
	}
}

@media only screen and (max-width: 700px) {
	#just-one-div {
		background: #E3774C;
	}
}

@media only screen and (max-width: 600px) {
	#just-one-div {
		background: #AD413B;
	}
}

@media only screen and (max-width: 500px) {
	#just-one-div {
		color: white;
		background: #73214A;
	}
}

W miarę jak zwężamy okno, zmienia się kolor tła wybranego elementu. Jak widać pozostałe atrybuty pozostają niezmienne, nie musimy więc robić pełnych arkuszy styli dla każdej szerokości, a jedynie zmieniać to, co jest dla nas istotne.

Pełny kod przykładu 1 w pliku ZIP, ze wszystkimi elementami, można pobrać tutaj.

Spróbujmy teraz zrobic cos bardziej użytecznego. W kodzie HTML przykładu zamieńmy naszego DIVa na:

<div id="just-one-div">Media: </div>

oraz zastosujmy następujący arkusz styli:

body {
	background: #efefef;
}

#just-one-div {
	position: fixed;
	top: 10px;
	left: 10px;
	padding: 5px;
	margin: 5px;
	border: 1px solid black;
	font: 12px Arial, sans-serif;
	color: black;
	background: yellow;
}

#just-one-div:after {
	content: "global";
}

@media only screen and (max-width: 1024px) {
	#just-one-div:after {
		content: "1024px - iPad landscape, Kindle Fire landscape";
	}
}

@media only screen and (max-width: 800px) {
	#just-one-div:after {
		content: "800px - Samsung Galaxy II landscape";
	}
}

@media only screen and (max-width: 768px) {
	#just-one-div:after {
		content: "768px - iPad portrait";
	}
}

@media only screen and (max-width: 600px) {
	#just-one-div:after {
		content: "600px - Kindle Fire portrait";
	}
}

@media only screen and (max-width: 480px) {
	#just-one-div:after {
		content: "480px - iPhone landscape, Samsung Galaxy II portrait";
	}
}

@media only screen and (max-width: 320px) {
	#just-one-div:after {
		content: "320px - iPhone portrait";
	}
}

Kliknij aby zobaczyć przykład 2.

Zbudowaliśmy całkiem sensowne narzędzie do debugowania media queries. Wyświetlana jest aktualna szerokość przeglądarki i wybrane urządzenia, które maja taką szerokość ekranu.

Pełny kod przykładu 2 w pliku ZIP można pobrać tutaj.

Czas najwyższy żeby zacząć eksperymentować ze zmianami layoutu. Najprostszy i najczęściej używany układ elementów to zestaw składający się z nagłówka strony, stopki, główniej kolumny z treścia i sidebara.

Typowy layout

Typowy layout prostej strony internetowej

W serwisach responsywnych taki layout zmienia się przy mniejszej szerokości przeglądarki. Wszystkie elementy skalują się do pewnego momentu, aż w końcu sidebar przeskakuje pod kolumnę z treścią. Zobaczmy jak to się dzieje na prostym przykładzie. W kodzie HTML strony zdefiniujmy wszystkie potrzebne elementy:

<div id="wrap">
	<div id="header"></div>
	<div id="content"></div>
	<div id="sidebar"></div>
	<div id="footer"></div>
</div>

a następnie użyjmy odpowiedniego arkusza styli

body {
	background: #dedede;
}

div {
	background: #065AB1;
	color: white;

	border: none;
	padding: 0;
	margin: 0;
}

#wrap {
	width: 90%;
	float: none;
	margin: 0 auto;
	border: 0;
}

#header {
	float: left;
	width: 100%;
	margin: 0 0 20px 0;
}

#content {
	clear: both;
	width: 70%;
	float: left;
	margin: 0 5% 0 0;
}

#sidebar {
	width: 25%;
	float: right;
	margin: 0;
}

#footer {
	clear: both;
	float: left;
	width: 100%;
	margin: 20px 0 0 0;
}

#header:after  {	content: "header"; }
#content:after {	content: "content"; }
#sidebar:after {	content: "sidebar"; }
#footer:after  {	content: "footer"; }

@media only screen and (max-width: 800px) {
	#content {
		width: 100%;
	}

	#sidebar {
		clear: both;
		float: left;
		margin-top: 20px;
		width: 100%;
	}
}

Kliknij aby zobaczyć przykład 3.

Abu uprościć przykład nie wpisywaliśmy w poszczególne bloki żadnej treści. Zostały ustawione tylko niezbędne atrybuty.

Pełny kod przykładu 3 w pliku ZIP można pobrać tutaj.

Bardzo często robiąc responsywny serwis musimy się liczyć z dodatkowymi utrudnieniami. Jeżeli chcemy wyświetlać reklamę Google AdSense na sidebarze, nie powinien się on zwężać poniżej szerokości wybranej przez nas formy reklamowej (np. boksu 300 x 250). W takim wypadku będziemy musieli użyć atrybutu min-width i niestety poniżej pewnej szerokości nie możemy już liczyć na to, że sidebar i główna kolumna z treścią będą się skalować w stałej proporcji (w procentach). Często layout, który robimy ma więcej niż dwie kolumny, to również jest utrudnienie. Możemy też chcieć aby sidebar nie „spadał” w całości poniżej bloku z treścią, tylko żeby po zwężeniu strony jego część pojawiła się powyżej, a część poniżej. Ponieważ najczęściej zbudowanie dobrze zachowującego się layoutu responsywnego wymaga pewnej precyzji, zawsze należy zresetować wszystkie style.

Kolejny przykład pokazuje układ trójkolumnowy który adaptuje się do szerokości przeglądarki bez skalowania. Warto wrócić uwagę na zachowanie trzeciej kolumny, która poniżej szerokości 1024 piksli „spada” pod pierwsze dwie kolumny, ale dodatkowo dzieli się, i to w ten sposób, że zmienia się kolejność elementów.

Adaptacja layoutu trojkolumnowego

Kliknij aby zobaczyć przykład 4.

Pełny kod przykładu 4 w pliku ZIP można pobrać tutaj.

Wada takiej adaptacji bez żadnego skalowania jest to, że przy szerokościach pomiędzy granicznymi (tymi dla których określono media query) strona duże marginesy. Layout zaraz po złamaniu ma 50% pustej przestrzeni. Dlatego warto, żeby poszczególne elementy choć trochę się skalowały. Pokazujemy to w kolejnym przykładzie, gdzie ten sam layout nie tylko się tak samo adaptuje ale też skaluje.

Kliknij aby zobaczyć przykład 5.

Pełny kod przykładu 5 w pliku ZIP można pobrać tutaj.

Dlaczego RWD jest taki ważny

W swoich zaleceniach dla webmasterów Google opowiedział się zdecydowanie po stronie RWD, określając, że jest to najlepsza metoda na budowę serwisów dla urządzeń mobilnych, znacznie lepsza i bardziej pożądana niż tworzenie drugiej, mobilnej wersji. Dlaczego jest to rozwiązanie tak dobre, i wspierane przez liderów branży?

  • Przede wszystkim mamy zawsze jeden kod HTML, jedną strukturę strony, a zmieniają się tylko style. To znaczy, że nie tylko każda przeglądarka, ale też boty indeksujące widzą stronę zawsze w ten sam sposób. Serwis ma też zawsze ten sam zestaw linków wewnętrznych.
  • Poprawnie zrobiony serwis responsywny jest future ready – gotowy na przyszłe wyzwania, na nowe urządzenia, które się pojawią, na nowe rozdzielczości. Jest znacznie większa szansa, że nie „zestarzeje się” tak szybko.
  • Serwis responsywny wygląda dobrze nie tylko na różnych urządzeniach ale też dostosowuje swój wygląd do szerokości normalnej, desktopowej przeglądarki. Jeśli w danym momencie mamy ciasno na ekranie, korzystamy z wielu okien, możemy go zwęzić bez obawy, że pojawi się dolny scrollbar, który zabija natychmiast użyteczność każdej strony.
  • Przy dobrym podejściu i odrobinie wprawy RWD jest po prostu tani. Nie tylko dlatego, że taniej jest zrobić jeden serwis niż kilka – a to nasz czeka kiedy będziemy chcieli robić wersje dla różnych urządzeń – ale też dlatego, że później jest znacznie tańszy w utrzymaniu. Mamy po prostu tylko jeden serwis, w którym musimy dokonywać zmian. Koszt RWD rośnie i to nieliniowo jeśli dramatycznie rośnie skala komplikacji serwisu, liczba różnych stosowanych layoutów i ich komplikacja, czyli liczba użytych modułów i ich różnorodność. W jakimś momencie zapanowanie nad tym dla różnych szerokości zaczyna się zbliżać do punktu, w którym właściwie trzeba zrobić kilka oddzielnych projektów. Tylko, że powinniśmy sobie zadać pytania, skoro doszliśmy do takiego stanu – czy aby na pewno to, co robimy ma sens? Czy projekt naszego serwisu nie poszedł kompletnie „w maliny”? Stąd ostatnia z zalet RWD, którą chciałbym podkreślić:
  • Konieczność myślenia wieloma szerokościami i poradzenia sobie ze zmianami layoutu silnie dopinguje do robienia prostych i przejrzystych serwisów o jasnej strukturze i płaskiej nawigacji. Po okresie dominacji koszmarnie pogmatwanych i nabitych setkami modułów stron, to bardzo ważny trend.

O czym warto pamiętać  stosując Responsive Web Design

Serwis powinien zawsze wyglądać dobrze

Odruchem każdego, kto zabiera się za robienie strony w RWD jest ustalenie media queries dla typowych szerokości najpopularniejszych urządzeń (1024, 800, 768, 620, 480, 320). Chociaż nie musi to dać złych efektów, nie ma powodu, dla którego powinniśmy się tego trzymać. Powstaje coraz więcej nowych urządzeń mobilnych, lawinowo rośnie liczba nowych modeli tabletów, producenci prześcigają się w dogadzaniu różnym grupom użytkownikom manewrując często rozmiarami i rozdzielczością ekranu. Nawet jeśli dziś dominują jakieś rozdzielczości, raptem za pół roku może się okazać, że najpopularniejsze są już inne.

Pisałem już wyżej, że bardzo ważne jest także zachowanie serwisu responsywnego w zwykłej przeglądarce, a tu już nigdy nie wiemy jaki będzie wybór użytkownika. Dlatego punkty przełączenia styli powinny być dobrane zawsze tam gdzie zwężany lub poszerzany serwis zaczyna wyglądać źle. Wielu twórców stron RWD poleca rozpoczynanie od najwęższego możliwego layoutu i ustawianie punktów zmiany styli tam gdzie podczas rozszerzania zaczyna on się już źle prezentować

Nie należy ukrywać treści

Choć jest to oczywiście możliwe dzięki zastosowania display:none, nie należy prawie nigdy przy zmianie szerokości ukrywać elementów treściowych.

Nie wolno karać użytkowników urządzeń mobilnych ukrywając część informacji, po to aby prezentowane strony były mniejsze. Oczywiście jest jakimś problemem ładowanie strony takiej jak ta, z wieloma dużymi obrazkami na przykład na iPhonie, ale są inne sposoby żeby uczynić ją lżejszą (to temat na oddzielny tekst). Ukrywanie części treści jest złym wyborem.

Jak od każdej reguły i od tej są wyjątki. Jeśli na przykład miniatury obrazków przy wypisach z artykułów nie maja roli informacyjnej, a służą bardziej jako bullety czy po prostu dekoracja, możemy je ukryć dla najwęższych wersji layoutu (tak też robię na WPinternals). Możemy je ukryć dokładnie tak samo jak inne elementy wystroju strony, jeśli nie rujnuje to komunikacji strony.

RWD to nie wszystko

Tworząc strony dla różnych urządzeń należy pamiętać, że layout to nie wszystko. Poprzez odpowiednie API urządzeni te dają specyficzne dla siebie możliwości, i jeśli to jest możliwe strona powinna je wykorzystywać. Na telefonie komórkowym może to być dostęp do lokalizacji użytkownika, nawiązanie połączeni głosowego, interface dotykowy, itp.

Inne projektowanie

Projektowanie dobrych stron w RWD wymaga pewnej edukacji i zmiany przyzwyczajeń nie tylko u programistów. W znacznie większym stopniu muszą się dostosować projektanci WWW i graficy. Tu nie wystarczy już zrobić jednego PSD dopieszczonego do piksla. Trzeba sobie zdawać sprawę, które elementy naturalnie przeniosą się na layout responsywny, a które będą sprawić ogromne problemy. Mam nadzieję, że ten tekst w na tyle ludzki sposób przedstawia zagadnienie, że może służyć jako materiał wprowadzający również dla grafików i projektantów.