Я использовал Интернет в течение дня в Internet Explorer 8

Эта статья является частью серии, в которой я пытаюсь использовать Интернет с различными ограничениями, представляя определенную демографическую группу пользователей. Я надеюсь привлечь внимание к трудностям, с которыми сталкиваются реальные люди, которых можно избежать, если мы проектируем и разрабатываем с учетом их потребностей.

В прошлый раз я провел день в Интернете, используя программу чтения с экрана. На этот раз я провел день, используя Internet Explorer 8, который был выпущен десять лет назад сегодня, 19 марта 2009 года.

Кто в мире использует IE8?

Прежде чем мы начнем; отказ от ответственности: я не собираюсь говорить вам, что вам нужно начать поддерживать IE8.

Есть все основания не поддерживать IE8. Microsoft официально прекратила поддержку IE8, IE9 и IE10 более трех лет назад, и руководители Microsoft даже говорят вам прекратить использовать Internet Explorer 11.

Но как бы мы, разработчики, ни надеялись, что это исчезнет, ​​это просто так. Не будет. Умереть . IE8 продолжает появляться в статистике браузеров, особенно за пределами западного мира.

К статистике браузеров следует относиться с долей скептицизма, но текущие оценки использования IE8 во всем мире составляют от 0,3% до 0,4% доли рынка настольных компьютеров. Нижняя граница оценки исходит от w3counter:

Более высокая оценка исходит от StatCounter (тот же поток данных, который используется в таблице использования «Могу ли я использовать»). По оценкам, глобальная доля настольных браузеров IE8 составляет около 0,37%.

Я подозревал, что мы можем увидеть более широкое использование IE8 в определенных географических регионах, поэтому детализировали данные по континентам.

Использование IE8 по регионам

Вот доля настольных компьютеров с IE8 по континентам (данные за февраль 2018 — январь 2019):

Кто-то в Азии в пять раз чаще использует IE8, чем кто-то в Океании.

Я более внимательно изучил азиатскую статистику, отметив долю использования IE8 в каждой стране. Существует очень четкая шестерка стран с самым высоким уровнем использования IE8, после чего цифры падают вниз, чтобы быть сопоставимыми со средними мировыми показателями:

Эти данные представлены на карте ниже:

Невероятно, но IE8 составляет около 4% пользователей настольных компьютеров в Иране — в сорок раз больше, чем доля пользователей IE8 в Океании.

Затем я посмотрел статистику по странам Африки, так как общее использование IE8 было примерно таким же, как и в Азии. Был явный победитель (Эритрея), за которым следовал ряд стран выше или около отметки использования 1%:

Это кратко показано на карте ниже:

В то время как страны Азии с более высоким, чем обычно, уровнем использования IE8, примерно объединены географически, в Африке, по-видимому, нет закономерности. Единственная закономерность, которую я вижу — если это не совпадение — заключается в том, что ряд крупнейших в мире стран, использующих IE8, жестко ограничивают доступ в Интернет и поэтому, вероятно, не поощряют и не разрешают переход на более безопасные браузеры.

Если ваш сайт ориентирован исключительно на западную аудиторию, вам вряд ли будет интересен IE8. Однако, если у вас есть растущий азиатский или африканский рынок — и особенно если вы заботитесь о пользователях в Китае, Иране или Эритрее — вам может быть очень важно, чтобы ваш веб-сайт работал с IE8. Да — даже в 2019 году!

Кто все еще использует IE?

Итак, кто эти люди? Неужели они ходят среди нас?!

Кем бы они ни были, вы можете поспорить, что они используют старый браузер не только для того, чтобы вас раздражать. Никто намеренно не выбирает худший опыт просмотра.

Кто-то может использовать старый браузер по следующим причинам:

• Недостаточная информированность
  Они просто не знают, что используют устаревшие технологии.
• Нехватка образования
  Они не знают вариантов обновления и альтернативных браузеров, открытых для них.
• Отсутствие планирования
  Отклонение запросов на обновление, потому что они заняты, но не предвидят обновления в более спокойные периоды.
• Отвращение к переменам
  В последний раз, когда они обновляли свое программное обеспечение, им пришлось изучать новый пользовательский интерфейс. «Если не сломано, не чини».
• Отвращение к риску
  В последний раз, когда они обновлялись, их компьютер замедлялся до минимума или они теряли свою любимую функцию.
• Программное ограничение
  Их ОС слишком старая, чтобы позволить им обновиться, или их права администратора могут быть заблокированы.
• Аппаратное ограничение
  Новые браузеры, как правило, более требовательны к пространству на жестком диске, памяти и процессору.
• Ограничение сети
  Ограничение объема данных или медленное соединение означают, что они не хотят загружать 75 МБ программного обеспечения.
• Юридическое ограничение
  Они могут быть на корпоративном компьютере, который допускает использование только одного конкретного браузера.

Разве это так удивительно, что во всем мире все еще есть люди, которые цепляются за IE8?

Я решил поставить себя на место одной из этих анонимных душ и провести день в Интернете с помощью IE8. Вы можете играть вместе дома! Загрузите виртуальную машину «IE8 в Windows 7» с веб-сайта Microsoft, затем запустите ее в виртуализаторе, таком как VirtualBox.

