Korzystałem z sieci przez jeden dzień w przeglądarce Internet Explorer 8

Ten artykuł jest częścią serii, w której staram się korzystać z sieci pod różnymi ograniczeniami, reprezentując daną grupę demograficzną użytkownika. Mam nadzieję podnieść rangę trudności, z jakimi borykają się prawdziwi ludzie, których można uniknąć, jeśli projektujemy i rozwijamy się w sposób zgodny z ich potrzebami.

Ostatnim razem przez jeden dzień nawigowałem po Internecie za pomocą czytnika ekranu. Tym razem spędziłem dzień korzystając z Internet Explorera 8, który został wydany dziesięć lat temu, 19 marca 2009 roku.

Kto na świecie używa IE8?

Zanim zaczniemy; zastrzeżenie: nie powiem ci, że musisz zacząć wspierać IE8.

Istnieją wszelkie powody, aby nie obsługiwać IE8. Microsoft oficjalnie przestał wspierać IE8, IE9 i IE10 ponad trzy lata temu, a kierownictwo Microsoftu mówi nawet, żebyś przestał używać Internet Explorera 11.

Ale o ile my, programiści, mamy nadzieję, że to zniknie, to po prostu. Przyzwyczajenie. Zgiń . IE8 nadal pojawia się w statystykach przeglądarek, zwłaszcza poza bańką świata zachodniego.

Statystyki przeglądarek należy traktować z przymrużeniem oka, ale obecne szacunki dotyczące użycia IE8 na całym świecie wynoszą około 0,3% do 0,4% udziału w rynku komputerów stacjonarnych. Dolny koniec oszacowania pochodzi z w3counter:

Wyższe oszacowanie pochodzi ze StatCounter (ten sam plik danych, który jest używany w tabeli użycia „Czy mogę użyć”). Szacuje, że globalny udział przeglądarek IE8 na komputery stacjonarne wynosi około 0,37%.

Podejrzewałem, że możemy zaobserwować większe wykorzystanie IE8 w niektórych regionach geograficznych, więc dane zostały przeanalizowane według kontynentów.

Wykorzystanie IE8 według regionu

Oto proporcja komputerów stacjonarnych IE8 na kontynent (dane od lutego 2018 do stycznia 2019):

Ktoś w Azji jest pięć razy bardziej skłonny do korzystania z IE8 niż ktoś z Oceanii.

Przyjrzałem się dokładniej statystykom azjatyckim, zwracając uwagę na proporcje użycia IE8 dla każdego kraju. Istnieje bardzo wyraźna lista sześciu krajów z największą liczbą zastosowań IE8, po których liczby spadają do poziomu porównywalnego ze średnią światową:

Dane te są podsumowane na poniższej mapie:

To niewiarygodne, że IE8 stanowi około 4% użytkowników komputerów stacjonarnych w Iranie — czterdziestokrotność liczby użytkowników IE8 w Oceanii.

Następnie przyjrzałem się statystykom krajów dla Afryki, ponieważ miała ona mniej więcej takie samo ogólne wykorzystanie IE8 jak Azja. Był wyraźny zwycięzca (Erytrea), a następnie kilka krajów powyżej lub w pobliżu znaku użycia 1%:

Jest to podsumowane na poniższej mapie:

Podczas gdy kraje w Azji, które mają wyższe niż normalne użycie IE8, są z grubsza pogrupowane geograficznie, nie wydaje się, aby istniał wzór w Afryce. Jedyny wzorzec, jaki widzę — chyba że to przypadek — to fakt, że wiele największych na świecie przeglądarek IE8, które używają krajów, które słynie z cenzurowania dostępu do Internetu, prawdopodobnie nie zachęcają ani nie zezwalają na aktualizację do bezpieczniejszych przeglądarek.

Jeśli Twoja witryna jest skierowana do odbiorców czysto zachodnich, prawdopodobnie nie będzie Cię przejmować IE8. Jeśli jednak masz rozwijający się rynek azjatycki lub afrykański — a szczególnie jeśli zależy Ci na użytkownikach w Chinach, Iranie lub Erytrei — możesz bardzo zainteresować się doświadczeniem IE8 swojej witryny. Tak — nawet w 2019 roku!

Kto nadal korzysta z IE?

Kim więc są ci ludzie? Czy naprawdę chodzą wśród nas?!

Kimkolwiek są, możesz się założyć, że nie używają starej przeglądarki tylko po to, by Cię zirytować. Nikt celowo nie wybiera gorszego sposobu przeglądania.

Ktoś może używać starej przeglądarki z następujących powodów:

• Brak świadomości
  Po prostu nie zdają sobie sprawy, że używają przestarzałej technologii.
• Nieuctwo
  Nie znają opcji aktualizacji i alternatywnych przeglądarek, które są dla nich otwarte.
• Brak planowania
  Odrzucam monity o uaktualnienie, ponieważ są zajęte, ale nie mają przewidywania, aby uaktualnić w cichszych okresach.
• Niechęć do zmian
  Ostatnim razem, gdy aktualizowali swoje oprogramowanie, musieli nauczyć się nowego interfejsu użytkownika. „Jeśli nie jest zepsuty, nie naprawiaj tego”.
• Niechęć do ryzyka
  Podczas ostatniej aktualizacji ich maszyna zwolniła do pełzania lub utracili swoją ulubioną funkcję.
• Ograniczenia oprogramowania
  Ich system operacyjny jest zbyt stary, aby umożliwić im uaktualnienie, lub ich uprawnienia administratora mogą zostać zablokowane.
• Ograniczenia sprzętowe
  Nowsze przeglądarki generalnie bardziej wymagają miejsca na dysku twardym, pamięci i procesora.
• Ograniczenie sieci
  Ograniczony limit danych lub wolne połączenie oznaczają, że nie chcą pobierać 75 MB oprogramowania.
• Ograniczenie prawne
  Mogą znajdować się na komputerze firmowym, który zezwala na korzystanie tylko z jednej konkretnej przeglądarki.

Czy to naprawdę taka niespodzianka, że ​​wciąż są ludzie na całym świecie, którzy trzymają się IE8?

Postanowiłem postawić się w sytuacji jednej z tych anonimowych dusz i przeglądać sieć przez jeden dzień za pomocą IE8. Możesz grać razem w domu! Pobierz maszynę wirtualną „IE8 w systemie Windows 7” z witryny Microsoft, a następnie uruchom ją w wirtualizatorze, takim jak VirtualBox.

IE8 VM: początek złego startu

Uruchomiłem swoją maszynę wirtualną IE8, w oczekiwaniu kliknąłem program Internet Explorer i oto, co zobaczyłem:

Hmm, dobrze. Wygląda na to, że domyślna strona internetowa uruchomiona przez IE8 już nie istnieje. Cóż, to liczby. Microsoft oficjalnie przestał wspierać IE8, więc dlaczego miałby się upewnić, że strona docelowa IE8 nadal działa?

Zdecydowałem się przejść do najczęściej używanej witryny na świecie.

Google

Jest to prosta strona, dlatego trudno się pomylić — ale szczerze mówiąc, wygląda świetnie! Próbowałem czegoś szukać:

Wyszukiwanie działało dobrze, chociaż układ wygląda nieco inaczej niż ten, do którego jestem przyzwyczajony. Wtedy przypomniałem sobie — widziałem ten sam układ wyników wyszukiwania, kiedy korzystałem z Internetu przez jeden dzień z wyłączonym JavaScriptem.

Dla porównania, oto jak wyglądają wyniki wyszukiwania w nowoczesnej przeglądarce z włączoną obsługą JavaScript:

Wygląda więc na to, że IE8 pobiera wersję wyszukiwarki Google bez JS. Nie sądzę, że była to koniecznie świadoma decyzja projektowa — możliwe, że po prostu wystąpił błąd JavaScript:

Mimo to wynik końcowy jest dla mnie w porządku — mam wyniki wyszukiwania, a to wszystko, czego chciałem.

Kliknąłem, aby obejrzeć film na YouTube.

Youtube

Na tej stronie jest sporo zepsutych. Wszystko związane z małymi dziwactwami w IE.

Na przykład logo jest powiększane i przycinane. Wynika to z tego, że IE8 nie obsługuje SVG, a tak naprawdę widzimy opcję awaryjną udostępnianą przez YouTube. Zastosowali właściwość CSS background-image , dzięki czemu w przypadku braku obsługi SVG, otrzymasz próbę wyświetlenia logo. Tylko, że wydaje się, że nie ustawili prawidłowo background-size , więc jest to trochę za duże przybliżenie.

Dla porównania, oto ta sama strona w Chrome (zobacz, jak Chrome renderuje SVG zamiast):

A co z przełącznikiem autoodtwarzania? Jest renderowany jak dziwnie wyglądające pole wyboru:

Wydaje się, że jest to spowodowane użyciem niestandardowego elementu (przycisku przełączania papieru, który jest elementem Material Design), którego IE nie rozumie:

Nie dziwię się, że to nie zostało poprawnie wyrenderowane; IE8 nie radzi sobie nawet z podstawowymi znacznikami semantycznymi, których używamy w dzisiejszych czasach. Spróbuj użyć <aside> lub <main> , a zasadniczo wyrenderuje je jako div, ale ignoruj ​​wszelkie zastosowane do nich style.

Aby włączyć znaczniki HTML5, musisz wyraźnie poinformować przeglądarkę, że te elementy istnieją. Można je następnie stylizować w normalny sposób:

 <!--[if lt IE 9]> <script> document.createElement('header'); document.createElement('nav'); document.createElement('section'); document.createElement('article'); document.createElement('aside'); document.createElement('footer'); </script> <![endif]-->

Nawiasem mówiąc, jest to zawarte w warunku IE. <!--[if lt IE 9]> to komentarz HTML do większości przeglądarek — i dlatego jest pomijany — ale w IE jest to warunek warunkowy, który przekazuje tylko „jeśli mniej niż IE 9”, gdzie wykonuje/renderuje węzły DOM w nim.

Tak więc strona wideo była porażką. Bezpośrednie odwiedzenie YouTube.com nie poszło znacznie lepiej:

Niezrażony zignorowałem ostrzeżenie i spróbowałem wyszukać film w pasku wyszukiwania YouTube.

Ruch IE8 jest na tyle podejrzany, że YouTube nie ufał, że jestem prawdziwym użytkownikiem, i postanowił nie przetwarzać mojego żądania wyszukiwania!

Rejestracja w Gmailu

Jeśli mam spędzić dzień na IE8, będę potrzebować adresu e-mail. Więc zabieram się za założenie nowego.

Przede wszystkim spróbowałem Gmaila.

Jest tu coś nie tak z obrazem i tekstem. Myślę, że wynika to z faktu, że IE8 nie obsługuje zapytań o media — więc próbuje pokazać mi obraz mobilny na komputerze.

Jednym ze sposobów na obejście tego jest użycie Sassa do wygenerowania dwóch arkuszy stylów; jeden dla nowoczesnych przeglądarek, a drugi dla starszego IE. Możesz uzyskać CSS przyjazny dla IE, skierowany do urządzeń mobilnych (zobacz samouczek Jake'a Archibalda), używając domieszki dla zapytań o media. Mieszanka „spłaszcza” twój stary IE CSS, aby traktować IE tak, jakby zawsze miał określoną predefiniowaną szerokość (np. 65em), dając tylko odpowiedni CSS dla tej szerokości. W tym przypadku widziałbym prawidłowy background-image dla mojego zakładanego rozmiaru ekranu i miałbym lepsze wrażenia.

W każdym razie nie powstrzymało mnie to od kliknięcia „Utwórz konto”. Było kilka różnic między wyglądem w IE8 a nowoczesną przeglądarką:

Choć na pierwszy rzut oka był obiecujący, formularz był dość błędny do wypełnienia. „Etykieta” nie znika, gdy zaczynasz wypełniać pola, więc tekst wejściowy jest zaciemniony:

Znacznik dla tej etykiety to w rzeczywistości <div> , a jakiś sprytny JS usuwa tekst z drogi, gdy wejście jest skupione. JS nie działa na IE8, więc tekst uparcie pozostaje na swoim miejscu.

Po uzupełnieniu wszystkich danych kliknąłem „Dalej” i czekałem. Nic się nie stało.

Potem zauważyłem mały żółty symbol ostrzegawczy w lewym dolnym rogu mojego okna IE. Kliknąłem i zobaczyłem, że narzeka na błąd JS:

Zrezygnowałem z Gmaila i zwróciłem się do MSN.

Rejestracja w Hotmailu

Zaczynałem się martwić, że poczta elektroniczna może być niedostępna dla dziesięcioletniej przeglądarki. Ale kiedy wszedłem do Hotmail, formularz rejestracyjny wyglądał OK – jak dotąd tak dobrze:

Wtedy zauważyłem CAPTCHA. Pomyślałem: „Nie ma mowy, żebym przez to przebrnął…”

Ku mojemu zaskoczeniu CAPTCHA zadziałała!

Jedyną dziwaczną rzeczą w formularzu było nieco błędne pozycjonowanie etykiet, ale rejestracja była poza tym bezproblemowa:

Czy ten zrzut ekranu wygląda dobrze dla ciebie? Czy potrafisz dostrzec celowy błąd?

Skrajnie po lewej stronie powinno być moje imię , a nie nazwisko. Kiedy wróciłem i sprawdziłem tę stronę później, kliknąłem etykietę „Imię” i ustawiłem fokus na lewe wejście, w ten sposób mogłem najpierw sprawdzić, czy wypełniam właściwe pole. To pokazuje , jak ważne są dostępne znaczniki — nawet bez CSS i wizualnego powiązania mogłem dokładnie określić, które pole wejściowe zostało zastosowane do której etykiety (choć za drugim razem!).

W każdym razie udało mi się ukończyć proces rejestracji i zostałem przekierowany na stronę główną MSN, co było świetne.

Mogłem nawet czytać artykuły i zapomnieć, że używam IE8:

Po zarejestrowaniu mojego adresu e-mail byłem gotowy, aby przejść i sprawdzić resztę Internetu!

Facebook

Odwiedziłem stronę na Facebooku i od razu zostałem przekierowany na stronę mobilną:

Jest to sprytna taktyka awaryjna, ponieważ Facebook musi wspierać dużą globalną publiczność na słabszych urządzeniach mobilnych, więc i tak musisz zapewnić podstawową wersję Facebooka. Dlaczego nie zaoferować tej samej linii bazowej doświadczenia starszym przeglądarkom na komputery stacjonarne?

Próbowałem się zarejestrować i udało mi się założyć konto. Świetnie! Ale kiedy zalogowałem się na to konto, potraktowano mnie podejrzliwie — tak jak podczas wyszukiwania rzeczy na YouTube — i spotkałem się z CAPTCHA.

Tylko że tym razem nie było tak łatwo.

Kilka razy próbowałem poprosić o nowe kody i odświeżyć stronę, ale obraz CAPTCHA nigdy się nie załadował, więc zostałem skutecznie zablokowany z mojego konta.

No cóż. Spróbujmy więcej mediów społecznościowych.

Świergot

Odwiedziłem witrynę Twittera i miałem dokładnie takie same wrażenia z przekierowań mobilnych.

Ale tym razem nie mogłem nawet dojść do zarejestrowania konta:

Co dziwne, Twitter cieszy się, że możesz się zalogować, ale nie, żebyś się zarejestrował w pierwszej kolejności. Nie jestem pewien dlaczego — być może ma podobny scenariusz CAPTCHA na swoich stronach rejestracji, który nie działa w starszych przeglądarkach. Tak czy inaczej, nie będę mógł założyć nowego konta.

Czułem się niezręcznie, logując się za pomocą mojego istniejącego konta na Twitterze. Nazwij mnie paranoikiem, ale luki, takie jak atak CFR Watering Hole z 2013 r. — gdzie samo odwiedzenie określonego adresu URL w IE8 powodowało zainstalowanie złośliwego oprogramowania na twoim komputerze — niepokoiło mnie, że mogę włamać się na moje konto.

Ale w trosce o edukację wytrwałam (z tymczasowym nowym hasłem):

Mógłbym też tweetować, aczkolwiek używając bardzo podstawowego <textarea> :

Podsumowując, Twitter jest w zasadzie w porządku w IE8 — o ile masz już konto!

Skończyłem na ten dzień z mediami społecznościowymi. Sprawdźmy kilka nowości.

wiadomości BBC

Strona główna wiadomości wygląda bardzo prosto i nieporęcznie, ale w zasadzie działa — aczkolwiek z ostrzeżeniami dotyczącymi bezpieczeństwa mieszanej zawartości.

Spójrz na logo. Jak już widzieliśmy na YouTube, IE8 nie obsługuje SVG, więc potrzebujemy powrotu do formatu PNG.

BBC używa techniki zastępczej <image> do renderowania PNG w IE:

…i zignorować PNG, gdy dostępny jest SVG:

Ta technika wykorzystuje fakt, że starsze przeglądarki były posłuszne zarówno tagom <image> , jak i <img> , a więc ignorują nieznany tag <svg> i renderują kod zastępczy, podczas gdy nowoczesne przeglądarki ignorują renderowanie <image> w SVG. Chris Coyier bardziej szczegółowo wyjaśnia tę technikę.

Próbowałem obejrzeć artykuł:

Jest czytelny. Widzę nagłówek, nawigację, polecany obraz. Ale brakuje pozostałych obrazów artykułu:

Należy się tego spodziewać i jest to spowodowane leniwym ładowaniem obrazów BBC. IE8, który nie jest „obsługiwaną przeglądarką”, oznacza, że ​​nie otrzymuje JavaScript, który umożliwia leniwe ładowanie, dzięki czemu obrazy w ogóle się nie ładują.

Z zainteresowania, pomyślałem, że zobaczę, co się stanie, jeśli spróbuję uzyskać dostęp do BBC iPlayer:

I to sprawiło, że zacząłem się zastanawiać nad kolejną usługą przesyłania strumieniowego.

Netflix

W połowie spodziewałem się pustej białej strony, kiedy załadowałem Netflix w IE8. Byłem mile zaskoczony, gdy faktycznie zobaczyłem przyzwoitą stronę docelową:

Porównałem to z nowoczesną wersją Chrome:

Istnieje nieco inne wezwanie do działania (tekst przycisku) — prawdopodobnie sprowadza się do testowania na wielu odmianach, a nie do używanej przeglądarki.

To, co wyróżnia renderowanie, to scentralizowany tekst i półprzezroczysta czarna nakładka.

Brak scentralizowanego tekstu jest spowodowany użyciem przez Netflix Flexbox do wyrównywania elementów:

text-align: center w tej klasie prawdopodobnie naprawiłoby centrowanie dla IE8 (i rzeczywiście wszystkich starych przeglądarek). Aby uzyskać maksymalną obsługę przeglądarek, możesz zastosować podejście zastępcze CSS ze starym „bezpiecznym” CSS, a następnie zaostrzyć układy za pomocą bardziej nowoczesnego CSS dla przeglądarek, które to obsługują.

Brak tła jest spowodowany użyciem rgba() , która nie jest obsługiwana w IE8 i starszych.

Tradycyjnie dobrze jest zapewnić takie zastępcze CSS, które pokazują czarne tło dla starych przeglądarek, ale pokazują półprzezroczyste tło dla nowoczesnych przeglądarek:

 rgb(0, 0, 0); /* IE8 fallback */ rgba(0, 0, 0, 0.8);

Jest to poprawka bardzo specyficzna dla IE, jednak w zasadzie każda inna przeglądarka obsługuje rgba . Co więcej, w tym przypadku całkowicie stracisz fantazyjne kafelki Netflix, więc lepiej byłoby w ogóle nie mieć filtra tła! Najpewniejszym sposobem zapewnienia obsługi w różnych przeglądarkach byłoby umieszczenie filtra w samym obrazie tła. Proste ale efektywne.

W każdym razie, jak dotąd, tak dobrze — IE8 faktycznie renderował stronę główną całkiem dobrze! Czy rzeczywiście będę dzisiaj oglądać Breaking Bad na IE8?

Mój i tak już niepewny optymizm został natychmiast zgaszony, gdy zobaczyłem stronę logowania:

Mimo to udało mi się zalogować i zobaczyłem zmniejszoną deskę rozdzielczą (bez fantazyjnych zwiastunów z automatycznym rozwijaniem):

Kliknąłem program z niejasnym oczekiwaniem, ale oczywiście zobaczyłem tylko czarny ekran.

Amazonka

Ok, media społecznościowe i wideo są niedostępne. Pozostało tylko iść na zakupy.

Sprawdziłem Amazon i byłem zachwycony — jest to prawie nie do odróżnienia od doświadczenia, jakie można uzyskać w nowoczesnej przeglądarce:

Już wcześniej wciągnęła mnie dobra strona internetowa. Kliknijmy więc na stronę produktu i zobaczmy, czy to tylko przypadek.

Nie! Strona produktu również wyglądała dobrze!

Amazon nie był jedyną witryną, która zaskoczyła mnie swoją wsteczną kompatybilnością. Wikipedia wyglądała świetnie, podobnie jak strona rządu Gov.UK. Nie jest łatwo mieć stronę, która w IE8 nie wygląda jak zupełny wypadek samochodowy. Większość moich doświadczeń była zdecydowanie mniej dopracowana…!

Ale przestarzałe ostrzeżenie lub dziwny układ nie były najgorszą rzeczą, jaką dziś widziałem.

Całkowicie uszkodzone witryny

Niektóre strony były tak zepsute, że nawet nie mogłem się z nimi połączyć!

Zastanawiałem się, czy może to być tymczasowy problem z siecią VM, ale zdarzało się to za każdym razem, gdy odświeżałem stronę, nawet gdy wracałem do tej samej witryny później w ciągu dnia.

Zdarzyło się to w kilku różnych witrynach w ciągu dnia i ostatecznie doszedłem do wniosku, że nigdy nie wpłynęło to na witryny HTTP — tylko na HTTPS (ale nie na wszystkie witryny HTTPS). Więc jaki był problem?

Używając Wireshark do analizy ruchu sieciowego, ponownie spróbowałem połączyć się z GitHub. Widzimy, że połączenie nie zostało nawiązane z powodu błędu krytycznego „Opis: Wersja protokołu”.

Patrząc na ustawienia domyślne w IE8, włączony jest tylko TLS 1.0 — ale GitHub zrezygnował z obsługi TLSv1 i TLSv1.1 w lutym 2018 roku.

Zaznaczyłem pola dla TLS 1.1 i TLS 1.2, przeładowałem stronę i — voila! — Udało mi się wyświetlić GitHub!

Wielkie dzięki dla mojego niezwykle utalentowanego przyjaciela Aidana Fewstera za pomoc w rozwiązaniu tego problemu.

Jestem za kompatybilnością wsteczną, ale to stanowi interesujący dylemat. Według Rady Standardów Bezpieczeństwa PCI, TLS 1.0 jest niepewny i nie powinien być dłużej używany. Jednak wymuszając TLS 1.1 lub nowszy, niektórzy użytkownicy będą niezmiennie zablokowani (i prawdopodobnie nie wszyscy będą wystarczająco obeznani z technologią, aby włączyć TLS 1.2 w swoich zaawansowanych ustawieniach).

Pozwalając starszym, niezabezpieczonym standardom i umożliwiając użytkownikom dalsze łączenie się z naszymi witrynami, nie pomagamy im — krzywdzimy ich, nie dając im powodu do przejścia na bezpieczniejsze technologie. Jak daleko powinieneś się posunąć we wspieraniu starszych przeglądarek?

Jak rozpocząć obsługę starszych przeglądarek?

Kiedy niektórzy ludzie myślą o „wspieraniu starszych przeglądarek”, mogą myśleć o tych zastrzeżonych starych hackach do IE, na przykład w tym czasie BBC musiało zrobić niewiarygodnie drastyczne rzeczy, aby obsługiwać zawartość iframed w IE7.

Lub mogą myśleć o tym, aby coś działało w „trybie dziwacznym” Internet Explorera; tryb działania specyficzny dla IE, który przedstawia rzeczy bardzo odmiennie od standardów.

Ale „obsługa starszych przeglądarek” bardzo różni się od „hakowania dla IE”. Nie opowiadam się za tym drugim, ale powinniśmy pragmatycznie postarać się o to pierwsze. Mantra, którą staram się żyć jako programista stron internetowych, jest następująca:

„Optymalizuj dla większości, podejmij wysiłek dla mniejszości i nigdy nie poświęcaj bezpieczeństwa”.

Zamierzam teraz odejść od świata IE8 i porozmawiać o ogólnych, zrównoważonych rozwiązaniach dla wsparcia starszych przeglądarek.

Istnieją dwie ogólne strategie obsługi starszych przeglądarek, obie zaczynające się na literę P:

1. Polifilling
   Dążyć do identyczności funkcji dla wszystkich, wypełniając brakujące funkcje przeglądarki.
2. Progresywne ulepszanie
   Zacznij od podstawowego środowiska, a następnie użyj funkcji wykrywania funkcji, aby nałożyć warstwę na funkcjonalność.

Strategie te nie wykluczają się wzajemnie; mogą być używane w tandemie. W każdym podejściu należy podjąć szereg decyzji dotyczących implementacji, każda z własnymi niuansami, które omówię bardziej szczegółowo poniżej.

Polifilling

W przypadku niektórych witryn lub stron internetowych JavaScript jest bardzo ważny dla funkcjonalności i po prostu chcesz dostarczać działający JavaScript do jak największej liczby przeglądarek.

Jest na to kilka sposobów, ale najpierw lekcja historii.

Krótka historia ECMAScript

ECMAScript jest standardem, a JavaScript jest jego implementacją. Oznacza to, że ES5 to „ECMAScript w wersji 5”, a ES6 to „ECMAScript w wersji 6”. Co mylące, ES2015 jest taki sam jak ES6.

ES6 była popularną nazwą tej wersji przed jej wydaniem, ale ES2015 jest oficjalną nazwą, a kolejne wersje ECMAScript są powiązane z ich rokiem wydania.

Uwaga : Wszystko to zostało wyjaśnione przez Brandona Morelli w świetnym poście na blogu, który wyjaśnia pełną historię wersji JavaScript.

W chwili pisania tego tekstu najnowszym standardem jest ES2018 (ES9). Większość nowoczesnych przeglądarek obsługuje przynajmniej ES2015. Prawie każda przeglądarka obsługuje ES5.

Technicznie rzecz biorąc, IE8 to nie ES5. Nie jest to nawet ES4 (którego nie ma — projekt został porzucony). IE8 używa implementacji Microsoft ECMAScript 3, zwanej JScript. IE8 ma pewne wsparcie dla ES5, ale został wydany kilka miesięcy przed opublikowaniem standardów ES5, więc ma niedopasowanie obsługi.

Transpiling vs Polyfilling

Możesz napisać JavaScript ES5 i będzie on działał w prawie każdej starożytnej przeglądarce:

 var foo = function () { return 'this is ES5!'; };

Możesz także kontynuować pisanie całego JavaScriptu w ten sposób — aby na zawsze zapewnić kompatybilność wsteczną. Ale traciłbyś nowe funkcje i cukier składniowy, które stały się dostępne w rozwijających się wersjach JavaScript, co pozwala na pisanie takich rzeczy jak:

 const foo = () => { return 'this is ES6!'; };

Spróbuj uruchomić ten JavaScript w starszej przeglądarce, a wystąpi błąd. Musimy przetranspilować kod do wcześniejszej wersji JavaScript, którą zrozumie przeglądarka (tj. przekonwertować nasz kod ES6 na ES5 przy użyciu zautomatyzowanych narzędzi).

Załóżmy teraz, że nasz kod używa standardowej metody ES5, takiej jak Array.indexOf . Większość przeglądarek ma natywną implementację tego i będzie działać dobrze, ale IE8 się zepsuje. Pamiętasz, że IE8 został wydany kilka miesięcy przed opublikowaniem standardów ES5, a więc czy ma niedopasowanie obsługi? Jednym z przykładów jest funkcja indexOf , która została zaimplementowana dla String , ale nie dla Array .

Jeśli spróbujemy uruchomić metodę Array.indexOf w IE8, nie powiedzie się. Ale jeśli już piszemy w ES5, co jeszcze możemy zrobić?

Możemy uzupełnić zachowanie brakującej metody. Deweloperzy tradycyjnie wypełniają każdą funkcję, której potrzebują, kopiując i wklejając kod lub ściągając zewnętrzne biblioteki wypełniaczy innych firm. Wiele funkcji JavaScript ma dobre implementacje wypełniania na swoich stronach Mozilla MDN, ale warto podkreślić, że istnieje wiele sposobów na wypełnianie tej samej funkcji na wiele sposobów.

Na przykład, aby upewnić się, że możesz użyć metody Array.indexOf w IE8, skopiuj i wklej wypełnienie w następujący sposób:

 if (!Array.prototype.indexOf) { Array.prototype.indexOf = (function (Object, max, min) { // big chunk of code that replicates the behaviour in JavaScript goes here! // for full implementation, visit: // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexof#Polyfill })(Object, Math.max, Math.min); }

Dopóki wywołasz funkcję wypełniania przed wciągnięciem własnego JS i pod warunkiem, że nie użyjesz żadnej funkcji JavaScript ES5 innej niż Array.indexOf , Twoja strona będzie działać w IE8.

Polyfills mogą być używane do wypełniania wszelkiego rodzaju brakujących funkcji. Na przykład istnieją wypełniacze umożliwiające włączenie selektorów CSS3, takich jak :last-child (nieobsługiwany w IE8) lub atrybut placeholder (nieobsługiwany w IE9).

Wypełnienia różnią się wielkością i skutecznością, a czasami są zależne od bibliotek zewnętrznych, takich jak jQuery.

Możesz również usłyszeć o „podkładkach”, a nie o „wypełnieniach”. Nie przejmuj się zbytnio nazewnictwem — ludzie używają tych dwóch terminów zamiennie. Ale technicznie rzecz biorąc, podkładka to kod, który przechwytuje wywołanie API i zapewnia warstwę abstrakcji. Wypełnienie to rodzaj podkładki w przeglądarce . W szczególności używa JavaScript do modernizacji nowych funkcji HTML/CSS/JS w starszych przeglądarkach.

Podsumowanie strategii „ręcznego importu wypełnień”:

• Pełna kontrola nad doborem wypełniaczy;
• Nadaje się do podstawowych stron internetowych;
• ️ Bez dodatkowych narzędzi jesteś zmuszony pisać w natywnym ES5 JavaScript;
• ️ Trudne do mikrozarządzania wszystkimi wypełniaczami;
• ️ Po wyjęciu z pudełka wszyscy użytkownicy otrzymają wypełniacze, niezależnie od tego, czy ich potrzebują, czy nie.

Wypełniacz Babel

Mówiłem o transpilacji kodu z ES6 do ES5. Robisz to za pomocą transpilera , z którego najpopularniejszym jest Babel.

Babel można skonfigurować za pomocą pliku .babelrc w katalogu głównym projektu. Wskazujesz w nim różne wtyczki i ustawienia predefiniowane Babel. Zazwyczaj jest jeden dla każdej potrzebnej transformacji składni i wypełnienia przeglądarki.

Mikrozarządzanie nimi i utrzymywanie ich w synchronizacji z listą obsługiwanych przeglądarek może być uciążliwe, więc standardową konfiguracją w dzisiejszych czasach jest delegowanie tego mikrozarządzania do modułu @babel/preset-env. Dzięki tej konfiguracji po prostu dajesz Babel listę wersji przeglądarek, które chcesz obsługiwać, a ona wykonuje za Ciebie ciężką pracę:

 { "presets": [ [ "@babel/preset-env", { "useBuiltIns": "usage", "targets": { "chrome": "58", "ie": "11" } } ] ] }

Opcja konfiguracji useBuiltIns @babel/preset-env to miejsce, w którym dzieje się magia, w połączeniu z import "@babel/polyfill" (inny moduł) w punkcie wejścia aplikacji.

• useBuiltIns nic nie robi. Całość @babel/polyfill jest dołączona do Twojej aplikacji, co jest dość ciężkie.
• Po ustawieniu na "entry" konwertuje import @babel/polyfill na wiele mniejszych importów, importując minimalną liczbę wypełnień wymaganych do wypełnienia docelowych przeglądarek wymienionych w .babelrc (w tym przykładzie Chrome 58 i IE 11) .
• Ustawienie na "usage" idzie o krok dalej, przeprowadzając analizę kodu i importując tylko wypełnienia dla funkcji, które są faktycznie używane . Jest klasyfikowany jako „eksperymentalny”, ale błądzi po stronie „za dużo wypełniania”, a nie „za mało”. W każdym razie nie widzę, jak to możliwe, że utworzyłoby to większe opakowanie niż "entry" lub false , więc jest to dobra opcja do wyboru (i tak właśnie idziemy w BBC).

Korzystając z Babel, możesz transpilować i wypełniać kod JavaScript przed wdrożeniem do produkcji oraz docelową obsługę w określonej minimalnej linii bazowej przeglądarek. Uwaga, innym popularnym narzędziem jest TypeScript, który ma własny transpiler, który transpiluje się do ES3, teoretycznie wspierając IE8 po wyjęciu z pudełka.

Podsumowanie użycia @babel/preset-env do wypełniania:

• Deleguj mikrozarządzanie wypełniaczami do narzędzia;
• Zautomatyzowane narzędzie pomaga zapobiegać włączaniu niepotrzebnych wypełniaczy;
• Skaluje do większych, złożonych witryn;
• ️ Po wyjęciu z pudełka wszyscy użytkownicy otrzymają wypełniacze, niezależnie od tego, czy ich potrzebują, czy nie;
• ️ Trudno jest dokładnie zobaczyć, co jest pobierane do pakietu aplikacji.

Lazy loading Polyfills z pakietem internetowym i dynamicznym importem

Możliwe jest wykorzystanie nowej propozycji import() do wykrywania funkcji i dynamicznego pobierania wypełnień przed zainicjowaniem aplikacji. W praktyce wygląda to mniej więcej tak:

 import app from './app.js'; const polyfills = []; if (!window.fetch) { polyfills.push(import(/* webpackChunkName: "polyfill-fetch" */ 'whatwg-fetch')); } Promise.all(polyfills) .then(app) .catch((error) => { console.error('Failed fetching polyfills', error); });

Ten przykładowy kod jest bezwstydnie skopiowany z bardzo dobrego artykułu „Lazy Loading Polyfills With Webpack And Dynamic Imports”, który zagłębia się w technikę bardziej szczegółowo.

Streszczenie:

• Nie nadyma nowoczesnych przeglądarek niepotrzebnymi wypełniaczami;
• ️ Wymaga ręcznego zarządzania każdym wypełnieniem.

polyfill.io

polyfill.io to usługa wypełniania poliamidu, stworzona przez Financial Times. Działa w ten sposób, że Twoja strona wysyła pojedyncze żądanie skryptu do polyfill.io, opcjonalnie wymieniając konkretne funkcje, które musisz wypełnić. Ich serwer następnie analizuje ciąg agenta użytkownika i odpowiednio wypełnia skrypt. Dzięki temu nie musisz ręcznie dostarczać własnych rozwiązań wypełniacza.

Oto JavaScript, który polyfill.io zwraca dla żądania wykonanego z IE8:

Oto to samo żądanie polyfill.io, ale żądanie pochodzi z nowoczesnego Chrome:

Wszystko, czego wymaga Twoja witryna, to jedno wywołanie skryptu.

Streszczenie:

• Łatwość włączenia do aplikacji internetowej;
• Deleguje odpowiedzialność za wiedzę o polyfill na osobę trzecią;
• ️ Z drugiej strony jesteś teraz zależny od usługi innej firmy;
• ️ Wykonuje blokujące wywołanie <script> , nawet dla nowoczesnych przeglądarek, które nie wymagają wypełniania.

Progresywne ulepszanie

Wypełnianie jest niezwykle przydatną techniką obsługi starszych przeglądarek, ale może być przesadą dla stron internetowych i ma ograniczony zakres.

Z drugiej strony technika progresywnego ulepszania to świetny sposób na zagwarantowanie podstawowego doświadczenia we wszystkich przeglądarkach, przy jednoczesnym zachowaniu pełnej funkcjonalności dla użytkowników nowoczesnych przeglądarek. Powinno to być osiągalne w większości witryn.

Zasada jest taka: zacznij od bazowego HTML (i stylizacji, opcjonalnie) i „progresywnie ulepszaj” stronę o funkcjonalność JavaScript. Zaletą jest to, że jeśli przeglądarka jest starsza lub jeśli JavaScript jest uszkodzony w dowolnym momencie jej dostarczania, Twoja witryna powinna nadal działać.

Termin „progresywne ulepszanie” jest często używany zamiennie z „dyskretnym JavaScriptem”. Zasadniczo oznaczają to samo, ale to drugie idzie nieco dalej, ponieważ nie powinieneś zaśmiecać kodu HTML mnóstwem atrybutów, identyfikatorów i klas, które są używane tylko przez twój JavaScript.

Ciąć musztardę

Technika BBC „cięcia musztardy” (CTM) jest wypróbowaną i przetestowaną implementacją progresywnego ulepszania. Zasada jest taka, że ​​piszesz solidne, bazowe doświadczenie HTML, a przed pobraniem jakiegokolwiek ulepszającego JavaScript, sprawdzasz minimalny poziom wsparcia. Oryginalna implementacja sprawdzona pod kątem obecności standardowych funkcji HTML5:

 if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // Enhance for HTML5 browsers }

Ponieważ pojawiają się nowe funkcje, a starsze przeglądarki stają się coraz bardziej przestarzałe, nasze cięcia zmienią linię bazową musztardy. Na przykład nowa składnia JavaScript, taka jak funkcje strzałek ES6, oznaczałaby, że ten wbudowany test CTM nie jest nawet analizowany w starszych przeglądarkach — nawet nie jest bezpiecznie wykonywany i nie przechodzi kontroli CTM — więc może mieć nieoczekiwane skutki uboczne, takie jak zerwanie kodu JavaScript innych firm (np. Google Analytics).

Aby uniknąć nawet próby parsowania nieprzetranspilowanego, nowoczesnego JS, możemy zastosować to „nowoczesne podejście” do techniki CTM, zaczerpnięte z bloga @snugug, w którym wykorzystujemy fakt, że starsze przeglądarki nie rozumieją type="module" i bezpiecznie ją pominiemy. W przeciwieństwie do tego, nowoczesne przeglądarki ignorują deklaracje <script nomodule> .

 <script type="module" src="./mustard.js"></script> <script nomodule src="./no-mustard.js"></script> <!-- Can be done inline too --> <script type="module"> import mustard from './mustard.js'; </script> <script nomodule type="text/javascript"> console.log('No Mustard!'); </script>

To podejście jest dobre, pod warunkiem, że jesteś zadowolony z traktowania przeglądarek ES6 jako nowej minimalnej podstawy funkcjonalności (~ 92% przeglądarek globalnych w momencie pisania tego tekstu).

Jednak tak jak ewoluuje świat JavaScript, tak samo ewoluuje świat CSS. Teraz, gdy mamy zmienne Grid, Flexbox, CSS i tym podobne (każda o różnej skuteczności awaryjnej), nie wiadomo, jaką kombinację obsługi CSS może mieć stara przeglądarka, co może prowadzić do miszmaszu „nowoczesnych” i „starszych” stylizacja, której efekt wygląda na zepsuty. W związku z tym witryny coraz częściej decydują się na CTM swoje style , więc teraz HTML jest podstawowym punktem odniesienia, a zarówno CSS, jak i JS są traktowane jako ulepszenia.

Techniki CTM oparte na JavaScript, które widzieliśmy do tej pory, mają kilka wad, jeśli używasz JavaScript do zastosowania CSS w jakikolwiek sposób:

1. Wbudowany JavaScript jest blokowany. Przeglądarki muszą pobrać, przeanalizować i uruchomić JavaScript, zanim uzyskasz jakąkolwiek stylizację. Dlatego użytkownicy mogą zobaczyć błysk niestylowanego tekstu.
2. Niektórzy użytkownicy mogą mieć nowoczesne przeglądarki, ale decydują się wyłączyć JavaScript. CTM oparty na JavaScript uniemożliwia im uzyskanie stylizowanej witryny, nawet jeśli są w stanie ją uzyskać.

„Ostatecznym” podejściem jest użycie zapytań o media CSS jako testu lakmusowego odcięcia musztardy. Ta technika „CSSCTM” jest aktywnie wykorzystywana na stronach takich jak Springer Nature.

 <head> <!-- CSS-based cuts-the-mustard --> <!-- IMPORTANT: the JS depends on having this rule somewhere in the CSS: `body { clear: both }` --> <link rel="stylesheet" href="mq-test.css" media="only screen and (min-resolution: 0.1dpcm), only screen and (-webkit-min-device-pixel-ratio:0) and (min-color-index:0)"> </head> <body> <!-- content here... --> <script> (function () { // wrap in an IIFE to prevent global scope pollution function isSupported () { var val = ''; if (window.getComputedStyle) { val = window.getComputedStyle(document.body, null).getPropertyValue('clear'); } else if (document.body.currentStyle) { val = document.body.currentStyle.clear; } if (val === 'both') { // references the `body { clear: both; }` in the CSS return true; } return false; } if (isSupported()) { // Load or run JavaScript for supported browsers here. } })(); </script> </body>

To podejście jest dość kruche — przypadkowe przesłonięcie właściwości clear w selektorze body mogłoby „zepsuć” witrynę — ale zapewnia najlepszą wydajność. Ta konkretna implementacja używa zapytań o media, które są obsługiwane tylko w co najmniej IE 9, iOS 7 i Android 4.4, co jest całkiem rozsądnym współczesnym punktem odniesienia.

„Ciecie musztardę”, we wszystkich swoich różnych postaciach, realizuje dwie główne zasady:

1. Powszechne wsparcie dla użytkowników;
2. Efektywnie zastosowany wysiłek deweloperski.

Witryny po prostu nie są w stanie dostosować się do każdej kombinacji przeglądarki/systemu operacyjnego/połączenia sieciowego/konfiguracji użytkownika. Techniki takie jak cięcie musztardy pomagają zracjonalizować przeglądarki do przeglądarek klasy C i A, zgodnie z modelem Graded Browser Support opracowanym przez Yahoo! .

Cięcie musztardy: antywzór?

Istnieje argument, że zastosowanie globalnej, binarnej decyzji „podstawowej” lub „zaawansowanej” nie jest najlepszym możliwym doświadczeniem dla naszych użytkowników. Zapewnia rozsądek w przypadku zniechęcającego problemu technicznego, ale co, jeśli przeglądarka obsługuje 90% funkcji w globalnym teście CTM, a ta konkretna strona nie korzysta nawet z 10% funkcji, na których nie działa? W takim przypadku użytkownik otrzymałby podstawowe doświadczenie, ponieważ sprawdzenie CTM zakończyłoby się niepowodzeniem. Ale mogliśmy dać im pełne doświadczenie.

A co z przypadkami, w których dana strona korzysta z funkcji, której przeglądarka nie obsługuje? Cóż, w dążeniu do komponowania moglibyśmy mieć rezerwę specyficzną dla funkcji (lub granicę błędu), a nie powrót na poziomie strony.

Robimy to każdego dnia w naszym tworzeniu stron internetowych. Pomyśl o wciągnięciu czcionki internetowej; różne przeglądarki mają różne poziomy obsługi czcionek. Co robimy? Udostępniamy kilka odmian plików czcionek i pozwalamy przeglądarce zdecydować, które pliki pobrać:

 @font-face { font-family: FontName; src: url('path/filename.eot'); src: url('path/filename.eot?#iefix') format('embedded-opentype'), url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff'), url('path/filename.ttf') format('truetype'); }

Podobną wadę mamy z wideo HTML5. Nowoczesne przeglądarki wybiorą format wideo, którego chcą użyć, podczas gdy starsze przeglądarki, które nie rozumieją, czym jest element <video> , po prostu wyrenderują tekst zastępczy:

 <video width="400" controls> <source src="mov_bbb.mp4" type="video/mp4"> <source src="mov_bbb.ogg" type="video/ogg"> Your browser does not support HTML5 video. </video>

Podejście do zagnieżdżania, które widzieliśmy wcześniej, stosowane przez BBC w przypadku zastępczych plików PNG dla SVG, jest podstawą responsywnego elementu obrazu <picture> . Nowoczesne przeglądarki wyrenderują najlepiej dopasowany obraz na podstawie dostarczonego atrybutu media , podczas gdy starsze przeglądarki, które nie rozumieją, czym jest element <picture> , wyrenderują <img> .

 <picture> <source media="(min-width: 650px)"> <source media="(min-width: 465px)"> <img src="img_orange_flowers.jpg" alt="Flowers"> </picture>

Specyfikacja HTML ewoluowała przez lata, aby zapewnić podstawowy mechanizm awaryjny dla wszystkich przeglądarek, jednocześnie umożliwiając funkcje i optymalizacje dla nowoczesnych przeglądarek, które je rozumieją.

Podobną zasadę moglibyśmy zastosować do naszego kodu JavaScript. Wyobraź sobie taką cechę, w której metoda foo zawiera złożony JS:

 class Feature { browserSupported() { return ('querySelector' in document); // internal cuts-the-mustard goes here } foo() { // etc } } export default new Feature();

Przed wywołaniem foo sprawdzamy, czy funkcja jest obsługiwana w tej przeglądarce, wywołując jej metodę browserSupported . Jeśli nie jest obsługiwany, nie próbujemy nawet wywołać kodu, który w przeciwnym razie spowodowałby błąd na naszej stronie.

 import Feature from './feature'; if (Feature.browserSupported()) { Feature.foo(); }

Ta technika oznacza, że ​​możemy uniknąć wciągania wypełniaczy i po prostu korzystać z tego, co jest natywnie obsługiwane przez każdą przeglądarkę, z wdziękiem degradując poszczególne funkcje, jeśli nie są obsługiwane.

Zwróć uwagę, że w powyższym przykładzie zakładam, że kod zostanie transpilowany do ES5, aby składnia była zrozumiała dla wszystkich przeglądarek, ale nie zakładam, że którykolwiek kod jest wypełniany . Gdybyśmy chcieli uniknąć transpilacji kodu, moglibyśmy zastosować tę samą zasadę, ale używając type="module" przyjmijmy cięcie musztardy, ale wiąże się to z zastrzeżeniem, że ma już minimalne wymagania dotyczące przeglądarki ES6, więc jest to tylko prawdopodobnie za kilka lat zacznie być dobrym rozwiązaniem:

 <script type="module"> import Feature from './feature.js'; if (Feature.browserSupported()) { Feature.foo(); } </script>

Omówiliśmy HTML i JavaScript. Możemy również zastosować zlokalizowane awaryjne rozwiązania w CSS; w CSS istnieje słowo kluczowe @supports , które pozwala warunkowo zastosować CSS w oparciu o obecność lub brak obsługi funkcji CSS. Jest jednak ironicznie zastrzeżony faktem, że nie jest powszechnie wspierany. Wymaga tylko starannej aplikacji; jest świetny wpis na blogu Mozilli o tym, jak używać zapytań o funkcje w CSS.

W idealnym świecie nie powinniśmy potrzebować globalnej kontroli krojenia musztardy. Zamiast tego każda pojedyncza funkcja HTML, JS lub CSS powinna być samowystarczalna i mieć własne granice błędów. Spodziewam się, że w świecie komponentów sieciowych, shadow DOM i niestandardowych elementów zobaczymy więcej zmian w kierunku tego rodzaju podejścia. Jednak znacznie trudniej jest przewidzieć i przetestować witrynę jako całość i mogą wystąpić niezamierzone skutki uboczne, jeśli, powiedzmy, stylizacja jednego komponentu wpływa na układ innego.

Dwie główne strategie kompatybilności wstecznej

Podsumowanie polifillingu jako strategii :

• Może dostarczyć funkcjonalność JS po stronie klienta dla większości użytkowników.
• Może być łatwiej kodować podczas delegowania problemu wstecznej kompatybilności do wypełnienia.
• ️ W zależności od implementacji, może mieć negatywny wpływ na wydajność dla użytkowników, którzy nie potrzebują wypełniaczy.
• ️ W zależności od złożoności aplikacji i wieku przeglądarki, może wymagać wielu wypełniaczy, przez co działa bardzo słabo. Ryzykujemy wysłanie megabajtów wypełniaczy do przeglądarek najmniej przygotowanych do ich przyjęcia.

Podsumowanie progresywnego ulepszania jako strategii :

• Tradycyjne CTM ułatwia segmentację kodu i ręczne testowanie.
• Gwarantowane podstawowe doświadczenie dla wszystkich użytkowników.
• ️ Może niepotrzebnie dostarczać podstawowe środowisko użytkownikom, którzy mogliby poradzić sobie z zaawansowanymi doświadczeniami.
• ️ Nieodpowiednie dla witryn, które do działania wymagają JS po stronie klienta.
• ️ Czasami trudno jest zrównoważyć solidną strategię progresywnego ulepszania z wydajnym pierwszym renderowaniem. Istnieje ryzyko nadania priorytetu „podstawowemu” środowisku ze szkodą dla 90% użytkowników, którzy mają „pełne” doświadczenie (np. dostarczanie małych obrazów dla noJS, a następnie zastępowanie ich obrazami o wysokiej rozdzielczości przy leniwym ładowaniu, oznacza, że zmarnowałem dużo możliwości pobierania na zasoby, które nigdy nie są nawet przeglądane).

Wniosek

IE8 był kiedyś najnowocześniejszą przeglądarką. (Nie, poważnie.) To samo można powiedzieć dzisiaj o Chrome i Firefox.

Jeśli dzisiejsze strony internetowe są całkowicie bezużyteczne w IE8, strony internetowe za dziesięć lat prawdopodobnie będą równie bezużyteczne w dzisiejszych nowoczesnych przeglądarkach — mimo że są zbudowane na otwartych technologiach HTML, CSS i JavaScript.

Zatrzymaj się i pomyśl o tym przez chwilę. Czy to nie jest trochę przerażające? (To powiedziawszy, jeśli nie możesz porzucić przeglądarek po dziesięciu latach i po tym, jak firma, która je zbudowała, zdeprecjonowała je, kiedy możesz?)

IE8 jest dzisiejszym kozłem ofiarnym. Jutro będzie to IE9, w przyszłym roku Safari, rok później może Chrome. Możesz zamienić IE8 na „starą przeglądarkę z wyboru”. Chodzi o to, że zawsze będzie jakiś podział między tym, dla jakich przeglądarek budują programiści, a tym, jakich przeglądarek używają ludzie. Powinniśmy przestać się z tego wyśmiewać i zacząć inwestować w solidne, integracyjne rozwiązania inżynieryjne . Skutki uboczne tych strategii przynoszą korzyści w postaci dostępności, wydajności i odporności sieci, więc w grę wchodzi szerszy obraz.

Zwykle nie myślimy o liczbach czytników ekranu. Po prostu przyjmujemy za pewnik, że moralnie słuszne jest robienie wszystkiego, co w naszej mocy, aby wspierać użytkowników, którzy nie mają innego sposobu na korzystanie z naszych treści bez własnej winy. Ta sama zasada dotyczy osób korzystających ze starszych przeglądarek.

Omówiliśmy kilka ogólnych strategii tworzenia solidnych witryn, które do pewnego stopnia powinny nadal działać w szerokim spektrum starszych i nowoczesnych przeglądarek.

Jeszcze raz zastrzeżenie: nie hakuj rzeczy dla IE. To nie miałoby sensu. Należy jednak pamiętać, że wszyscy ludzie korzystają z różnych przeglądarek z różnych powodów i że istnieją pewne solidne podejścia inżynieryjne, które możemy zastosować, aby uczynić sieć dostępną dla wszystkich.

Optymalizuj dla większości, podejmij wysiłek dla mniejszości i nigdy nie rezygnuj z bezpieczeństwa.

Dalsze czytanie na SmashingMag:

• Standardy sieciowe: co, dlaczego i jak
• Smart Bundling: jak udostępniać starszy kod tylko starszym przeglądarkom
• Nie używaj atrybutu zastępczego
• Projektowanie dla sieci bez przeglądarki