Jedną z największych trudności projektowania stron internetowych i interfejsów aplikacji internetowych jest podjęcie decyzji czy w danym przypadku wykorzystać szeroko wspieraną popularną i tradycyjną metodę rozwiązania konkretnego problemu czy wykorzystać innowację, która będzie funkcjonować tylko w nowszych przeglądarkach.

Zaletą stosowania tradycyjnych metod projektowania stron jest pewność, że zadziałają one:

  • w starszych (nie aktualizowanych) przeglądarkach
  • w starszych systemach operacyjnych
  • w mniej popularnych systemach operacyjnych i platformach
  • w starszych urządzeniach
  • w warunkach ograniczonej prędkości łącza internetowego

Jak można łatwo się domyślić, wadą jest poświęcenie wykorzystania możliwości najnowszych technologii, które często idzie z pewnym kompromisem i zrezygnowania z potencjalnie lepszych i bardziej unikalnych doświadczeń użytkownika, które są punktem wyjściowym opracowywania wszelkiego rodzaju innowacji. Przykładem takich innowacji mogą być mogą być:

  • animacje i wszelkie powiązane technologie takie jak canvas, WebGL, nowinki w CSS3,
  • formaty graficzne nowej generacji, które dostarczają lepszą (subiektywnie i obiektywnie) jakość obrazu i jednocześnie mniejsze zużycie transferu,
  • Rozszerzenia przeglądarek i technologii HTML5, np. localStorage, powiadomienia Web-Push, WEB SQL Database i tym podobne.

Progressive Enhancement rozwiązuje ten problem

Progressive enhancement, czyli progresywne (lub stopniowe) ulepszanie to filozofia i taka niejako strategia wprowadzania innowacji, która polega na tym, że projektując front-end strony internetowej w pierwszej kolejności kładzie się nacisk na podstawową zawartość i podstawowe funkcjonalności a następnie na zasadzie opcjonalnych rozszerzeń stopniowo dodaje się bardziej dopracowane i technicznie bardziej wymagające i bardziej wyrafinowane warstwy prezentacji na jakie pozwala urządzenie i oprogramowanie klienckie.

Proponowane zalety tej strategii to fakt, że umożliwia się każdemu dostęp do podstawowej zawartości i funkcjonalności strony internetowej przy użyciu dowolnej przeglądarki lub nawet bardzo powolnego połączenia internetowego, serwując ulepszoną wersję tylko tym, którzy mają bardziej zaawansowane oprogramowanie przeglądarki, większą przepustowość lub sprzęt o wyższych możliwościach.

Jak inaczej można radzić sobie z problemami tzw. krzyżowej kompatybilności?

Polyfill

W tworzeniu stron internetowych polyfill to kod, który implementuje dodatkowe funkcje do wykonania w starszych przeglądarkach internetowych (lub także nowych, które z jakieś przyczyny natywnie nie wspierają konkretnej funkcji). Pozdrowienia dla Internet Explorer 🙂

Polyfill najczęściej odnosi się to do biblioteki JavaScript, lub dodatkowej funkcji, która implementuje fragmenty standardu HTML5, albo inny konkretny standard. Formalnie „polyfill to podkładka pod interfejs API przeglądarki”. Niejako „zmusza się” starsze przeglądarki to wykorzystania nowej funkcji.

Biblioteki np. jQuery

Jednym z dodatkowych rozwiązań jest wykorzystanie jQuery, czyli pisząc kod stosujemy nieco wyższą abstrakcję – w ten sposób też można zapewnić funkcje, które były by trudniejsze do wykonania w Vanilla JS (czyli w czystym JavaScript) tak, aby były szeroko wspierane przez przeglądarki.

Przykłady praktyk zgodnych ze stopniowym ulepszaniem

Przykład #1: Kolejność reguł CSS

Jednym z prostszych przykładów jest umiejętne pisanie stylu CSS. Nowością w CSS3 jest format zapisu barw w postaci rgba, w którym możemy wykorzystać kanał alfa, dzięki któremu uzyskujemy efekt stopniowanej przezroczystości.

Jedną z najlepszych rzeczy w CSS (odróżniającą go od większości innych języków skryptowych lub interpretowanych) jest fakt, że jeżeli napiszemy instrukcję niezrozumiałą dla przeglądarki, ta pomija ją i przechodzi do następnej instrukcji.

Dlatego, kiedy doświadczony front-end deweloper chce wykorzystać rgba w swoim kodzie skorzysta z filozofii progressive enhancement i najpierw zapisze wartość barwy w standardowy sposób czyli heksadecymalnie (w systemie szesnastkowym) a dopiero potem wykorzysta jakąś nowość, która może małemu odsetkowi użytkowników zwyczajnie nie zadziałać: 

.article-content h2 {
     color: #888;   
     color: rgba(0.5,0.5,0.5,0.85); 
}

Dzięki temu nowoczesna przeglądarka zastosuję drugą linijkę a ta, która nie obsługuje rgba pozostanie przy pierwszej linijce. Efekt wizualny będzie co prawda inny, ale dzięki takiemu zabiegowi możemy pogodzić ograniczenia przeglądarek, które nie wspierają rgba i nie rezygnować przy tym z dostarczenia użytkownikom nowoczesnych przeglądarek nowoczesnych efektów i idealnego odwzorowania barw. Z podobną sytuacją mamy w przypadku gradientów:

background: #c7ff47;
background: linear-gradient(to bottom, #c7ff47 0%,#2c7707 100%);

W nowej wersji CSS można wykorzystać linear-gradient do tworzenia gradientów. Podobnie jak w poprzednim przykładzie, wykorzystanie podejścia zgodnego z progressive enhancement będzie polegało na ustawieniu najpierw uśrednionej barwy dla tła, który zastosują przeglądarki niewspierające gradientów.

Przykład #2: Nowe tagi HTML5 i formaty graficzne nowej generacji

Jak wspomniałem w optymalizacji zdjęć, format WebP to bardzo wydajny format, który godzi przezroczystość, możliwość animacji, wysoką jakość wizualną zdjęcia i mały rozmiar. Niestety, nie jest szeroko wspierany przez przeglądarki. Np. do tej pory są problemy z wyświetlaniem zdjęć w Safari i w Internet Explorer/Edge.

To powoduje że WebP jest jeszcze rzadko wykorzystywany z obawy przed problemami wynikającymi ze wspomnianym brakiem wsparcia. Na szczęście istnieje rozwiązanie zgodne z progressive enhancement, dzięki którym wykorzystamy potencjał WebP w nowoczesnych przeglądarkach i pogodzimy ograniczenia posiadaczy przegladarek, które nie wyświetlają zdjęć zapisanych w formacie WebP. Wygląda to tak:

<picture> 
	<source type="image/webp" srcset="obrazek-300.webp 300w, obrazek-600.webp 600w, obrazek-800.webp 800w"> 
	<source srcset="obrazek-300.png 300w, obrazek-600.png 600w, obrazek-800.png 800w">
	<img src="obrazek.png" alt="Obrazek"> 
 </picture>

Jak można się domyślić, przeglądarka wspierająca WebP wykorzysta plik w formacie WebP, (bo jest wyżej) natomiast w przypadku braku wsparcia, przeglądarka pobierze zasób z kolejnego źródła, tak aż w końcu natrafi na format, który obsługuje.

Podobnie wygląda stosowanie video. Tutaj też użyjemy zapytań medialnych aby serwować różną wielkość dla różnych rozdzielczości CSS:

<video> 
   <source src="filmik-small.mp4" type="video/mp4" media="all and (max-width: 480px)"> 
   <source src="filmik-small.webm" type="video/webm" media="all and (max-width: 480px)"> 
   <source src="filmik.webm" type="video/webm">
   <source src="filmik.mp4" type="video/mp4">
</video>

Przykład #3: Mechanizm Single Page Application

Zamiast tworzyć wymyślne techniki asynchronicznego ładowania danych w tronach o architekturze SPA, można użyć mechanizmu jaki zaproponowałem w przewodniku dotyczącym programowania Single Page Applications.

W wielkim skrócie, całość działa tak, że każda strona jest niezależną podstroną. w przypadku kliknięcia na link, za pomocą JavaSriptu jest blokowane przejście na nową stronę, a mechanizm load() załaduje treść kontenera treści do aktualnej podstrony. Następnie aktualizujemy ścieżkę w pasku adresu i obsługujemy przyciski „wstecz” i „dalej”. Wyłączając JavaScript, podstrony będą się zmieniać standardowo – synchronicznie. Jest to najdobitniejszy przykład poprawnie zastosowanej idei Progressive Enhancement, gdzie dodatkowa warstwa funkcji zwiększa jakość doświadczeń na zaawansowanych urządzeniach nie poświęcając kompatybilności z przeglądarkami, które z jakichś powodów w ogóle nie obsługują JavaScriptu. Oczywiście mechanizm zaproponowany w tutorialu wymaga także innych dodatkowych udoskonaleń.

Przykład #4: Nawigacja na stronie One-Page

W przewodniku dotyczącym tworzenia stron one-page zaproponowano nawigację, która przechowuje w atrybucie href identyfikatory sekcji do których widok ma być przewinięty. Korzystamy wówczas ze standardowej funkcji linków z haszem. Przeglądarka przesuwa widok do konkretnego kontenera nawet wtedy, kiedy jest wyłączona obsługa JavaScript.
Podobnie jak w poprzednim przykładzie – dopiero po dodaniu szeroko wspieranej techniki nawigacji dodajemy animowany efekt przewijania do konkretnej sekcji, który zadziała w przeglądarkach z włączoną obsługą JavaScript.

Wady progressive enhancement

Czy podejście to ma jakieś wady? Ma, co można wywnioskować nawet z tych trywialnych przykładów, które przytoczyłem:

  • nadmiarowy kod
  • nadmiarowa ilość zasobów
  • większy koszt stworzenia aplikacji

Podsumowanie

Progressive enhancement to dobre rozwiązanie, które pomaga pogodzić nowoczesne rozwiązania z potrzebami starszych platform. Tak jak wszędzie i tutaj przyda się racjonalność i skupienie na nadrzędnym celu. Warto wdrażać w ten sposób rozwiązania, które dadzą relatywnie sporą korzyść. Przykładem może być stworzenie alternatywnych zasobów dla sporych grafik PNG (które wykorzystują przezroczystość) w postaci WebP.

Z progressive enhancement jak z każdym ulepszaniem można przesadzić i doprowadzić do tzw. przeinżynierowania. Jeżeli na każdym kroku będziemy stosować to podejście to nadmierny wzrost kodu będzie utrudniał rozwój projektu a tym samym zwiększy jego koszt utrzymania.

Źródła

Frain B., Responsive Web Design with HTML5 and CSS3, Packt Publishing, 2012.

Oceń artykuł na temat: Co to jest progressive enhancement?
Średnia : 4.8 , Maksymalnie : 5 , Głosów : 17