Виртуальная машина IE8: неудачный старт

Я загрузил свою виртуальную машину с IE8, в предвкушении кликнул по программе Internet Explorer и вот что увидел:

Хм, хорошо. Похоже, веб-страница по умолчанию, открытая IE8, больше не существует. Ну, это цифры. Microsoft официально прекратила поддержку IE8, так зачем ей следить за тем, чтобы целевая страница IE8 по-прежнему работала?

Я решил перейти на самый широко используемый сайт в мире.

Google

Это простой сайт, поэтому трудно ошибиться — но, честно говоря, он выглядит великолепно! Я попытался найти что-то:

Поиск работал нормально, хотя макет выглядит немного иначе, чем я привык. Потом я вспомнил — я видел такой же макет результатов поиска, когда пользовался Интернетом в течение дня с отключенным JavaScript.

Для справки, вот как результаты поиска выглядят в современном браузере с включенным JavaScript:

Итак, похоже, что IE8 получает версию поиска Google без JS. Я не думаю, что это обязательно было преднамеренным дизайнерским решением — возможно, это просто ошибка JavaScript:

Тем не менее, конечный результат меня устраивает — я получил результаты поиска, и это все, что я хотел.

Я щелкнул, чтобы посмотреть видео на YouTube.

YouTube

На этой странице довольно много сломано. Все, что связано с небольшими причудами в IE.

Логотип, например, увеличен и обрезан. Это связано с тем, что IE8 не поддерживает SVG, и на самом деле мы видим резервный вариант, предоставляемый YouTube. Они применили CSS-свойство background-image , чтобы в случае отсутствия поддержки SVG вы попытались отобразить логотип. Только они, кажется, не установили background-size должным образом, поэтому он слишком сильно увеличен.

Для справки, вот та же страница в Chrome (вместо этого посмотрите, как Chrome отображает SVG):

А как насчет переключателя автозапуска? Он отображается как странно выглядящий флажок:

Похоже, это связано с использованием пользовательского элемента (кнопка-переключатель бумаги, которая является элементом дизайна материалов), который IE не понимает:

Я не удивлен, что это не отображается должным образом; IE8 не справляется даже с базовой семантической разметкой, которую мы используем в наши дни. Попробуйте использовать <aside> или <main> , и он в основном отобразит их как div, но игнорирует любые применяемые к ним стили.

Чтобы включить разметку HTML5, вы должны явно указать браузеру, что эти элементы существуют. Затем их можно стилизовать как обычно:

 <!--[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]-->

Кстати, это завернуто в условие IE. <!--[if lt IE 9]> является HTML-комментарием для большинства браузеров — и поэтому пропускается — но в IE это условное выражение, которое проходит только «если меньше, чем IE 9», где оно выполняет/отображает узлы DOM внутри.

Таким образом, видео-страница была неудачной. Посещение YouTube.com напрямую оказалось не намного лучше:

Не испугавшись, я проигнорировал предупреждение и попытался найти видео в строке поиска YouTube.

Трафик IE8 явно достаточно подозрительный, поэтому YouTube не поверил, что я реальный пользователь, и решил не обрабатывать мой поисковый запрос!

Регистрация в Gmail

Если я собираюсь провести день в IE8, мне понадобится адрес электронной почты. Поэтому я пытаюсь установить новый.

Прежде всего, я попробовал Gmail.

Здесь что-то не так с изображением и текстом. Я думаю, это связано с тем, что IE8 не поддерживает медиа-запросы, поэтому он пытается показать мне мобильное изображение на рабочем столе.

Один из способов обойти это — использовать Sass для создания двух таблиц стилей; один для современных браузеров и один для устаревшего IE. Вы можете получить удобный для IE, ориентированный на мобильные устройства CSS (см. руководство Джейка Арчибальда), используя миксин для ваших медиа-запросов. Миксин «сглаживает» ваш устаревший CSS IE, чтобы трактовать IE так, как если бы он всегда имел определенную предопределенную ширину (например, 65em), предоставляя только соответствующий CSS для этой ширины. В этом случае я бы увидел правильное background-image для моего предполагаемого размера экрана и получил бы лучший опыт.

Во всяком случае, это не помешало мне нажать «Создать учетную запись». Было несколько различий между тем, как это выглядело в IE8 и в современном браузере:

На первый взгляд многообещающая, но заполнить форму было довольно сложно. «Ярлык» не убирается, когда вы начинаете заполнять поля, поэтому ваш вводимый текст запутывается:

Разметка для этой метки на самом деле представляет собой <div> , и некоторые хитрые JS перемещают текст в сторону, когда ввод находится в фокусе. JS не работает в IE8, поэтому текст упорно остается на месте.

Заполнив все свои данные, я нажал «Далее» и стал ждать. Ничего не произошло.

Затем я заметил маленький желтый предупреждающий символ в левом нижнем углу окна IE. Я щелкнул по нему и увидел, что он жалуется на ошибку JS:

Я отказался от Gmail и обратился к MSN.

Регистрация в Hotmail

Я начал беспокоиться, что электронная почта может быть запрещена для браузера десятилетней давности. Но когда я зашел на Hotmail, форма регистрации выглядела нормально — пока все хорошо:

Затем я заметил CAPTCHA. Я подумал: «Я не переживу этого…»

К моему удивлению, CAPTCHA сработала!

Единственной причудливой вещью в форме было немного ошибочное позиционирование ярлыка, но в остальном регистрация прошла без проблем:

Этот скриншот выглядит нормально для вас? Можете ли вы заметить преднамеренную ошибку?

Крайний левый ввод должен был быть моим именем, а не моей фамилией. Когда я вернулся и проверил эту страницу позже, я щелкнул ярлык «Имя», и он применил фокус к крайнему левому вводу, таким образом я мог проверить, что я заполнил правильное поле в первую очередь. Это показывает важность доступной разметки — даже без CSS и визуальной ассоциации я мог точно определить, какое поле ввода применялось к какой метке (хотя и во второй раз!).

Как бы то ни было, я смог завершить процесс регистрации и был перенаправлен на домашнюю страницу MSN, которая выглядела великолепно.

Я даже мог читать статьи и забыть, что использую IE8:

С моей зарегистрированной электронной почтой я был готов пойти и проверить остальную часть Интернета!

Фейсбук

Я зашел на сайт Facebook и сразу же был перенаправлен на мобильный сайт:

Это умная запасная тактика, поскольку Facebook необходимо поддерживать большую глобальную аудиторию на недорогих мобильных устройствах, поэтому в любом случае необходимо предоставить базовую версию Facebook. Почему бы не предложить такой же базовый опыт для старых настольных браузеров?

Я попытался зарегистрироваться и смог создать учетную запись. Здорово! Но когда я вошел в эту учетную запись, ко мне отнеслись с подозрением — так же, как когда я искал что-то на YouTube — и столкнулся с CAPTCHA.

Только на этот раз все было не так просто.

Я пытался запросить новые коды и обновить страницу несколько раз, но изображение CAPTCHA так и не загрузилось, поэтому моя учетная запись была фактически заблокирована.

Ну что ж. Давайте попробуем еще несколько социальных сетей.

Твиттер

Я посетил сайт Twitter и получил точно такой же опыт мобильной переадресации.

Но на этот раз я не смог даже зарегистрировать аккаунт:

Как ни странно, Twitter рад вашему входу в систему, но не вашей регистрации. Я не уверен, почему — возможно, на страницах регистрации есть аналогичный сценарий CAPTCHA, который не будет работать в старых браузерах. В любом случае, я не смогу создать новую учетную запись.

Я чувствовал себя неловко из-за входа в свою существующую учетную запись Twitter. Назовите меня параноиком, но такие уязвимости, как атака CFR Watering Hole в 2013 году, когда простое посещение определенного URL-адреса в IE8 приводило к установке вредоносного ПО на ваш компьютер, заставили меня нервничать, что я могу скомпрометировать свою учетную запись.

Но, в интересах образования, я настоял (с новым временным паролем):

Я также мог твитнуть, хотя и использовал очень простую <textarea> :

В заключение, Twitter отлично работает в IE8 — если у вас уже есть учетная запись!

Я закончил с социальными сетями на сегодня. Давайте проверим некоторые новости.

Новости BBC

Домашняя страница новостей выглядит очень простой и неуклюжей, но в основном работает, хотя и с предупреждениями безопасности смешанного содержания.

Взгляните на логотип. Как мы уже видели на YouTube, IE8 не поддерживает SVG, поэтому нам нужен резервный вариант PNG.

BBC использует резервную технику <image> для рендеринга PNG в IE:

… и игнорировать PNG, когда доступен SVG:

Этот метод использует тот факт, что старые браузеры подчинялись как тегам <image> , так и <img> , и поэтому будут игнорировать неизвестный <svg> и отображать запасной вариант, тогда как современные браузеры игнорируют отображение <image> внутри SVG. Крис Койер объясняет технику более подробно.

Я попытался просмотреть статью:

Это читабельно. Я вижу заголовок, навигацию, изображение. Но остальные изображения статьи отсутствуют:

Этого следовало ожидать, и это связано с ленивой загрузкой изображений BBC. IE8, не являющийся «поддерживаемым браузером», означает, что он не получает JavaScript, обеспечивающий отложенную загрузку, поэтому изображения вообще никогда не загружаются.

Из интереса я решил посмотреть, что произойдет, если я попытаюсь получить доступ к BBC iPlayer:

И это заставило меня задуматься о другом потоковом сервисе.

Нетфликс

Я наполовину ожидал увидеть пустую белую страницу, когда загрузил Netflix в IE8. Я был приятно удивлен, когда действительно увидел приличную целевую страницу:

Я сравнил это с современной версией Chrome:

Там немного другой призыв к действию (текст кнопки) — вероятно, из-за многовариантного тестирования, а не из-за того, какой у меня браузер.

Чем отличается рендеринг, так это централизованным текстом и полупрозрачным черным наложением.

Отсутствие централизованного текста связано с тем, что Netflix использует Flexbox для выравнивания элементов:

text-align: center для этого класса, вероятно, исправит центрирование для IE8 (да и для всех старых браузеров). Для максимальной поддержки браузера вы можете использовать альтернативный подход CSS со старым «безопасным» CSS, а затем ужесточить макеты с помощью более современного CSS для браузеров, которые его поддерживают.

