Перевод статьи «Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies» из журнала A List Apart, автор — Лиа Веру, переводчик — SelenIT

Минздрав Интернета предупреждает: каждый раз, когда вы называете проприетарную фичу словом «CSS3», в мире умирает котенок. Любая -webkit-фича, не входящая в спецификации (хотя бы в редакторский черновик) — никакой не CSS3. Да, их часто выдают за него, но они вообще даже не часть CSS. Различать эти вещи — не просто педантство. Это важно, потому что эта путаница мотивирует некоторых производителей браузеров (с таким, кхе-кхе, яблочком на лого…) идти в обход процесса стандартизации, реализовывать в WebKit свою отсебятину, а потом подавать ее вебмастерам как невиданную вкусность. Новые блестящие игрушки ослепляют нас, и мы сами начинаем превозносить их, усиливая эхо рекламного шума.

Гоняясь за новыми побрякушками, мы часто забываем, сколько людей боролись всё прошлое десятилетие за то, чтобы мы могли писать код без ветвлений и хаков и рассчитывать, что он заработает везде. Если вы «в теме» дольше пары-тройки лет, вы наверняка помните, что так было не всегда. Причина удобства нынешней веб-разработки — веб-стандарты, итог тяжко давшейся нам победы в браузерных войнах.

Удивительно, но веб-стандарты существовали и в эпоху браузерных войн. W3C основан в 1994 году. Однако вебмастерам было не до них, всем хотелось «потрогать» проприетарные расширения. В итоге браузеры тоже особо не заморачивались веб-стандартами. Ничего не напоминает? Сегодняшние проприетарные фичи ничуть не лучше ActiveX и IE-шных фильтров. Разница лишь в лучшем пиаре, и то потому, что мы не еще столкнулись с последствиями. Хоть верьте, хоть нет, но тогдашние фичи тоже принимались с восторгом в те дни.

Да, иногда у браузеров получается что-то стоящее, что со временем становится стандартом (XMLHttpRequest, Drag and Drop API, contentEditable, веб-шрифты — так, навскидку). Но ничто не препятствует им вводить новинки, соблюдая стандартную процедуру. Ничто не мешает им, придумав что-то клёвое, предложить это соответствующей рабочей группе W3C, заодно улучшив его благодаря коллективной обратной связи, прежде чем пускать в реализацию. Поступил бы так Microsoft с Drag & Drop API — не был бы он таким геморроем в использовании.

Проприетарные фичи, не прошедшие процедуры стандартизации, обычно страдают конструктивными дефектами, даже когда идея в целом хорошая. Например, CSS-градиенты — блестящая задумка, но -webkit-gradient() был многобуквенным ужасом, так и подбивающим ошибиться в нем. Веб-шрифты — великолепная идея, но вот обязательность наличия .eot-файла — нет. Процедура стандартизации не только способствует переносимости, она еще и помогает лучше спроектировать каждую фичу, благодаря большему разнообразию мнений.

Так что же это за позорные фичи? По части CSS наиболее популярны:

• -webkit-box-reflect
• -webkit-text-stroke
• -webkit-mask
• -webkit-background-clip: text;
• -webkit-text-size-adjust
• -webkit-tap-highlight-color
• -webkit-text-fill-color

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

«Как узнать, проприетарна ли та или иная фича?»

Способ, который помогает мне — поискать в Гугле название фичи (в кавычках), добавив к поисковому запросу site:w3.org, чтобы искать только в пределах домена w3.org. Два примера:

• “box-shadow” site:w3.org
• “box-reflect” site:w3.org

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

«Чем я могу помочь?»

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

• Убедитесь, что используете эти фичи в соответствии с принципом прогрессивного улучшения, что конструкция может прекрасно работать и без них.
• Не рекламируйте их, или, если вы вынуждены это делать, не забывайте объяснять, что эти фичи — проприетарные, и что это значит.
• Если вам приходится использовать их в своем коде, добавьте комментарий об этом. Хватит чего-нибудь вроде /* Warning: Нестандартно! */. Многие начинающие фронтенд-кодеры учатся на примерах исходников реальных сайтов. Даже если вы не читаете лекций и не пишете туториалов, вы можете косвенно учить людей каждой строчкой своего кода.
• Отзовите статьи, лекции, примеры и т.п., пропагандирующие эти фичи без каких-либо предупреждений, или где используется только один префикс одного производителя (что тоже весьма серьезная проблема). А еще лучше — сами исправьте их, если возможно.

