7 решений для преодоления кризиса с вендорными префиксами



Крейг Баклер

Оригинал: sitepoint.com/css3-vendor-prefix-crisis-solutions

Перевод: Влад Мержевич

Как мы уже сообщали, Mozilla, Microsoft и Opera недовольны сайтами, которые ориентированы только на свойства с -webkit. Это заставляет их браузер выглядеть плохо даже в случае, когда он реализует идентичные или лучшие технологии. Чтобы решить эту проблему, они предлагают включить поддержку префикса -webkit в не Webkit-браузеры.

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

1. Ничего не менять

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

Плюсы

  • Браузеры продолжают внедрять свои префиксы, которые вы можете свободно использовать или игнорировать.
  • Не надо учиться или проверять что-то новое.
  • Большинство веб-разработчиков считают что всё в порядке и это решение их обрадует.

Минусы

  • Мы оставляем одно стандартное свойство и четыре свойства с префиксами. Стили увеличиваются больше необходимого и их сложнее проверять.
  • Ленивые или менее опытные разработчики продолжают ориентироваться только на браузеры Webkit.
  • Доля рынка Chrome и Safari может дорасти до точки, которая делает другие браузеры излишними. Мы возвращаемся к временам одного браузерного движка и на этом новации останавливаются. Возвращаются те тёмные дни, когда доминировал IE6.
  • Microsoft, Mozilla и Опера считают, что это реальная проблема: ничего не делать это не вариант.

2. Не-Webkit браузеры поддерживают префикс webkit

Предположим, IE, Firefox и Опера поддерживают свойства с префиксом webkit.

Microsoft уже внедрила -webkit-text-size-adjust в мобильную версию IE. Хотя это нестандартное свойство для Safari (где нет text-size-adjust), она послушалась сообщества и добавила поддержку. Это вряд ли произойдет снова, если Mozilla или Опера начнут добавлять свойства Webkit в свой движок.

Плюсы

  • Это быстрое и грязное решение, которое позволяет не-Webkit браузерам отображать сайты подобно Chrome или Safari.
  • Разработчикам нет необходимости обновлять свои сайты.
  • -webkit станет доминирующим префиксом, использование -moz, -ms или -o станет ненужным и это приведёт к уменьшению размера файла CSS.
  • Если Webkit сохранится, то Google и Apple станут очень мощными. Если другой поставщик не согласен с реализацией, они могут просто сломать его или предоставить альтернативу. Разработчики не смогут использовать свойство в любом браузере.

Минусы

  • Есть ощущение, что-то не так: один браузер не нужно маскировать под другой.
  • Поощряет небрежную практику разработки.
  • Различные реализации в браузерах сделают некоторые свойства непригодными для использования.
  • Если разработчики оставят свойства Webkit, которых нет в других браузерах, большинство пользователей перейдут на Chrome и Safari. Другие поставщики станут не нужны.

3. Все браузеры используют префикс -beta

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

Плюсы

  • Понадобится только один префикс для освоения и применения.
  • Уменьшится размер стилевого файла.
  • Свойство явно экспериментальное и разработчики будут более осторожны в его использовании.

Минусы

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

4. Экспериментальные свойства появляются только в бета-версии браузеров

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

Плюсы

  • Для разработчиков становится невозможным использовать код с префиксом или ориентироваться на конкретные браузеры при создании сайтов.
  • Только Webkit-сайты будут соответствующим образом наказаны.
  • Мы все работаем с конечными стандартами, а не с будущими.

Минусы

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

5. Префиксы отбрасываются после окончательной реализации

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

Плюсы

  • Решение логично.
  • Удаляется неиспользуемый код. Объём библиотек снижается и браузеры становятся экономичнее и быстрее.
  • Это поощряет хорошую практику разработки и наказывает плохую.

Минусы

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

6. Процесс утверждения W3C становится быстрее

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

Плюсы

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

Минусы

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

7. Больше евангелизма и образования в сообществе разработчиков

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

Плюсы

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

Минусы

  • Никто не гарантирует, что евангелисты и разработчики не изменят свою позицию.
  • Не слишком ли поздно? Передовые практические методы опубликованы, но игнорируются.
  • Нет определённого центрального репозитория.
  • Всегда будут новые, невежественные и небрежные разработчики. Никто не может сразу стать экспертом.

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

В конечном счете, разработчики сами вызвали эту проблему: до нас её не было. Не возникнет вопросов, если мы станем избегать свойств с префиксами или использовать кроссбраузерную альтернативу. Если этого не сделать, есть риск, что свойства CSS3, на которые мы полагаемся сегодня, не будут работать завтра.

Не выкладывайте свой код напрямую в комментариях, он отображается некорректно. Воспользуйтесь сервисом cssdeck.com или jsfiddle.net, сохраните код и в комментариях дайте на него ссылку. Так и результат сразу увидят.