Отсутствие фона связано с использованием rgba() , который не поддерживается в IE8 и ниже.

Традиционно хорошо предоставлять запасные варианты CSS, которые показывают черный фон для старых браузеров, но показывают полупрозрачный фон для современных браузеров:

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

Это исправление очень специфично для IE, однако практически любой другой браузер поддерживает rgba . Более того, в этом случае вы бы вообще потеряли причудливые плитки Netflix, поэтому было бы лучше вообще не использовать фоновый фильтр! Надежный способ обеспечить кросс-браузерную поддержку — встроить фильтр в само фоновое изображение. Простой, но эффективный.

В любом случае, пока все хорошо — IE8 действительно хорошо отрисовывал домашнюю страницу! Я действительно собираюсь сегодня смотреть «Во все тяжкие » в IE8?

Мой и без того робкий оптимизм тут же рассеялся, когда я просмотрел страницу входа:

Тем не менее, я смог войти в систему и увидел урезанную панель инструментов (без причудливых автоматически расширяющихся трейлеров):

Я нажимал на программу со смутным предвкушением, но, конечно, видел только черный экран.

Амазонка

Хорошо, социальные сети и видео отключены. Осталось только отправиться за покупками.

Я проверил Amazon и был потрясен — это почти неотличимо от опыта, который вы получите в современном браузере:

Раньше меня привлекала хорошая домашняя страница. Итак, давайте нажмем на страницу продукта и посмотрим, не является ли это случайностью.

Нет! Страница продукта тоже выглядела хорошо!

Amazon был не единственным сайтом, который удивил меня своей обратной совместимостью. Википедия выглядела великолепно, как и правительственный веб-сайт Gov.UK. Нелегко иметь сайт, который не выглядит как автомобильная авария в IE8. Большая часть моего опыта была определенно менее отточенной…!

Но устаревшее предупреждение или причудливый макет были не худшим, что я видел сегодня.

Совершенно неработающие сайты

Некоторые сайты были настолько сломаны, что я даже не мог к ним подключиться!

Я задавался вопросом, может ли это быть временной проблемой сети виртуальной машины, но это происходило каждый раз, когда я обновлял страницу, даже когда возвращался на тот же сайт позже в тот же день.

Это происходило на нескольких разных сайтах в течение дня, и в конце концов я пришел к выводу, что это никогда не затрагивало сайты на HTTP — только на HTTPS (но не на всех HTTPS-сайтах). Так в чем была проблема?

Используя Wireshark для анализа сетевого трафика, я снова попытался подключиться к GitHub. Мы видим, что соединение не удалось установить из-за фатальной ошибки «Описание: Версия протокола».

Глядя на настройки по умолчанию в IE8, включен только TLS 1.0, но GitHub прекратил поддержку TLSv1 и TLSv1.1 в феврале 2018 года.

Я поставил галочки для TLS 1.1 и TLS 1.2, перезагрузил страницу и — вуаля! — Я смог просмотреть GitHub!

Большое спасибо моему чрезвычайно талантливому другу Эйдану Фьюстеру за помощь в решении этой проблемы.

Я полностью за обратную совместимость, но здесь возникает интересная дилемма. Согласно Совету по стандартам безопасности PCI, TLS 1.0 небезопасен и не должен больше использоваться. Но при принудительном использовании TLS 1.1 или более поздней версии некоторые пользователи неизбежно будут заблокированы (и не все, вероятно, будут достаточно технически подкованными, чтобы включить TLS 1.2 в своих дополнительных настройках).

Разрешая использовать старые небезопасные стандарты и позволяя пользователям продолжать подключаться к нашим сайтам, мы не помогаем им — мы наносим им вред, не давая им повода для перехода на более безопасные технологии. Итак, как далеко вы должны зайти в поддержке старых браузеров?

Как я могу начать поддерживать старые браузеры?

Когда некоторые люди думают о «поддержке старых браузеров», они могут иметь в виду те проприетарные старые хаки для IE, как в тот раз, когда BBC пришлось делать какие-то невероятно грубые вещи для поддержки содержимого iframe в IE7.

Или они могут подумать о том, чтобы заставить что-то работать в «причудливом режиме» Internet Explorer; специфический для IE режим работы, который сильно отличается от стандартов.

Но «поддержка старых браузеров» сильно отличается от «взлома его для IE». Я не сторонник последнего, но мы должны прагматично попытаться сделать первое. Мантра, которой я стараюсь придерживаться как веб-разработчик, такова:

«Оптимизируйте для большинства, приложите усилия для меньшинства и никогда не жертвуйте безопасностью».

Сейчас я отойду от мира IE8 и расскажу об общих, устойчивых решениях для поддержки устаревших браузеров.

Существует две общие стратегии поддержки старых браузеров, обе начинаются с буквы P:

1. Полифиллинг
   Стремитесь к равенству функций для всех, заполняя недостающие функции браузера.
2. Прогрессивное улучшение
   Начните с основного опыта, а затем используйте обнаружение функций для добавления функциональности.

Эти стратегии не исключают друг друга; их можно использовать в тандеме. При любом подходе необходимо принять ряд решений по реализации, каждое из которых имеет свои нюансы, о которых я расскажу более подробно ниже.

Полифиллинг

Для некоторых веб-сайтов или веб-страниц JavaScript очень важен для функциональности, и вы просто хотите предоставить рабочий JavaScript как можно большему количеству браузеров.

Есть несколько способов сделать это, но сначала урок истории.

Краткая история ECMAScript

ECMAScript — это стандарт, а JavaScript — реализация этого стандарта. Это означает, что ES5 — это «ECMAScript версии 5», а ES6 — «ECMAScript версии 6». Как ни странно, ES2015 такой же, как ES6.

ES6 было популярным названием этой версии до ее выпуска, но ES2015 является официальным названием, и все последующие версии ECMAScript связаны с годом их выпуска.

Примечание . Все это услужливо объяснил Брэндон Морелли в отличном сообщении в блоге, в котором объясняется полная история версий JavaScript.

На момент написания последним стандартом является ES2018 (ES9). Большинство современных браузеров поддерживают как минимум ES2015. Почти каждый браузер поддерживает ES5.

Технически IE8 — это не ES5. Это даже не ES4 (которого не существует — проект был заброшен). IE8 использует реализацию Microsoft ECMAScript 3, называемую JScript. IE8 имеет некоторую поддержку ES5, но был выпущен за несколько месяцев до того, как были опубликованы стандарты ES5, и поэтому имеет несоответствие поддержки.

Транспиляция против полифилинга

Вы можете написать ES5 JavaScript, и он будет работать почти в каждом древнем браузере:

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

Вы также можете продолжать писать весь свой JavaScript таким же образом, чтобы обеспечить обратную совместимость навсегда. Но вы упустите новые функции и синтаксический сахар, которые стали доступны в развивающихся версиях JavaScript, позволяя вам писать такие вещи, как:

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

Попробуйте запустить этот JavaScript в более старом браузере, и он выдаст ошибку. Нам нужно преобразовать код в более раннюю версию JavaScript, которую браузер сможет понять (т. е. преобразовать наш код ES6 в ES5 с помощью автоматизированных инструментов).

Теперь предположим, что наш код использует стандартный метод ES5, такой как Array.indexOf . Большинство браузеров имеют собственную реализацию этого и будут работать нормально, но IE8 сломается. Помните, что IE8 был выпущен за несколько месяцев до того, как были опубликованы стандарты ES5, и поэтому у него несоответствие поддержки? Одним из примеров этого является функция indexOf , реализованная для String , но не для Array .

Если мы попытаемся запустить метод Array.indexOf в IE8, это не удастся. Но если мы уже пишем на ES5, что еще мы можем сделать?

Мы можем полифилить поведение отсутствующего метода. Разработчики традиционно полифилят каждую необходимую им функцию, копируя и вставляя код или подключая сторонние библиотеки полифилла. Многие функции JavaScript имеют хорошие реализации полифилла на соответствующей странице Mozilla MDN, но стоит отметить, что существует несколько способов полифилла одной и той же функции.

Например, чтобы убедиться, что вы можете использовать метод Array.indexOf в IE8, вы должны скопировать и вставить полифил следующим образом:

 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); }

До тех пор, пока вы вызываете polyfill до того, как загрузите какой-либо собственный JS, и при условии, что вы не используете какую-либо функцию JavaScript ES5, кроме Array.indexOf , ваша страница будет работать в IE8.

Полифилы можно использовать для добавления всех видов отсутствующих функций. Например, существуют полифиллы для включения селекторов CSS3, таких как :last-child (не поддерживается в IE8) или атрибута placeholder (не поддерживается в IE9).

Полифилы различаются по размеру и эффективности и иногда зависят от внешних библиотек, таких как jQuery.

Вы также можете услышать о «прокладках», а не о «полифиллах». Не зацикливайтесь на названии — люди используют эти два термина как синонимы. Но с технической точки зрения прокладка — это код, который перехватывает вызов API и обеспечивает уровень абстракции. Полифилл — это тип прокладки в браузере . Он специально использует JavaScript для модификации новых функций HTML/CSS/JS в старых браузерах.

Краткое изложение стратегии «ручного импорта полифиллов»:

• Полный контроль над выбором полифиллов;
• Подходит для основных веб-сайтов;
• ️ Без дополнительных инструментов вы вынуждены писать на родном ES5 JavaScript;
• ️ Сложно управлять всеми вашими полифиллами на микроуровне;
• ️ Из коробки все ваши пользователи получат полифиллы, нужны они им или нет.

Вавилон Полифилл

Я говорил о преобразовании кода ES6 в ES5. Вы делаете это с помощью транспилятора , самым популярным из которых является Babel.

Babel настраивается через файл .babelrc в корне вашего проекта. В нем вы указываете на различные плагины и пресеты Babel. Обычно для каждого преобразования синтаксиса и полифилла браузера есть по одному.

Микроуправление ими и их синхронизация со списком поддержки вашего браузера может быть проблемой, поэтому стандартная настройка в настоящее время заключается в делегировании этого микроуправления модулю @babel/preset-env. При такой настройке вы просто даете Babel список версий браузеров, которые вы хотите поддерживать, и он делает всю тяжелую работу за вас:

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

Параметр конфигурации useBuiltIns для @babel/preset-env — это место, где происходит волшебство в сочетании с import "@babel/polyfill" (другой модуль) в точке входа вашего приложения.

• Если этот параметр опущен, useBuiltIns ничего не делает. Весь @babel/polyfill включен в ваше приложение, что довольно тяжело.
• Если установлено значение "entry" , он преобразует импорт @babel/polyfill в несколько меньших импортов, импортируя минимальные полифилы, необходимые для полифилла целевых браузеров, которые вы указали в своем .babelrc (в этом примере, Chrome 58 и IE 11) .
• Настройка "usage" делает еще один шаг вперед, выполняя анализ кода и импортируя полифиллы только для функций, которые фактически используются . Он классифицируется как «экспериментальный», но ошибается в сторону «слишком много полифилла», а не «слишком мало». В любом случае, я не понимаю, как это возможно, чтобы создать больший пакет, чем "entry" или false , так что это хороший вариант для выбора (и это то, как мы идем на BBC).

Используя Babel, вы можете транспилировать и полифилить свой JavaScript перед развертыванием в рабочей среде, а также обеспечивать поддержку в определенном минимальном базовом наборе браузеров. NB, еще одним популярным инструментом является TypeScript, у которого есть собственный транспилятор, который транспилирует в ES3, теоретически поддерживающий IE8 из коробки.

Резюме использования @babel/preset-env для полифилинга:

• Делегируйте микроуправление полифиллами инструменту;
• Автоматизированный инструмент помогает предотвратить включение полифилов, которые вам не нужны;
• масштабируется до более крупных и сложных сайтов;
• ️ Из коробки полифиллы получат все ваши пользователи, нужны они им или нет;
• ️ Трудно уследить за тем, что именно входит в комплект вашего приложения.

Ленивая загрузка полифиллов с помощью Webpack и динамического импорта

Можно использовать новое предложение import() для обнаружения функций и динамической загрузки полифилов до инициализации вашего приложения. На практике это выглядит примерно так:

 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); });

Этот пример кода беззастенчиво скопирован из очень хорошей статьи «Отложенная загрузка полифиллов с помощью Webpack и динамического импорта», в которой этот метод рассматривается более подробно.

Резюме:

• Не перегружает современные браузеры ненужными полифиллами;
• ️ Требуется ручное управление каждым полифиллом.

полифилл.ио

polyfill.io — это полифиллинг как сервис, созданный Financial Times. Он работает, когда ваша страница отправляет одиночный запрос скрипта к polyfill.io, при необходимости перечисляя конкретные функции, которые вам нужны для полифилла. Затем их сервер анализирует строку пользовательского агента и соответствующим образом заполняет сценарий. Это избавляет вас от необходимости вручную предоставлять свои собственные решения полифилла.

Вот JavaScript, который polyfill.io возвращает для запроса, сделанного из IE8:

Вот тот же запрос polyfill.io, но запрос пришел из современного Chrome:

Все, что требуется от вашего сайта, — это один вызов скрипта.

Резюме:

• Простота включения в ваше веб-приложение;
• делегирует ответственность за знание полифилла третьей стороне;
• ️ С другой стороны, теперь вы полагаетесь на сторонний сервис;
• ️ Выполняет блокирующий вызов <script> даже для современных браузеров, которым не нужны полифиллы.

Прогрессивное улучшение

Полифиллинг — невероятно полезный метод для поддержки старых браузеров, но он может сильно раздувать веб-страницы и имеет ограниченные возможности.

Метод прогрессивного улучшения, с другой стороны, — отличный способ гарантировать базовые возможности для всех браузеров, сохраняя при этом полную функциональность для ваших пользователей в современных браузерах. Это должно быть достижимо на большинстве сайтов.

Принцип таков: начните с базового HTML (и стилей, необязательно) и «постепенно улучшайте» страницу с помощью функций JavaScript. Преимущество заключается в том, что если браузер является устаревшим или если JavaScript не работает в какой-либо момент его доставки, ваш сайт все равно должен работать.

Термин «прогрессивное улучшение» часто используется как синоним «ненавязчивого JavaScript». По сути, они означают одно и то же, но последний идет немного дальше, поскольку вы не должны засорять свой HTML множеством атрибутов, идентификаторов и классов, которые используются только вашим JavaScript.

Cut-The-Горчица

Техника BBC «сокращение горчицы» (CTM) — это испытанная реализация прогрессивного улучшения. Принцип заключается в том, что вы пишете прочный базовый опыт работы с HTML, и перед загрузкой какого-либо расширяющего JavaScript вы проверяете минимальный уровень поддержки. Исходная реализация проверена на наличие стандартных функций HTML5:

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

По мере появления новых функций и старения старых браузеров наши базовые показатели сокращения горчицы будут меняться. Например, новый синтаксис JavaScript, такой как стрелочные функции ES6, будет означать, что эта встроенная проверка CTM не может быть проанализирована даже в устаревших браузерах — даже без безопасного выполнения и сбоя проверки CTM — поэтому может иметь неожиданные побочные эффекты, такие как нарушение другого стороннего JavaScript. (например, Google Analytics).

Чтобы даже не пытаться анализировать нетранспилированный современный JS, мы можем применить этот «современный взгляд» на технику CTM, взятую из блога @snugug, в которой мы используем тот факт, что старые браузеры не понимают type="module" и благополучно пропустим его. Напротив, современные браузеры будут игнорировать объявления <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>

Этот подход хорош, если вы согласны рассматривать браузеры ES6 в качестве нового минимального базового уровня функциональности (~92% браузеров по всему миру на момент написания статьи).

Однако так же, как развивается мир JavaScript, развивается и мир CSS. Теперь, когда у нас есть Grid, Flexbox, переменные CSS и тому подобное (каждая с разной эффективностью отката), невозможно сказать, какая комбинация поддержки CSS может быть в старом браузере, что может привести к мешанине из «современного» и «устаревшего». укладка, результат которой выглядит ломаным. Таким образом, сайты все чаще выбирают CTM для своего стиля , поэтому теперь HTML является основной базовой линией, а CSS и JS рассматриваются как усовершенствования.

Методы CTM на основе JavaScript, которые мы видели до сих пор, имеют несколько недостатков, если вы каким-либо образом используете наличие JavaScript для применения CSS:

1. Встроенный JavaScript блокирует. Браузеры должны загрузить, проанализировать и выполнить ваш JavaScript, прежде чем вы получите какие-либо стили. Поэтому пользователи могут увидеть мелькание нестилизованного текста.
2. У некоторых пользователей могут быть современные браузеры, но они решили отключить JavaScript. CTM на основе JavaScript не позволяет им получить стилизованный сайт, даже если они вполне способны его получить.

«Окончательный» подход заключается в использовании медиа-запросов CSS в качестве лакмусовой бумажки. Этот метод «CSSCTM» активно используется на таких сайтах, как 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>

Этот подход довольно ненадежен — случайное переопределение свойства clear в селекторе body может «сломать» ваш сайт, — но он предлагает наилучшую производительность. В этой конкретной реализации используются медиа-запросы, которые поддерживаются по крайней мере в IE 9, iOS 7 и Android 4.4, что является вполне разумной современной базой.

«Cuts the горчица» во всех своих различных обличьях выполняет два основных принципа:

1. Широкая поддержка пользователей;
2. Эффективно приложенные усилия разработчиков.

Сайты просто не могут вместить каждую комбинацию браузера/операционной системы/сетевого подключения/конфигурации пользователя. Такие методы, как сокращение горчицы, помогают рационализировать браузеры до уровня C и A, в соответствии с моделью Graded Browser Support от Yahoo! .

Cuts-The-Mustard: антипаттерн?

Существует аргумент, что применение глобального бинарного решения «основной» против «расширенного» — не лучший возможный опыт для наших пользователей. Это обеспечивает решение сложной технической проблемы, но что, если браузер поддерживает 90% функций в вашем глобальном тесте CTM, а эта конкретная страница даже не использует 10% функций, с которыми она не работает? В этом случае пользователь получит основной опыт, так как проверка CTM завершится ошибкой. Но мы могли бы дать им полный опыт.

А как насчет случаев, когда данная страница использует функцию, которую браузер не поддерживает? Что ж, при переходе к компонентизации у нас мог бы быть запасной вариант для конкретной функции (или граница ошибки), а не резервный вариант на уровне страницы.

Мы делаем это каждый день в нашей веб-разработке. Подумайте о том, чтобы использовать веб-шрифт; разные браузеры имеют разные уровни поддержки шрифтов. Что мы делаем? Мы предоставляем несколько вариантов файла шрифта и позволяем браузеру решить, какой из них загрузить:

 @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'); }

У нас есть аналогичный запасной вариант с видео HTML5. Современные браузеры сами выбирают, какой формат видео они хотят использовать, тогда как устаревшие браузеры, которые не понимают, что такое элемент <video> , просто отображают резервный текст:

 <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>

Подход к вложению, который мы видели ранее, используемый BBC для запасных вариантов PNG для SVG, является основой для адаптивного элемента изображения <picture> . Современные браузеры будут отображать наиболее подходящее изображение на основе предоставленного атрибута media , тогда как устаревшие браузеры, которые не понимают, что такое элемент <picture> , будут отображать запасной вариант <img> .

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

Спецификация HTML тщательно развивалась на протяжении многих лет, чтобы обеспечить базовый резервный механизм для всех браузеров, в то же время предоставляя функции и оптимизации для современных браузеров, которые их понимают.

Мы могли бы применить аналогичный принцип к нашему коду JavaScript. Представьте себе такую ​​функцию, где метод foo содержит какой-то сложный JS:

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

Перед вызовом foo мы проверяем, поддерживается ли Feature в этом браузере, вызывая его метод browserSupported . Если он не поддерживается, мы даже не пытаемся вызвать код, который в противном случае привел бы к ошибке на нашей странице.

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

Этот метод означает, что мы можем избежать использования полифиллов и просто использовать то, что изначально поддерживается каждым отдельным браузером, изящно снижая отдельные функции, если они не поддерживаются.