«Как я могу помочь стандартизации фичи?»

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

Шаг 1. Изучите стандартные альтернативы

Прежде всего, изучите стандартные альтернативы. Они могут хуже (или вообще никак) поддерживаться браузерами, но вы хотя бы будете знать, за что бороться. Вы даже можете добавить их как «фоллбэк», не загораживая дорогу другим производителям, если вдруг они эту фичу уже реализуют.

Вы можете даже помочь ускорить реализацию, сообщив о соотв. баге в браузерах, которые ее не поддерживают. Не забудьте сначала поискать среди существующих багов. Если баг уже числится в списке, вы всё еще можете подчеркнуть его важность для вас, написав комментарий (будьте вежливы!). Браузеры учитывают запросы вебмастеров, устанавливая приоритеты для фич — что из них реализовать раньше. Покажите им, что та или иная фича для вас значима.

Шаг 2. Проверьте, не была ли эта фича уже кем-то предложена

W3C обсуждает, какие фичи добавлять и как «отполировать» их до совершенства, в своих списках рассылки. У каждой рабочей группы (WG, сокр. от «Working Group») есть свой, иногда даже несколько, чтобы рабочие группы могли сообща разрабатывать фичи, затрагивающие несколько технологий сразу. Например, CSS WG пользуется списком www-style, а SVG WG — списком www-svg. Однако для фич, затрагивающих как CSS, так и SVG, есть список public-fx.

Прежде чем писать в любую из этих рассылок, пожалуйста, поищите прошлые обсуждения вопроса. Каждая минута, которую тратит член рабочей группы, отвечая на дубликаты предложений — это еще одна зря потерянная минута для разработки веб-стандартов. Для поиска по архивам вы снова можете воспользоваться мощью Гугла. Наберите ключевые слова как обычно и просто добавьте в конец запроса site:lists.w3.org.

Если вы видите, что фичу уже предлагали, но обсуждение застопорилось без какого-либо результата, вы можете ответить (один раз!), чтобы снова поднять его. Пожалуйста, постарайтесь не выказывать в переписке своего нетерпения или раздражения. Читайте обсуждение дальше, обдумывая, что бы такого добавить, чтобы оно не оказалось уже расписано другими.

Шаг 3. Предложите фичу

Постарайтесь приложить как можно больше относящихся к делу данных.

Вот некоторые типы сведений, которые вы можете включить:

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

Также, решите, для какой спецификации она подойдет. Список спецификаций CSS можно найти здесь. Затем добавьте в начало названия вашей темы ID этой спецификации в квадратных скобках. Например, если тема относится к модулю величин и единиц, добавьте в начало названия «[css3-values]» (ID каждой спецификации можно найти в ее URL). Это облегчит поиск вашей темы редакторам, и такие метки помогают каждому следить за разработкой интересующей его спеки.

Еще надо иметь в виду, что новые фичи не добавляются в спецификации, которые достигли статуса кандидата в рекомендации (или вот-вот его достигнут). Конечно же, это относится и к последующим стадиям, напр. предложенной рекомендации и рекомендации. Например, если у вас предложение ввести новый селектор, адресуйте его не модулю селекторов 3-го уровня (ID: css3-selectors), которые уже имеют статус рекомендации, а селекторам 4-го уровня.

Если хотите узнать больше о том, как работает процесс стандартизации, прочитайте замечательный цикл статей fantasai «Внутри рабочей группы CSS».

«Это всё так сложно и скучно!»

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

Огромное спасибо Дэвиду Стори, Сильвену Галино и Эрику Мейеру за их отклик.

Translated with the permission of A List Apart Magazine and the author[s].

P.S. Это тоже может быть интересно:

• Тёмная сторона CSS: выходим за рамки и взрываем звезды с border-image и градиентами
• «Запашки» кода React-компонентов
• CSS-выражения от контейнера для дизайнеров