Основы кроссбраузерной верстки — что нужно знать
Корректное отображение во всех нужных браузерах на сегодняшний день — must have для любого сайта. Любой маркетолог расскажет, как это важно для лояльности пользователей и конверсии, как это влияет на user experience и еще много аргументов за, но это буду не я 🙂
В этом материале я поделюсь основами кроссбраузерной верстки и буду рада комментариям и советам о том, что еще можно было бы сюда добавить. Итак, начнем.
Что такое кроссбраузерность?
Кроссбраузерность — это термин, означающий способность сайта одинаково отображаться во всех нужных пользователям браузерах.
Почему этот термин вообще вообще возник?
На рынке браузеров существует несколько крупных игроков, которые часто по-разному отображают те или иные HTML элементы и по-разному имплементируют те или иные свойства CSS. Появляется все большее количество новых мобильных устройств со своими браузерами. Internet Explorer продолжает медленно, но уверенно терять своих пользователей, которые переходят в более современные браузеры. Chrome продолжает насиловать оперативную память компьютеров. Microsoft не устает пытаться реабилитировать Edge и с переходом на движок Chromium в марте 2020 года вышел на второе место по количеству пользователей. Все это и многое другое происходит на рынке браузеров, и веб-разработчикам приходится с этим жить, и все это учитывать.
Какие браузеры нужно поддерживать?
Хорошей практикой в любом проекте, будь то продуктовая компания с большим опытом на рынке, или аутсорс, поддерживающий legacy проект или только появившийся старт-ап — изучение целевой аудитории и составление списка поддерживаемых браузеров на основе аналитических данных (чаще всего с помощью инструментов Google Analytics и/или Yandex Metrica).
В Google Analytics собираются примерно такие данные (разумеется, их можно настроить под свои нужды, тут только пример):
Тут можно увидеть количество пользователей, использующих тот или иной браузер, их абсолютное количество, а также процентное соотношение. В соответствии с этими данными принимается решение о браузерах, которые веб-разработчики должны поддерживать, а какие можно игнорировать. Обычно нужно поддерживать все браузеры, у которых процентное количество пользователей превышает 5%. Но в разных компаниях принимаются разные правила и, возможно, в вашей решат, что каждый пользователь важен и нужно будет поддерживать все-все-все 🙂
Что делать, если таких данных нет? Например, вы только-только начали разрабатывать сайт?
Если у вас нет четких требований от маркетологов или других ЛПР (лица принимающие решения) о списке поддерживаемых браузеров, обычно за основу берутся самые доминирующие игроки рынка — Internet Explorer (обычно только 11 версии), Google Chrome, Opera, Мozilla FireFox, Safari, Microsoft Edge — и ориентируются на последние 2–3 их версии.
Как верстать кроссбраузерно?
- Используйте сброс или нормализацию стандартных стилей браузера. Reset.css или normalize.css. Если кратко говорить о подходах, то смысл reset-а в том, чтоб большинство дефолтных стилей браузеров обнулить (все отступы, форматирование и т.д) и на этой основе писать свое. Смысл normalize — привести все эти стили к единому виду и значениям. Подробнее можно изучить по ссылкам:) Есть много сторонников первого подхода, есть много сторонников второго. Можно очень долго с пеной у рта обсуждать преимущества или недостатки каждого из них, но всегда нужно помнить, что инструмент должен подходить под задачу. Выбирайте то, что вам подходит.
- Используйте вендорные префиксы, где это необходимо. Вендорные префиксы — это приставки, добавляемые в свойства CSS, используемые производителями (вендорами) браузеров для экспериментальных, еще не принятых в стандарт CSS свойств. То есть, например, если какой-нибудь из браузеров решил добавить что-нибудь крутое, но этот функционал и правила его поведения еще до конца не оговорены и не утверждены с составителями стандартов, то браузер может имплементировать его с соответствующей приставкой. Свойство с такой приставкой будет работать только в браузере, для которого эта приставка актуальна. Существуют следующие вендорные префиксы:
- -o-для браузера Опера
- -moz- для браузеров из семейства Mozilla
- -ms- для Internet Explorer 8
- —webkit-префикс для браузеров, построенных на движке Webkit, в частности Safari и Chrome (ну и конечно же, новый Edge:)
- -icab-для браузера iCab (альтернативного, как заявлено на родном сайте, браузера для Apple)
- -khtml- KHTML — компонент для просмотра HTML документов разработанный для среды KDE для UNIX-систем.
Например, мы уже давно можем стилизировать placeholder для input-ов, но какие-то браузеры имплементировали это как псевдоэлемент, а какие-то — как псевдокласс. Поэтому, чтобы стилизовать placeholder одинаково для всех браузеров, нужно писать примерно так:
Каждый раз, когда изучаете новое свойство CSS, не поленитесь долистать до конца документации и проверить, необходимо ли дописывать для этого свойства различные вендорные префиксы. Если пишете в чистом HTML и CSS, то это придется делать руками и самостоятельно прописывать вендорные префиксы в CSS.
Но так как мы в 2020, то скорее всего в вашем проекте используется какой-нибудь сборщик, Gulp или Webpack. Для них есть множество плагинов, в частности autoprefixer, которые сами добавят нужные вендорные префиксы в ваш CSS код. Для того, чтобы эти плагины понимали, какие браузеры нужно поддерживать, обычно используется такая вещь, как Browserslist. Просто перечислите настройки и плагины сами добавят эти префиксы там, где нужно.
3. Новые свойства CSS и JS перед использованием проверяйте на сайте caniuse.com. Это ресурс, который отслеживает поддержку самыми популярными браузерами различных свойств CSS и JS. Если вы хотите использовать какую-то технологию, но точно не уверены, кроссбраузерная ли она, и можно ли ее использовать в соответствии с вашими правилами поддержки браузеров, заходите на caniuse и проверяйте. Например, вы думаете, использовать ли в проекте position: sticky для своего хэдера. Вы в процессе изучения данного свойства могли заметить, что иногда авторы статей прямым текстом предупреждают, что технология еще не до конца имплементирована во все браузеры. Идем на caniuse. В поисковую строку вводим position:sticky
И видим таблицу. В данной таблице показано — браузеры, их версии и эти вещи окрашены в разные цвета.
- Ярко зеленый цвет, означает, что свойство полностью поддерживается, вендорный префикс не требуется. По наведению на соответствующий квадрат, можно получить дополнительную информацию
- Светло-зеленый(болотный) цвет, означает, что данное свойство поддерживается частично. Частичная поддержка это значит либо с вендорным префиксом, либо что-то может некорректно отрабатывать в некоторых случаях. По наведению на соответствующий квадрат, можно получить дополнительную информацию и увидеть, что именно может работать не так или не работать вовсе.
- Красный цвет означает, что свойство не поддерживается в данной версии браузера вообще.
Внизу под таблицей есть разные вкладки, которые тоже стоят внимания. Known issues, Notes — это пометки по свойству, о багах или особенностях его поведения в разных браузерах, о которых широко известно. С этой информацией тоже стоит ознакомиться. И тут можно ее искать, если вы столкнулись с багом, связанным с кроссбраузерностью (у вас что-то некорректно работает только в одном браузере, а в остальных все ок).
Глянули? Подходит для вашего проекта? Подходит по всем параметрам, используйте. Не подходит — или не используйте и ищите другие варианты или используйте полифиллы
4. Тестируйте свою работу в разных браузерах. Установите себе самые популярные браузеры последней версии. Некоторые браузеры вы, конечно, не сможете себе установить (например Safari для Windows не выпускают с 2012 года), но все самые популярные, типа Chrome, Mozilla Firefox, Opera, Internet Explorer 11, Edge и так далее у вас должны стоять. Вы должны проверять свою работу, как минимум на тех, что для вашего проекта обозначены обязательными.
Скорее всего, вы не работаете одновременно в Windows, Ubuntu и Mac OS. Наиболее вероятно также то, что у вас на компьютере всего 1 операционная система, которой вам вполне достаточно для продуктивной работы. Но, допустим, вам поставили баг на какое-то окружение, которое вы физически не можете воспроизвести (как вариант — Chrome 79 версии в Windows 10, а вы на Mac OS и в гробу видали этот Windows).
В таком случае на помощь приходят различные эмуляторы, используя которые, можно выбрать нужную вам операционную систему, браузер и в live режиме проверить, как отображается сайт. Из подобных эмуляторов, больше всего мне нравится browserstack.com. Приложение эмулирует не только различные варианты десктопа, но и много вариаций на мобильных телефонах. Очень удобная штука и спасала меня много раз.
Также есть масса сервисов, которые делают скриншоты сайта. Их суть — просто делать скриншоты вашего сайта, эмулируя нужные окружения. Это удобно использовать тестировщикам, но я не нашла от них пользы для разработки. Видеть, что где-то проблема — не велика польза, если не можешь посмотреть причину. В browserstack же для многих окружений доступна опция dev tools. И ты не только видишь проблему, но и можешь ее по-человечески изучить.
5. Интересуйтесь последними обновлениями в браузерах и во фронт-энде в целом. Масса сайтов, типа habr.ru, dou.ua, codeguida.com публикуют подборки с самыми интересными и свежими материалами по фронт-энду. В них часто мелькают различные обновления браузеров, и новинки в веб-разработке. Читайте эти подборки, интересуйтесь обновлениями, держите руку на пульсе.
6. Если вам ставит кто-либо (чаще всего отдел тестирования) баг по кроссбраузерности, попытайтесь выяснить как можно больше деталей. Например, вам ставят баг — в Mozilla Firefox кнопка некликабельна, необходимо исправить. Такой информации обычно недостаточно. Выясните, повторяется ли этот баг только в Mozilla Firefox, или в остальных браузерах тоже. В каких версиях браузера этот баг повторяется, или, возможно, во всех. В какой операционной системе (Ubuntu, Windows, MacOS, может другие). Эти вопросы помогут вам локализировать проблему и знать, где ее воспроизвести, подробно ее изучить и правильно решить. И эти вопросы важно задавать, так как частенько случается, что баг ставят на один браузер, но по факту, функционал не работает нигде. И тогда, это не совсем проблема браузера 🙂
7. Когда случаются конкретные ошибки, как бы это очевидно не звучало — гуглите. Пример из реальной практики: в один прекрасный момент тестировщики заметили, что в браузерах Safari на iOS определенной версии текст в кнопках не выровнен по центру. Это было характерно только для браузеров Safari на iOS 9 версии и ниже, что было выяснено как путем самостоятельной проверки, так и общения с тестировщиками. Текст в этих кнопках выравнивался с помощью flex. Я зашла на browserstack.com, в эмулятор нужного окружения, и увидела, что на данном окружении, почему-то эффект не работает. Путем долгого поиска в интернете по разнообразнейшим запросам, был найден комментарий на stackoverflow, в котором было написано, что тег button, согласно философии Safari, не может быть flex-контейнером. Flex-элементом он может быть, но контейнером — нет. Почему? Ну, так решили, даже вроде логика какая-то была. Потом, конечно опомнились и в следующих версиях исправили, но мне-то надо, чтоб работало и в этой. Все, избавились от display: flex, выровняли по-другому, баг исправлен.
В процессе решения вопроса я использовала все, что описала выше — browserstack, caniuse (где искала возможные проблемы с флексами), также помогает MDN, https://developer.mozilla.org/ где частенько можно встретить описание ошибок в конкретных браузерах. Ну и также, мне помогло знание английского языка, которое позволило мне изучать много информации по моим гугловским запросам и высокая стрессоустойчивость в тот момент, когда я преодолевала все стадии — принятия, отрицания и так далее 🙂
Кроссбраузерность сайта — это не та тема, которую можно сесть, выучить — и все, вы ее знаете. Это такая вещь, которая постоянно меняется, исправляется, дополняется. Нужно всегда держать руку на пульсе развития технологий и эволюции браузеров. Не обязательно и, в целом, не нужно запоминать наизусть, где какие свойства отрабатывают некорректно. Потому что сегодня они работают некорректно, а завтра разработчики браузеров уже это исправили. Проверяйте работу в разных браузерах, знайте где искать информацию про особенности поведения технологий и держите руку на пульсе последних обновлений.
What are -moz- and -webkit-? [duplicate]
I am a beginner at CSS and when I was looking at some CSS code the other day, I found these lines. In the tutorials I used to learn CSS, I have never seen anything like these lines. What is the explanation for these lines? Or is there a source where I could learn to implement lines like these?
2 Answers 2
These are the vendor-prefixed properties offered by the relevant rendering engines ( -webkit for Chrome, Safari; -moz for Firefox, -o for Opera, -ms for Internet Explorer). Typically they’re used to implement new, or proprietary CSS features, prior to final clarification/definition by the W3.
This allows properties to be set specific to each individual browser/rendering engine in order for inconsistencies between implementations to be safely accounted for. The prefixes will, over time, be removed (at least in theory) as the unprefixed, the final version, of the property is implemented in that browser.
To that end it’s usually considered good practice to specify the vendor-prefixed version first and then the non-prefixed version, in order that the non-prefixed property will override the vendor-prefixed property-settings once it’s implemented; for example:
Specifically, to address the CSS in your question, the lines you quote:
Specify the column-count , column-gap and column-fill properties for Webkit browsers and Firefox.
What are -moz- and -webkit-?
CSS properties starting with -webkit- , -moz- , -ms- or -o- are called vendor prefixes.
Why do different browsers add different prefixes for the same effect?
A good explanation of vendor prefixes comes from Peter-Paul Koch of QuirksMode:
Originally, the point of vendor prefixes was to allow browser makers to start supporting experimental CSS declarations.
Let’s say a W3C working group is discussing a grid declaration (which, incidentally, wouldn’t be such a bad idea). Let’s furthermore say that some people create a draft specification, but others disagree with some of the details. As we know, this process may take ages.
Let’s furthermore say that Microsoft as an experiment decides to implement the proposed grid. At this point in time, Microsoft cannot be certain that the specification will not change. Therefore, instead of adding the grid to its CSS, it adds -ms-grid .
The vendor prefix kind of says "this is the Microsoft interpretation of an ongoing proposal." Thus, if the final definition of the grid is different, Microsoft can add a new CSS property grid without breaking pages that depend on -ms-grid.
UPDATE AS OF THE YEAR 2016
As this post 3 years old, it’s important to mention that now most vendors do understand that these prefixes are just creating unnecessary duplicate code and that the situation where you need to specify three different CSS rules to get one effect working in all browser is an unwanted one.
As mentioned in this glossary about Mozilla’s view on Vendor Prefix on May 3, 2016 ,
Browser vendors are now trying to get rid of vendor prefix for experimental features. They noticed that Web developers were using them on production Web sites, polluting the global space and making it more difficult for underdogs to perform well.
For example, just a few years ago, to set a rounded corner on a box you had to write:
But now that browsers have come to fully support this feature, you really only need the standardized version:
Webkit css что это
Webkit Browser Engine
Чтобы понять актуальность, а это прежде всего важно иметь практические знания о механизмах веб-браузера. Это компонент браузера, который отвечает за визуализацию контента, где по этой причине это также упоминается как механизм веб-рендеринга.
Проще говоря механизм рендеринга — это компонент, который отвечает за то, что видно в браузере, где берет данные из HTML или PHP, форматирует их в соответствии с CSS или XSL и передает их браузеру пользователя.
Не все веб-браузеры используют один и тот же механизм рендеринга. Internet Explorer использует движок Trident, продукты Mozilla, такие, как Firefox, используют Gecko, Opera использует движок Presto, а движок WebKit используется браузерами Safari и Chrome.
Из-за различных движков рендеринга в веб-браузере иногда возникают проблемы перекрестной совместимости для макета контента. Другими словами, это контент, который возможно был разработан для Internet Explorer, может не отображаться так, как задумал дизайнер в другом браузере, таком как Mozilla Firefox.
Webkit в синтаксисе CSS3
Таким образом термин «webkit» также является частью синтаксиса CSS, используемого для визуализации контента для браузеров Safari и Chrome. Из-за отсутствия кросс-совместимости, код webkit, возможно, должен быть включен в CSS, чтобы гарантировать, что он будет отображаться так, как задумано в Chrome и Safari.
Актуальность webkit связана с CSS3, где с модулями CSS нового поколения, которые предоставляют такие функции, как эффекты перехода, макеты с несколькими столбцами и анимация. Хотя все браузеры могут отображать старые спецификации CSS в значительной степени в одинаковой степени, это не относится к новым модулям CSS3.
Например в коде CSS3 расположенном ниже зеленого квадрата, он расширяется по горизонтали в течение 2 секунд, когда на него наведена мышь.
Чтобы тот же эффект перехода отображался в браузерах с использованием механизма WebKit, где код CSS будет следующим:
CSS — Префиксы браузеров
Веб-разработчик начинающий изучать теоретические основы CSS и использующий данные знания на практике может столкнуться с проблемами при рассмотрении реальных примеров. Это может вызвать у него непонимание происходящего и отбить дальнейшее желание изучать данную технологию.
Например, при рассмотрении стилей какого-нибудь сайта веб-разработчик может столкнуться со свойствами, содержащими впереди некоторые непонятные слова: -webkit- , -moz- , -ms- и др.
Что же это такое? На самом деле всё просто, эти непонятные слова являются префиксами следующих браузеров:
- -webkit- : браузеры Chrome, Safari, Opera;
- -moz- : браузер Mozilla Firefox;
- -ms- : браузер Internet Explorer.
Таким образом, если перед названием свойства стоит некоторый префикс, то это означает, что данное свойство реализовано и будет применяться исключительно в указанном браузере. Все остальные браузеры данное свойство будут игнорировать, т.к. для них данный префикс неизвестен.
Причины появления префиксов
Причин для появления префиксов было достаточно много:
- Для включения в браузер экспериментальных свойств CSS, которые стандартом ещё не утверждены. Таким образом, производители браузеров производят тестирование и вносят предложения перед утверждением свойств CSS в стандарте.
- Для решения проблем с кроссбраузерностью.
- Для создания собственных свойств, которые не входят в стандарт CSS, но возможно появятся в нём через некоторое время.
Когда экспериментальное свойство утверждено в стандарте и прошло тестирование в браузере, у него обычно убирается префикс.
Как использовать префиксы
Рассмотрим в качестве примере следующий код:
Данный код применяет свойства CSS, которые изменяют алгоритм расчёта ширины и высоты для всех элементов веб-страницы. Первое CSS свойство -webkit-box-sizing со значением border-box предназначено для браузеров, использующих движок webkit (Safari) или blink (Chrome, Opera, Яндекс.Браузер). Второе CSS свойство -moz-box-sizing со значением border-box предназначено для браузеров, использующих движок Gecko (Mozilla Firefox). Последнее CSS свойство предназначено для браузеров, в которых это свойство уже протестировано и внедрено в соответствии со стандартом.
При использовании префиксов для свойств CSS, необходимо помнить, что их следует располагать до свойства CSS без префикса. Почему это так важно? Это важно потому, что если когда-то в браузере будет реализовано оригинальное свойство (без префикса), то будет использоваться именно оно (т.к. оно располагается последним), а не его экспериментальная версия.
Например: применение свойства CSS ко всем элементам веб-страницы в браузере Google Chrome версии 40.
На рисунке выше видно, что оригинальное свойство box-sizing уже внедрено в этот браузер, и из-за того, что оно располагается последним, браузер использует именного его, а не вышеприведенное свойство -webkit-box-sizing .
Как проверить поддержку определенного свойства в браузере
Сайт, на котором можно проверить реализовано ли данное свойство или нет в конкретном браузере можно по ссылке приведённой ниже. Кроме этого на сайте показывается количество пользователей в процентах, которые пользуется этой версией браузера.
Например: проверим, как реализовано свойство transform в браузерах.
На сайте «CanIUse» браузеры отмечаются различными цветами, в зависимости от того в каком состоянии находится поддержка определённых свойств или тегов: