Префиксы поставщиков CSS3 и надвигающийся апокалипсис подробно обсуждались в SitePoint с начала 2012 года:
- Предстоящая катастрофа с префиксом поставщика CSS
- 7 решений кризиса префиксов поставщиков CSS3
- Наступает судный день: Opera реализует префикс CSS3 Webkit
- Два новых предложения по решению кризиса префиксов поставщиков CSS3
Проблемы широко поняты неправильно — вот почему мы находимся в этом беспорядке. Надеемся, что эта статья разрушит несколько мифов о кризисе префиксов поставщиков …
1. W3C изобретает стандарты …
Не имеет значения, изобретаете ли вы свойство CSS3, протокол беспроводной сети, электрическую розетку или кадровую политику компании: ничто не станет стандартом, пока не будет реализовано .
Существует широко распространенное заблуждение, что W3C состоит из повелителей HTML5, которые устанавливают правила, которым должны следовать все. W3C не является и никогда не был новатором веб-технологий. Поставщики браузеров несут ответственность за изобретение новых свойств CSS3; они становятся стандартом только тогда, когда:
- собственность передана в W3C (у всех продавцов есть представители, которые принадлежат организации)
- Общепринято, что это хороший путь вперед
- по крайней мере, один другой поставщик реализует ту же функцию.
2.… для поставщиков, чтобы следовать
Если вы решили создать браузер с нуля, рекомендуем вам следовать спецификациям W3C. В этом нет ничего обязательного, но документы определяют, как сегодня работают другие браузеры. Есть даже документы, которые описывают, как браузеры должны отображать недопустимый HTML.
Спецификации — это запись того, что было сделано, а НЕ того, что должны делать поставщики. Если у вас есть работающий браузер, вы можете добавить любую понравившуюся вам функцию и отправить ее на рассмотрение в W3C.
3. Процесс утверждения W3C занимает слишком много времени
Это занимает столько времени, сколько нужно.
Продавцы обычно стремятся получить одобрение W3C, иначе их усилия были напрасны. Мы все работаем над программными продуктами и знаем, насколько расстраивающими могут быть разногласия, поэтому подумайте, насколько сложно пяти основным конкурентам оценить и одобрить идеи друг друга.
Однако помните, что окончательная «Рекомендация W3C» означает, что функция была реализована в двух или более браузерах на одном уровне, и никто не высказал разумных возражений. Возможно, имущество можно было использовать за несколько лет до этого момента.
4. Свойства CSS3 не должны быть доступны, пока они не станут стандартом
Некоторые разработчики высказали мнение, что свойства должны быть отключены или присутствовать только в ночных выпусках браузера, пока они не будут стандартизированы. Поскольку свойство должно быть реализовано до того, как оно станет стандартом, как вы можете дождаться появления стандарта перед реализацией свойства?
Смысл префиксов поставщиков заключается в оценке реализации функций. Если бы эта функция была каким-то образом скрыта, ей бы уделялось мало внимания, оценка заняла бы больше времени, и она не стала бы Рекомендацией W3C при вашей жизни.
Вы можете подождать, пока недвижимость станет стандартом, но…
- Вы пропустите некоторые замечательные функции.
border-radiusуже некоторое время был доступен во всех браузерах без префиксов, однако уровень 3 модуля CSS «Фоны и границы» еще не достиг финальной стадии рекомендации W3C. Вам лучше вернуться к нарезке изображений. - Как только свойство становится стандартом, нет гарантии, что оно будет доступно везде. Большинство браузеров еще не реализовали все функции CSS2.1 — и у них было 13 лет, чтобы сделать это.
5. Префиксы поставщиков == Бета-версия
Существует распространенное мнение о том, что префиксы поставщиков сопоставимы с бета-версиями программного обеспечения. Это приводит к выводу, что префиксные свойства не рекомендуются для производственного использования. Это не правильно.
Бета-версия программного обеспечения выпущена для целей тестирования, чтобы определить, работают ли функции как задумано. Префиксы поставщика используются для оценки реализации новой функции. Разница невелика, но важно понимать, что:
- Хотя свойство с префиксом поставщика является предварительно стандартным, оно было разработано, задокументировано, передано, закодировано и протестировано к моменту его появления в вашем браузере. Нет никакой гарантии, что оно останется прежним или будет реализовано другими поставщиками, но редко когда свойство радикально изменяется или исчезает. В худшем случае это свойство доступно только в одном браузере.
- Свойство поставщика с префиксом прошло бета-тестирование, и сама функция не должна вызывать проблем. Если использование свойства вызвало ужасный сбой браузера, это было бы проблемой с программным обеспечением, а не со спецификацией свойства.
- Единственная причина, по которой поставщики не используют имя свойства без префикса, состоит в том, чтобы избежать конфликтов реализации на ранних этапах соглашения с поставщиками. Это может измениться, если предложение Флориана Ривоала будет принято .
6. Префиксы не нужны
Исключение префиксов не решает проблему с префиксами поставщиков. Имущественные различия редки, но они встречаются. В этих обстоятельствах свойство станет непригодным для использования, если вы не сможете различить две реализации браузера.
Возможно, есть лучшие варианты, но префиксы решают конкретную проблему.
7. У JavaScript нет проблемы с префиксом
JavaScript, или ECMAScript, является международным стандартом. Язык почти не изменился с момента его создания, и, хотя грядут более радикальные изменения, различные механизмы JavaScript идентичны. Даже известные ошибки копируются.
Тем не менее, JavaScript не проблема. Когда разработчики жалуются на кодирование на стороне клиента, это, как правило, вызывает API-интерфейс браузера. Эти API вызываются кодом JavaScript, но они являются предопределенными объектами в браузере — они не являются частью самого языка.
Имейте в виду, что API-интерфейсы JavaScript с префиксом поставщика, такие как полноэкранный , уже существуют, и в будущем появятся и другие. Тем не менее, это не проблема, так как вы можете обнаружить объекты и разветвляться соответственно. Это невозможно в CSS.
8. SASS / SCSS / LESS / Другой инструмент CSS может исправить все
Существует несколько скриптов / языков макросов CSS, которые предварительно компилируют правила в действительные таблицы стилей. Большинство обрабатывает префиксы; Вы определяете одно стандартное свойство, и соответствующие префиксы поставщиков добавляются автоматически. Это отличное решение, но:
- Не каждый может установить прекомпиляторы CSS, так как вам требуются определенные серверные языки или платформы.
- Прекомпилятор CSS работает так же хорошо, как и его последнее обновление. Префиксы поставщика меняются всякий раз, когда выпускается новый браузер — программное обеспечение должно идти в ногу, или оно бесполезно.
- Это еще один синтаксис для изучения; многие разработчики довольны кодированием необработанного CSS.
- Прекомпиляторы CSS представляют свой собственный набор проблем. Любая система, которая генерирует код, может ошибиться и усложнить отладку.
Если вы довольны использованием инструментария CSS, это нормально. Но они не для всех и скрывают только проблему префикса поставщика. Они не решают это.
9. Webkit ведет пакет …
Webkit — одна из наиболее активных групп разработки, которая первой внедрила некоторые из блестящих эффектов CSS3. Но они не всегда идут впереди:
- CSS3 calc () функция только появилась в Chrome 19, но доступна в Firefox, была в IE9 более года без префикса.
- Реализация градиента фона Webkit была ужасной. Члены W3C в конечном итоге остановились на более чистом предложении Mozilla.
- Webkit не поддерживает круглые и
background-repeatсвойстваbackground-repeat; они были в IE9 и Opera в течение многих месяцев. - У SVK-парсера Webkit меньше возможностей, и он часто работает медленнее, чем другие движки.
Другие поставщики вносят свою долю. Помните, что webkit используется в Safari и Chrome; Apple и Google — крупнейшие в мире IT и веб-компании — регулярно публикуют новые разработки. Основная причина, по которой мы находимся в этом беспорядке, заключается в том, что некоторые разработчики полагали, что единственным важным движком является webkit
10.… так что один движок рендеринга решит все
Единый движок рендеринга сделает жизнь веб-разработчиков намного проще. Многие считают, что некая законная монополия на браузер является хорошей идеей. Если вы согласны, помните, что ваше желание было исполнено десять лет назад. Был один доминирующий браузер; Кодирование было простым, и не было необходимости беспокоиться о стандартах W3C. IE6 был стандартом. Должны ли мы игнорировать этот исторический урок?
Единый браузерный движок убивает конкуренцию и эволюцию. В предложении не отражено несколько ключевых вопросов:
- Невозможно обеспечить соблюдение закона или практически на глобальном уровне.
- Поставщики браузеров являются конкурентами. Два разработчика не согласятся по поводу одного предложения по функциям; будут ли пять конкурирующих компаний работать в гармонии на одной кодовой базе? Microsoft, Mozilla и Opera отбросят пару десятилетий работы по внедрению Webkit?
- Продавцы имеют разные требования и графики. Предположим, что Apple требуется новое свойство для iPhone. Будут ли они ждать одобрения от Google, Microsoft, Mozilla и Opera? Или они раскрутят двигатель и воплотят его в жизнь? Прежде чем вы это знали, у нас снова будет пять отдельных двигателей.
- Многие предполагают, что поставщики все еще могут конкурировать за «функции». Тем не менее, браузер является двигателем. Производители активно отбирают лишние материалы, чтобы создавать более быстрые и привлекательные приложения. За что будут конкурировать поставщики всех этих функций?
- Один двигатель не означает одну версию. Даже сегодня, благодаря более быстрому графику выпуска Chrome, он имеет более свежую версию webkit, чем Safari.
Несмотря на наличие пяти основных приложений, разработка стала проще, чем когда-либо. Рынок браузеров снова активен, процветает и волнует. Я надеюсь, что мы никогда не потеряем это.
11. Продавцы виноваты
Есть ли у поставщиков обязанность разработчиков? Или их главная забота должна касаться миллионов конечных пользователей?
Были случаи, когда поставщики продвигали свойства с префиксами в качестве стандарта HTML5, но они специально не усложняли нашу жизнь. Префиксы решают больше вопросов, чем поднимают. Единственная причина, по которой у нас сейчас кризис, заключается в том, что подмножество веб-разработчиков не смогли использовать свойства CSS3 -webkit, -moz, -ms, -o и без префиксов. Пришло время прекратить ныть и исправить проблемы в нашем коде.
12. Префиксы были глупой идеей
Префиксы поставщиков не идеальны. Это решение, которое не позволяет двум поставщикам по-разному реализовывать одно и то же свойство и делает его непригодным для использования. Возможно, они были немного наивны, но легко заметить недостатки с точки зрения прошлого.
Лучшие решения неизбежно появятся, но до тех пор мы застряли с префиксами, и мы можем использовать их соответствующим образом.