Статьи

Два новых предложения по решению кризиса префиксов поставщиков CSS3

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

  1. Поставщики реализуют экспериментальные свойства CSS3, используя собственный префикс, например -webkit-transform, -moz-transform, -ms-transform, -o-transform.
  2. Разработчики могут использовать технологии сегодня, не нарушая кросс-браузерную совместимость. Свойства могут быть перечислены с их префиксными и нефиксированными именами, чтобы гарантировать, что они работают везде.
  3. Как только свойство становится рекомендацией W3C, все поставщики браузеров могут предоставить стабильное свойство без префикса, например, transform.
  4. При желании разработчики могут удалить префиксные свойства из своих таблиц стилей. Однако в этом нет особой необходимости, если свойство без префикса определено последним и применяются правила каскадирования CSS.

Вот что происходит в реальном мире:

  1. Поставщики реализуют экспериментальные свойства CSS3, используя собственный префикс. В некоторых случаях поставщики продвигают их как «стандарт» HTML5, даже если они относятся к конкретному устройству или никогда не передаются в W3C.
  2. Некоторые разработчики используют проприетарное свойство от одного поставщика, например, только -webkit-transform. Это может быть из-за невежества, лени или потому, что они тестируют ограниченное количество устройств.
  3. Как только свойство становится рекомендацией W3C, все поставщики браузеров могут предоставить стабильное свойство без префикса, например, transform…
  4. но разработчики не хотят менять свои таблицы стилей. В некоторых браузерах сайт выглядит хорошо, а в других — хуже, даже если они поддерживают стандартную спецификацию W3C.
  5. Поставщики начинают беспокоиться и добавляют поддержку других префиксов в свой браузер, т. Е. Opera реализует префикс -webkit для некоторых свойств . Префиксный процесс нарушен, и, хотя еще слишком рано прогнозировать результат, большинство разработчиков считают его плохим ходом.

Мы подробно обсудили эти проблемы на SitePoint; нет простых решений . Однако на прошлой неделе члены W3C высказали два интересных предложения.

Вариант 1. Нефиксированные свойства поддерживаются с первого дня

Первое предложение поступило от Флориана Ривоала, представителя Opera в W3C:

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

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

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

Например, вы можете использовать следующий код преобразования в вашем CSS:


transform: rotate(30deg);

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

 
transform: rotate(30deg);
-webkit-transform: rotate(-30deg);

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

Тем не менее, что произойдет, если webkit изменил вращение на одобренное W3C направление по часовой стрелке? Разработчикам необходимо исправить свои таблицы стилей, удалив или переставив -webkit-transform: rotate(-30deg); свойство. К сожалению, не все используют одну и ту же версию движка webkit одновременно. Вы можете столкнуться с ситуацией, когда ваш сайт работает в Chrome, но не работает в Safari в течение нескольких месяцев.

Вариант 2: новый модификатор черновика

Второе предложение исходит от Франсуа Реми:

Давайте введем модификатор значения «! Vendor-draft». Я предлагаю использовать нефиксированные свойства с самого начала, но с токеном, объясняющим, для какой версии свойства мы создали наш CSS:
border-radius: 3px !webkit-draft;

Любой браузер, который не является webkit, но реализовал border-radius способом, совместимым с «черновиком webkit», может поддерживать декларацию. Это отличается от префиксов поставщиков: другие браузеры не олицетворяют веб-набор, они просто признают, что поддерживают одно конкретное свойство в соответствии с тем, как его определяет черновик веб-набора. Браузеры, которые не совместимы с этим проектом, будут просто игнорировать объявление. Браузерам, которые изменяют свою реализацию свойства, рекомендуется повторять свой флаг «! Vendor-draft» (при необходимости, используя номер версии).

Это решает проблему, изменяя значение свойства, а не его имя (аналогично модификатору !important Опять же, можно использовать следующий код преобразования:

 
transform: rotate(30deg);

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

 
transform: rotate(30deg);
transform: rotate(-30deg) !webkit-draft;

Если браузер впоследствии поддерживает спецификацию W3C, второе свойство будет игнорироваться.

Также было бы возможно реализовать черновую версию, например

 
transform: rotate(30deg);
transform: rotate(-30degrees) !webkit-draft;
transform: rotate(-30deg) !webkit-draft-2;

Это гибкое решение, которое, наконец, решает проблему свойств, эволюционирующих с течением времени.

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

Мне нравятся оба решения. С точки зрения кодирования, модификаторы проекта вендора кажутся наиболее логичным вариантом, но я сомневаюсь, что его можно будет рассмотреть, пока вендоры не «завершат» CSS3 и не начнут работу над CSS4.

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

У вас есть предпочтения для любого из этих вариантов? Или уже слишком поздно предотвращать катастрофу приставки поставщика?