Обратите внимание, что в приведенном выше примере я предполагаю, что код транспилируется в ES5, чтобы синтаксис был понятен всеми браузерами, но я не предполагаю, что какой-либо код полифиллен . Если бы мы хотели избежать транспиляции кода, мы могли бы применить тот же принцип, но с помощью type="module" взять на себя смелость, но с оговоркой, что он уже имеет минимальные требования к браузеру ES6, поэтому только вероятно, станет хорошим решением через пару лет:

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

Мы рассмотрели HTML и рассмотрели JavaScript. Мы также можем применять локализованные запасные варианты в CSS; в CSS есть ключевое слово @supports , которое позволяет условно применять CSS в зависимости от наличия или отсутствия поддержки функции CSS. Однако по иронии судьбы это предостережение от того факта, что оно не поддерживается повсеместно. Это просто требует осторожного применения; есть отличный пост в блоге Mozilla о том, как использовать запросы функций в CSS.

В идеальном мире нам не нужна глобальная проверка на отказ от горчицы. Вместо этого каждая отдельная функция HTML, JS или CSS должна быть автономной и иметь свои собственные границы ошибок. Я ожидаю, что в мире веб-компонентов, теневого DOM и пользовательских элементов мы увидим больший сдвиг в сторону такого подхода. Но это значительно усложняет прогнозирование и тестирование вашего сайта в целом, и могут возникнуть непреднамеренные побочные эффекты, если, скажем, стиль одного компонента влияет на макет другого.

Две основные стратегии обратной совместимости

Резюме полифиллинга как стратегии :

• Может предоставлять функциональные возможности JS на стороне клиента большинству пользователей.
• Может быть проще кодировать, делегируя проблему обратной совместимости полифиллу.
• ️ В зависимости от реализации может отрицательно сказаться на производительности пользователей, которым не нужны полифиллы.
• ️ В зависимости от сложности приложения и возраста браузера может потребоваться много полифиллов, и поэтому он будет работать очень плохо. Мы рискуем отправить мегабайты полифилов тем самым браузерам, которые наименее подготовлены к этому.

Краткое изложение прогрессивного улучшения как стратегии :

• Традиционный CTM упрощает сегментацию кода и его ручное тестирование.
• Гарантированный базовый уровень опыта для всех пользователей.
• ️ Может излишне предоставлять основной опыт пользователям, которые могут справиться с расширенным опытом.
• ️ Не очень подходит для сайтов, которым для функциональности требуется JS на стороне клиента.
• ️ Иногда трудно сбалансировать надежную стратегию прогрессивного улучшения с производительным первым рендерингом. Существует риск чрезмерного приоритета «основного» опыта в ущерб 90% ваших пользователей, которые получают «полный» опыт (например, предоставление небольших изображений для noJS, а затем замена изображений с высоким разрешением при отложенной загрузке означает, что мы потратили много ресурсов для загрузки на активы, которые даже никогда не просматриваются).

Заключение

IE8 когда-то был передовым браузером. (Нет, серьезно.) То же самое можно сказать о Chrome и Firefox сегодня.

Если сегодняшние веб-сайты совершенно непригодны для использования в IE8, веб-сайты через десять лет, вероятно, будут такими же непригодными для использования в современных браузерах, несмотря на то, что они построены на открытых технологиях HTML, CSS и JavaScript.

Остановитесь и задумайтесь об этом на мгновение. Разве это не немного страшно? (Тем не менее, если вы не можете отказаться от браузеров через десять лет и после того, как компания, которая его создала, объявила его устаревшим, то когда вы сможете это сделать?)

IE8 сегодня является козлом отпущения. Завтра это будет IE9, в следующем году это будет Safari, через год это может быть Chrome. Вы можете заменить IE8 на «старый браузер по выбору». Дело в том, что всегда будет некоторая разница между браузерами, для которых их создают разработчики, и браузерами, которые используют люди. Мы должны перестать насмехаться над этим и начать инвестировать в надежные инклюзивные инженерные решения . Побочные эффекты этих стратегий, как правило, приносят дивиденды с точки зрения доступности, производительности и устойчивости сети, поэтому здесь имеет место более широкая картина.

Мы склонны не думать о числах для чтения с экрана. Мы просто считаем само собой разумеющимся, что морально правильно делать все возможное, чтобы поддерживать пользователей, у которых нет другого способа потреблять наш контент, не по нашей вине. Тот же принцип применим и к людям, использующим старые браузеры.

Мы рассмотрели некоторые стратегии высокого уровня для создания надежных сайтов, которые должны в некоторой степени продолжать работать в широком спектре устаревших и современных браузеров.

Еще раз, отказ от ответственности: не взламывайте вещи для IE. Это было бы упущено суть. Но имейте в виду, что самые разные люди используют самые разные браузеры по самым разным причинам, и что есть несколько надежных инженерных подходов, которые мы можем использовать, чтобы сделать Интернет доступным для всех.

Оптимизируйте для большинства, приложите усилия для меньшинства и никогда не жертвуйте безопасностью.

Дальнейшее чтение на SmashingMag:

• Веб-стандарты: что, почему и как
• Smart Bundling: как обслуживать устаревший код только для устаревших браузеров
• Не используйте атрибут Placeholder
• Проектирование для безбраузерного Интернета