Браузеры и их совместимость со стандартами html
Особенно это важно в эпоху адаптивного веб-дизайна, когда на первый план выходит способность front-end адаптироваться к широкому диапазону различных устройств и при этом обеспечивать оптимальное качество просмотра.
Раньше дизайнер создавал макет дизайна в Photoshop , который затем переносился в HTML и CSS . На сегодняшний день технологические изменения заставляют переосмыслить эту концепцию. Мы больше не можем предсказать, какой браузер, разрешение или устройство будут использоваться для просмотра сайта. Ушли в прошлое те времена, когда большинство компьютеров использовало фиксированное разрешение 1024 на 768 пикселей, и можно было разрабатывать сайты со статическими размерами.
В данной статье мы рассмотрим текущую статистику по просмотрам веб-страниц, приведем перечень средств, которые помогают решать различные проблемы совместимости.
Текущая ситуация
Общемировая статистика за 2015 год показывает, что топ-14 используемых разрешений экрана находятся в диапазоне от 1920 на 1080 до 320 на 480 пикселей.
Хотя Windows 7 ( 31,20% ) до сих пор удерживает большую долю рынка, мобильные платформы начинают заменять традиционные, стационарные.
Github больше не поддерживает IE 7 и 8 . Кроме этого часть функционала Twitter не работает в IE8 . И, наконец, популярный фреймворк не будет поддерживать IE8 , начиная с 4 версии .
Тем не менее, статистика использования может варьироваться в зависимости от региона: 6,11% пользователей в Китае в 2015 году по-прежнему просматривали страницы через IE8 . Если принять во внимание, что в Китае было около 724400000 интернет-пользователей, можно понять, что в этом году примерно 44200000 китайцев продолжают использовать IE8 .
Поэтому региональные рынки, специфические клиенты и требования отрасли могут существенно отличаться. Особенно это касается корпоративных и правительственных учреждений.
Проанализируйте свою аудиторию
Основной принцип здесь такой: чем выше требуемая кроссбраузерность, тем больше времени потребуется на разработку, что приводит к увеличению стоимости проекта. Чтобы принять взвешенное, экономически обоснованное решение, нужно задать себе следующие вопросы:
- Какова ваша целевая аудитория?
- На какой географический регион нужно настроить таргетинг?
- Какие браузеры и устройства используют ваши посетители?
- Существуют ли в компании или отрасли технические факторы, которые заставляют вас поддерживать конкретные версии старых браузеров?
- Каковы с точки зрения электронной коммерции коэффициенты конверсии и рентабельности различных групп пользователей по версиям браузеров?
Ответив на эти вопросы с помощью статистических данных, например, из Google Analytics , можно получить объективную картину.
Проблемы в устаревших браузерах и различные подходы к разработке
Адаптивный веб-дизайн во многом зависит от медиа-запросов, с помощью которых изменяется CSS для различных разрешений экрана. Кроме этого современные сайты характеризуются использованием семантических элементов HTML5 (например, <header>, <nav>, <section>, <aside>, <footer>) для группировки компонентов дизайна. Селекторы CSS3 используются для выбора конкретных элементов и дальнейшего назначения стилей (например, [attribute*=value] , :checked , :nth-child(n) , :not(selector) , :last-child)) . И, наконец, адаптивная типографика часто задается с помощью единиц REM ( root em ).
Это подводит нас к следующим техническим сложностям при реализации CSS кроссбраузерности:
- Медиа-запросы CSS3 : не поддерживается в IE6 , 7 и 8 ;
- Семантические элементы HTML5 : не поддерживается в IE6 , 7 и 8 ;
- Селекторы CSS3 : не поддерживается в IE6 . Только частично поддерживаются в IE7 и 8 ;
- Единицы REM : не поддерживается в IE6 , 7 и 8 . Только частично поддерживаются в IE9 и 10 ;
- Лимит количества правил CSS : IE9 и ниже поддерживают только 4095 CSS-селекторов . Правила после 4095-ого селектора не применяются.
Указанные выше ошибки будут иметь наибольшее влияние на стратегию, применяемую при реализации адаптивного дизайна.
Существуют две основных стратегии разработки: постепенное упрощение и прогрессивное улучшение .
С другой стороны, пользователям старых браузеров и медленного интернет-соединения будет предлагаться графически усеченная, но все еще функциональная версия сайта.
Подобный подход при реализации кроссбраузерности предполагает начало разработки с простой версии, к которой затем добавляются более сложные элементы. Старые браузеры смогут отображать сайт с базовым уровнем опыта взаимодействия. А новые функции HTML / CSS / JavaScript будут доступны в браузерах, которые могут реально их использовать.
В противоположность этому, постепенное упрощение обеспечивает полнофункциональный уровень UX в современных браузерах. А затем постепенно уменьшает его сложность для старых браузеров за счет графики, но, не касаясь функционала. Идея заключается в том, чтобы начать разработку с новейших веб-стандартов, а затем попытаться минимизировать проблемы, связанные со старыми браузерами.
Какой подход выберете вы, зависит от личных предпочтений и условий проекта:
- Прогрессивное улучшение обеспечивает большую стабильность, так как вы можете постепенно добавлять новые функции для современных браузеров. Но оно требует более тщательного планирования;
- Некоторые разработчики утверждают, что нет смысла поддерживать устаревшие браузеры и должны использоваться новейшие технологии. Поддержка современных браузеров дает намного лучший опыт взаимодействия;
- Существует мнение, что прогрессивное улучшение мертво, так как множество JavaScript-приложений не работают надлежащим образом при этом подходе;
- Веб-доступность для общественных учреждений может быть определена в юридических требованиях конкретных территориальных образований, и это может повлечь необходимость применения особого подхода.
Учитывая появление таких инструментов для определения функций, как Modernizr , лично я склоняюсь к использованию постепенного упрощения и черного списка браузеров при разработке совместимых сайтов.
Чтобы как можно скорее обнаружить потенциальные проблемы кроссбраузерности JavaScript , нужно в процессе разработки тестировать сайт в различных браузерах и разрешениях. Существуют различные программные эмуляторы, которые могут нам помочь:
Normalize.css и CSS Autoprefixer
Обычно я начинаю новые проекты в CDN со сброса CSS с помощью Normalize.css , который обеспечивает лучшую кроссбраузерность при определении стилей HTML-элементов , используемых по умолчанию, вплоть до Internet Explorer 8 . Normalize.css сохраняет нужные стили элементов, нормализует их внешний вид и исправляет ряд ошибок и несоответствий в различных браузерах.
Кроме этого многие устаревшие браузеры не могут интерпретировать неизвестные элементы HTML и свойства CSS . Когда браузер встречает фрагмент HTML или CSS , который он не понимает, то игнорирует его и продолжает процесс отображения. Многие приложения используют вендорные префиксы, чтобы добавить новые, экспериментальные или нестандартные функции CSS до их реализации в спецификации:
Проблема заключается в том, что префиксы неудобны в использовании и с ними связано много ошибок. Поэтому я использую плагин CSS Autoprefixer в сочетании с Grunt .
В качестве примера рассмотрим следующий класс CSS :
С помощью CSS Autoprefixer он преобразуется в:
Условные комментарии
Если нужно создать резервный CSS или включить кроссбраузерность JavaScript для ранних версий Internet Explorer , то можете использовать условные комментарии . Они поддерживаются в Internet Explorer 5-9 , они используют синтаксис комментариев HTML в сочетании с логическими значениями. В зависимости от логического значения ( true или false ) код внутри тегов комментариев будет выводиться или скрываться в соответствующих версиях браузера:
Код автоматически скрывается во всех браузерах, не поддерживающих условные комментарии. Наглядным примером того, как условные комментарии могут быть эффективно использованы на практике, является HTML5 Boilerplate , который добавляет специфические классы CSS для устаревших версий Internet Explorer :
Полифиллы
Ниже приведено несколько полифиллов, предназначенных для устранения проблем кроссбраузерности сайта, указанных в пункте 3:
Для использования указанных полифиллов, их нужно добавить из CDN или в виде файла в корректном формате внутри условных комментариев в разделе <head> (не забудьте включить одну из необходимых для Selectivizr библиотек JavaScript ):
Определение функций с помощью Modernizr
Библиотека Modernizr , написанная на JavaScript , поможет проверить кроссбраузерность сайта: поддерживается ли в различных браузерах конкретная функция HTML5 или CSS3 . Если функция не доступна, то может быть загружен альтернативный CSS или JavaScript-код .
Идея заключается в том, чтобы напрямую определять функциональные возможности браузера, а не пытаться установить его конкретную версию. И на основании этого выводить его функциональные возможности, что является менее эффективным и надежным способом.
Стоит отметить, что Modernizr не добавляет недостающие функции в браузер. Поэтому вам нужно будет предоставить код из резервного CSS или полифилла.
Для начала необходимо скачать полнофункциональную сборку. Позже, когда вы будете готовы к разработке, можно создать пользовательскую сборку со специфическими функциями, которые вы тестируете. Все, что нужно сделать, это добавить класс .no-js в HTML-тег сайта и включить скрипт Modernizr в разделе head после любого CSS-файла :
Класс .no-js используется, чтобы проверить, включен ли JavaScript в браузере пользователя. Если он включен, Modernizr заменит .no-js классом .js . Функция тестирования Modernizr анализирует, поддерживается ли в браузере конкретная функция и генерирует ряд классов, которые добавляются в HTML-элемент . Google Chrome 47.0.2526.111 , например, будет возвращать следующие классы объектов.
В настоящее время Modernizr доступен в качестве глобального объекта, который можно вызвать в сочетании с названием функции, чтобы проверить существует ли она. Он возвращает логическое значение ( true или false ).
Рассмотрим два простых примера CSS и JavaScript .
Пример решения проблем CSS кроссбраузерности: проверка поддержки SVG и предоставление в качестве резервного варианта PNG
Пример JavaScript: определение border-radius и добавление соответствующих классов CSS
Округление углов рамки не поддерживается в IE8 и ниже. Мы можем создавать различные CSS-классы , которые применяются в зависимости от наличия функции border-radius :
Теперь можно использовать JavaScript , чтобы сохранить целевой идентификатор в качестве переменной, а затем через условие добавить классы CSS :
Заключение
Когда речь идет об адаптивном веб-дизайне в устаревших браузерах, не существует какого-то универсального решения. Важно проанализировать аудиторию ресурса, чтобы получить представление о реальной численности пользователей браузеров. Затем нужно тщательно протестировать сайт, чтобы выявить потенциальные проблемы кроссбраузерности.
Тщательно выбирая правильные полифиллы, добавляемые в условных комментариях, можно обойти отсутствие наиболее существенных функций HTML5 . Кроме этого возможность определения с помощью Modernizr является удобным способом предоставить резервные CSS и JavaScript для устаревших браузеров, в которых отсутствует поддержка современного функционала HTML5 и CSS3 .
Дайте знать, что вы думаете по данной теме материала в комментариях. Мы очень благодарим вас за ваши комментарии, подписки, лайки, отклики, дизлайки!
Пожалуйста, опубликуйте ваши комментарии по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!
Подробный список совместимости основных браузеров CSS3 и HTML5
Поддержка CSS3 и HTML5 ведущими популярными браузерами становится все более совершенной, и отдел IE, который с разбитым сердцем заставил многих разработчиков переднего плана, начал принимать стандарт. Всего несколько дней назад лидер сообщества W3C по HTML5 Шелли объявил, что разработка HTML5 близится к завершению, и если все пойдет хорошо, HTML5 официально станет международным стандартом в 2012 году.
Конечно, даже если стандарт официально установлен, современным браузерам потребуется много времени, чтобы охватить большинство пользователей. Если вы хотите использовать CSS3 и HTML5 для создания своего сайта сейчас, вам необходимо иметь полное представление о поддержке этих двух новых технологий в различных браузерах.
CSS3 являетсясекс
Как видно из таблицы, CSS Transforms 3D пока не поддерживает браузер. Другие платформы, кроме того, поддерживаются на платформе Windows. Поддерживаются все Chrome и Safari. Второй лучший вариант поддержки - Opera и Firefox. После запуска IE из красного креста Догнать. Safari по-прежнему хорошо работает на платформе Mac, затем следуют Firefox и Opera.
Наиболее восхитителен этот список. За исключением версий ниже IE 9, все остальные браузеры уже поддерживают селекторы CSS3, включая IE 9 и IE 10, которые будут выпущены в следующем году.
HTML5 веб-приложение
Как видно из таблицы, кроме клиентской базы данных IndexDB и сенсорных событий, все остальные функции поддерживаются Chrome и Safari.
Было проверено, что Chrome 10 и Firefox 4 уже поддерживают IndexDB, Firefox 4 также поддерживает WebSocket, но по соображениям безопасности он не включен по умолчанию, мы можем повторно включить WebSocket с помощью about: config, просто включив network.websocket.override-security-block вариант.
HTML5 графика и встроенный контент
Это должно быть самой ожидаемой вещью в HTML5, встроенном холсте, видео, аудио, SVG, WebGL и других объектах. Все поддерживаются Chrome, Firefox, IE 9.
HTML5 аудио кодирование
Вся поддержка Chrome, вся поддержка Safari кроме Ogg Vorbis, IE 9 начал поддерживать MP3И AAC.
HTML5 кодирование видео
Chrome поддерживает все, я не знаю, сможет ли H.264 стать единым стандартом кодирования видео, я с нетерпением жду этого.
HTML5 объект формы
На платформах Windows и Mac Opera полностью поддерживает объекты форм HTML5, а семейство IE полностью уничтожено.
Атрибуты формы HTML5
IE был снова уничтожен, Opera по-прежнему полностью поддерживает его, затем Safari, Chrome, Firefox.
Из приведенных выше данных видно, что лучшей поддержкой CSS3 и HTML5 является Chrome, затем Safari, Firefox и Opera одинаково совпадают, IE 9 начал охватывать стандарт. Ввиду этой ситуации, если вы хотите использовать эти две новые технологии для создания сайта первопроходческого опыта, теперь CSS3 и HTML5 могут позволить вам добиться этого, если вы захотите применить его к крупномасштабному реальному проекту, это слишком рано.
Что пишут в блогах
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Татьяна Бирюкова
Как часто заказчики ПО хотят, чтобы их детище работало у любого пользователя, в любых условиях и окружениях? Здесь будет уместен ответ — всегда. Что же скрывается за этой фразой? Что именно требуется для проверки от тестировщика? И как он будет воплощать требования в жизнь?
Не секрет, что WEB-приложения имеют отличия от десктопных. Самое главное отличие и опасение — это то, что мы не знаем, в каком браузере и уж тем более — в какой версии этого браузера откроет приложение наш пользователь.
Сколько существует браузеров
Если вас спросят, сколько браузеров вы знаете, думаю, вы с уверенностью назовете не меньше пяти. А если вас спросить, сколько вообще существует браузеров — возможно, вы задумаетесь.
А если спросить об этом у Гугла? Ответ будет неоднозначный. Количество более-менее известных браузеров сейчас превышает 50 наименований. И возможно, прямо сейчас кто-то выпускает в сеть еще один, свой собственный. А давайте представим, что уже завтра этот “кто-то” выпустит обновление своего браузера. Как же в таких непростых условиях проверить всё?
Какие есть стандарты для создания браузеров
Но и тут есть подводные камни. Стандарты совершенствуются; новые версии браузеров, по крайней мере, стараются совершенствоваться. А старые версии? Мало кто занимается доработкой старых версий. Да вообще никто не занимается. Выпустили новую — и все счастливы. А пользователи, думаете, каждый день проверяют наличие обновлений своего браузера? Тоже вряд ли.
К тому же, не стоит забывать про разработчиков, которые пишут само приложение. Они тоже люди, могут ошибиться в коде, могут не посмотреть в стандарт — бывает всякое. Поэтому, к сожалению, стандарты — не панацея.
Как выбрать браузеры под ваше приложение
Теперь о тестировании. Прежде чем начать непосредственно тестировать то или иное web-приложение, тестировщик должен ознакомиться с требованиями, которые выдвигает заказчик. Бывает так, что в требованиях изначально прописано: “Наш продукт должен работать в браузерах Chrome, начиная с версии 43, и IE, начиная с версии 9”. Или же сам заказчик не может определиться и, конечно же, ему хочется охватить всё и всех. Ну а вдруг, его самый важный потенциальный клиент использует браузер Uran? И что тогда? Он не увидит его приложение вовсе?
Прежде чем тестировщик начнет устанавливать себе все браузеры мира на один компьютер или, наоборот, удалять ненужные 48, можно предложить заказчику провести исследование. Таким образом, тестирование пройдет быстрее и более углубленно. Приложение выйдет в свет раньше. Ну а сам заказчик потратит меньше денежных средств.
Для начала надо определить целевую аудиторию будущего приложения. Кто эти люди, где они живут? Исходя из этих данных в сети можно увидеть статистику использования браузеров — например, самые популярные браузеры Азии. Благодаря таким запросам можно увидеть очень интересные и даже неожиданные результаты. Ну а если приложение в каком-то виде уже существует, можно воспользоваться удобной статистикой от ГуглАналитикс и иметь свои конкретные данные.
Хочу показать вам некоторые сервисы по просмотру статистики:
-
— здесь можно посмотреть данные по каждому месяцу, отследить тенденции. Кроме непосредственно браузеров и их версий можно посмотреть данные по использованию ОС, по разрешениям экрана и мобильным платформам; — здесь собрана статистика по отдельным странам или сторонам света (Азия, Европа, Океания); — на этом сервисе можно самому составить список из интересующих Вас браузеров и их версий; — на Гугл Аналитикс можно будет посмотреть свою собственную статистику.
Как проводить кроссбраузерное тестирование
Тут на помощь приходят эмуляторы. Их тоже существует немало. С помощью одних, например, Browsershots, можно получить скриншоты реальных пользователей с нужных нам браузеров и их версий. С помощью других можно самому выполнять нужные нам действия в самом эмуляторе.
Я хочу рассказать про два из них, которые лично использовала в ходе своей работы.
Например, эмулятор IETester, разработанный специально под этот браузер. В соседних окнах эмулятора можно открыть одну и ту же страницу разными версиями браузера. Это очень удобно и наглядно. Путем сравнения двух соседних вкладок можно легко увидеть несоответствия в отображении. В моей практике эта программа меня не подводила. И вдогонку, еще один её несомненный плюс — программа полностью бесплатна и занимает совсем немного места.
Однако, есть мнения, что отображение в этом эмуляторе не соответствует действительности. Как быть в этой ситуации? Есть решение! Проверить в самом браузере. Если какой-то момент “прям смущает-смущает”, открывайте реальный браузер и смотрите.
Если, например, надо проверить в IE 10, а на компьютере уже есть IE 11? Удалять, переустанавливать, проверять — это неверное решение. Тут на помощь приходят виртуальные машины. Это как компьютер в компьютере.
Например, можно воспользоваться Vmware workstation. И иметь на рабочем компьютере одни версии браузеров, а на виртуальной машине — другие. Можно даже установить несколько таких машин на один компьютер, и после этого иметь под рукой много разного софта. Стоит заметить, что виртуальные машины тоже различаются:
-
— поддерживает работу с Windows и Linux; — только для Windows; — готова к установке Windows, Linux и MAC OS.
Другой эмулятор — Spoon. Им также можно пользоваться абсолютно бесплатно. Он включает в себя широкий выбор браузеров: Firefox, Chrome, Opera, Safari и их разные версии. Тоже довольно удобная программа, которая позволяет в разных окошках на одной странице сравнить разные браузеры.
Разнообразие инструментов для тестирования кроссбраузерности
Конечно, этими двумя программами выбор эмуляторов не ограничивается:
- есть платные Multibrowser и CrossBrowserTesting;
- есть бесплатные — например, Lunascape;
- есть с бесплатным пробным периодом — Browsera.
Каждый тестировщик знает и любит какие-то свои программки.
- делать скриншоты;
- тестировать в разных браузерах и ОС;
- записывать тесты и позже прогонять их на других нужных браузерах.
Кроме записи данный сервис может похвастаться полноценной работой в ОС: т.е., можно в рамках одного теста переключаться между браузерами, задавать разные адреса и даже открывать инструмент разработки.
На что важно обращать внимание при кроссбраузерном тестировании
А зачем вообще тестировщики проводят такое тестирование, что именно они хотят проверить? Как я уже говорила, браузеры — разные, движки, на которых они работают, тоже разные. А это значит, что одни и те же элементы могут отображаться по-разному. Ведь разработчикам во время написания приложения довольно сложно подстроиться сразу под все браузеры и учесть все их особенности.
WEB-приложения по-другому называют клиент-серверные приложения. Здесь клиентом выступает браузер, а сервером — веб-сервер. Браузер принимает от пользователя запрос, отправляет его на сервер. WEB-сервер обрабатывает запрос и передает ответ обратно в виде HTML-страницы. Браузер отрисовывает полученный код в страницу, которую мы с Вами в итоге и видим. То есть, непосредственно от браузера будет зависеть то, какой мы увидим страницу.
Тестировщики при таком виде проверок отслеживают отображение форм, полей, чекбоксов, шрифтов, но наибольшее внимание, конечно же, уделяется интерфейсу: ведь это то, что в первую очередь оценивают пользователи вашего приложения.
Если собрать охапку современных браузеров, то разложить её можно по-разному: по устройствам, по платформам, по типу работы, да хоть по цвету иконок. Самое полезное для разработчика — уметь разложить их по движкам. Именно движок, то есть самое ядро браузера, определяет как он работает с вашей вёрсткой.
При всём разнообразии браузеров, независимых движков довольно мало, а новые появляются очень редко. Так что вместо десятков браузеров вам нужно поддерживать не больше пяти независимых движков. А ещё бывает, что браузеры с одним названием используют разные движки на разных платформах! В общем, всё очень сложно и интересно.
Самый популярный в мире браузерный движок — это Blink. Его использует Chrome и браузеры на его основе: Opera, Samsung Internet, Яндекс.Браузер и другие. Для работы с JavaScript, эти браузеры используют движок V8 — тот же, что и в Node.js. Один из главных разработчиков открытого движка Blink — Google, но в разработке активно участвует не меньше десятка компаний.
WebKit, другой популярный движок, очень похож на Blink. А вообще, наоборот — это Blink похож на WebKit. Это как? В 2013 году Blink форкнули из WebKit. По сути, скопировали. Google собрала вещи и сказала Apple, основному разработчику WebKit, что ей не нравятся её методы работы и теперь всё будет по-другому. Что поделать, опенсорс. И действительно, стало по-другому: основа у WebKit и Blink общая (префиксы webkit , например), но возможности уже довольно разные. На новом WebKit сейчас работают мобильные и десктопные браузеры Safari, на старом — встроенный браузер на Android до версии KitKat.
На движке Gecko работает браузер Firefox, когда-то очень популярный, а сегодня сохраняющий небольшую долю и важную роль в развитии веба и технологий. Префиксы у Gecko свои: moz — Mozilla, но для лучшей совместимости Firefox специально поддерживает некоторые свойства WebKit. Полноценный Firefox на Gecko работает на десктопных платформах и на Android. Параллельно с Gecko, Mozilla разрабатывает экспериментальный движок Servo и меняет некоторые части Gecko прямо на ходу. Например, в следующем Firefox 57 движок CSS заменят на новый.
Браузер Edge работает на всех современных платформах Microsoft, включая мобильные и Xbox. В его основе движок EdgeHTML — недавно как раз вышла его 16-я версия. EdgeHTML тоже форкнули от движка Trident или MSHTML, на котором работал браузер Internet Explorer. Удивительно похоже на историю Blink и WebKit: оба движка сохраняют общие префиксы ( ms и опять немного webkit для совместимости), но сильно отличаются по возможностям. EdgeHTML отбросил всякое старьё и смело развивается: пара крупных релизов в год и даже система голосования за фичи. Trident и IE закрыли в 2015 году.
Кроме движков, полезно ещё знать особенности платформ. Например, на мобильной платформе iOS куча браузеров, помимо встроенного Safari: Chrome, Firefox, Opera, Яндекс, UC и даже Edge недавно выпустили. Но все эти браузеры — просто оболочки над встроенным в систему движком WebKit. Правила этой платформы запрещают использовать другие браузерные движки. А вот на Android большинство браузеров поставляются со своими движками: Firefox, Opera, Samsung, но некоторые используют встроенный Chromium.
Ну вроде всё? А нет! Есть ещё отдельная группа необычных браузеров: они живут не на устройствах пользователей, а глубоко на серверах. На устройствах стоит только лёгкая оболочка, которая запрашивает адрес и получает с сервера набор скриншотов и ссылок, слепленных в сайт. Это прокси-браузеры и они безумно сжимают трафик, но по пути теряют: фирменные шрифты, фоновые картинки, градиенты, скруглённые уголки, тени и вроде того. Opera Mini — один из самых популярных прокси-браузеров. На сервере у него крутится устаревший движок Presto, а ставят его чаще всего на простые телефоны. Но есть и другие, подробнее вам расскажет Тим Кадлек.
Некоторые браузеры работают только на одной платформе: Edge и IE есть только на Windows, Safari только на macOS и iOS. Были когда-то попытки интервенций, но ничего не вышло. Это конечно усложняет тестирование. К счастью, есть сервисы вроде BrowserStack, которые дают вам доступ ко всем существующим браузерам, а Microsoft выкладывает компактные образы Windows для тестирования Edge и IE в виртуальных машинах.
Ладно! Про браузеры мы теперь знаем. А что делать, если тот же браузер, тот же движок — а результат на разных платформах разный? А ничего не поделаешь! На деле браузеры могут сильно отличаться в зависимости от платформы или устройства. Самая большая разница между десктопными и мобильными браузерами — в последних очень много оптимизаций и просто магии. Но можно поймать и разное поведение на десктопных Windows и macOS.
Думаю вы уже поняли, к чему я клоню. Кроссбраузерность — это такой радужный единорог, за которым все гоняются, но никто не может поймать. Цель у погони, безусловно, благородная: чтобы сайты выглядели и работали одинаково хорошо на всех браузерах и всех платформах. И если размеры отступов, шрифта, высоту строки, цвета мы ещё можем более-менее гарантировать, то сглаживание текста, размытие теней, рендеринг графики и внешний вид системных контролов лучше даже не пытаться привести к общему виду.
Так что если для вас пиксель-пёрфект — это попасть в сетку и в горизонтальные размеры блоков, то у вас ещё есть шансы. Но если вы подкручиваете сглаживание текста, количество строк в абзаце или вертикальные размеры блоков с содержимым, строго по макету, вы тратите время впустую. Идеально кроссбраузерный сайт будет выглядеть одинаково чужеродно на всех платформах — ведь у каждой свои особенности, привычные пользователям.
И ещё про тестирование. Как бы хорошо ни имитировал устройства и браузеры эмулятор Chrome DevTools — это только намёк на то, как они будут выглядеть в реальности. Важно проверить результат на настоящих платформах и устройствах, как минимум: на Windows, Android, macOS и iOS. Настоящие пальцы на настоящем устройстве, настоящие браузеры в естественной среде обитания расскажут вам много нового о том, как именно будут пользоваться вашими интерфейсами. Это гораздо важнее того, насколько они похожи на макет.
Читайте также: