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, на которые мы полагаемся сегодня, не будут работать завтра.