От переводчика: В продолжении темы проприетарности (переводы статей раз и два), Lea Verou написала свою статью на A list apart, в которой она дает советы для веб-разработчиков. На перевод сподвиг заголовок статьи :)
Официальное заявление: каждый раз, когда вы причисляете проприетарную фичу к CSS3, умирает котенок. Любая -webkit- фича, которая не присутствует в спецификациях (хотя бы в черновиках) не относится к CSS3. Да, некоторые фичи выдают за CSS3, но они вовсе не являются частью CSS3. И это не придирки. Это очень важный момент, так как такое положение вещей поощряет определенные компании (*кхе* Apple *кхе*) игнорировать процесс стандартизации, реализуя то, что они придумали, в WebKit, и популяризируя это среди разработчиков, как лучшее изобретение после колеса. Новые блестящие игрушки ослепляют нас и мы тоже начинаем их раскручивать, внося свой вклад в повсеместное использование.
В нашем стремлении использовать новые побрякушки, мы часто забываем как много людей боролось в прошедшее десятилетие, чтобы позволить нам писать код без ветвлений и хаков, и ожидать что это будет работать везде одинаково. Если вы в веб разработке больше чем пару лет, вы определенно должны помнить, что так было не всегда. Главная причина тому, что есть сейчас — веб стандарты, тяжелая победа в Браузерной войне.
Возможно вы будете удивлены, но веб стандарты существовали во время Браузерной войны. W3C был основан в 1994 году. Тем не менее, тогда разработчикам браузеров было плевать на стандарты, и они внедряли нововведения по своему желанию. В результате, браузеры имели мало общего с веб стандартами. Это ничего вам не напоминает? Сегодняшние проприетарные фичи, ничем не лучше того же ActiveX и фильтров IE (прим. свойство filter в Internet Explorer). Вся лишь разница, что у сегодняшних пиар получше, но это все пока мы не столкнулись с последствиями. Верите или нет, но фичи IE6, тоже когда то были восприняты с большим воодушевлением.
Да, иногда браузеры предлагают хорошие вещи, которые со временем стандартизируются (XMLHttpRequest, Drag & Drop API, contentEditable, Web fonts лишь часть из них). Тем не менее, ничего не мешает делать инновации и следовать процессу стандартизации. Как не мешает им прийти с чем-то крутым в соответствующую рабочую группу W3C, внести предложение и усовершенствовать это путем коллективного обсуждения, прежде чем сломя голову кидаться внедрять это. Если бы Microsoft сделало так для Drag & Drop API, то сегодня не нужен был бы бубен, для того чтобы использовать это API.
Проприетарные фичи, которые не прошли процесс стандартизации обычно имею плохой дизайн, даже когда идея была хорошей. Например, CSS градиенты были хорошей идеей, но -webkit-gradient() был избыточным и имел ошибки. Web fonts были хорошей идеей, но использовать для этого .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
Не каждое свойство с префиксом проприетарно. Часть из них всего лишь экспериментальная реализация фичи включенной в стандарты. Это приводит нас к следующему вопросу.
Как я могу определить, что фича является проприетарной?
У меня такой способ: в строке поиска Google пишу название фичи (в кавычках) и добавляю в конце site:w3.org, чтобы поиск был только в рамках домена w3.org. Пара примеров:
Если посмотреть результаты, то для первой фичи первая же вариант это ссылка на спецификацию W3C. Для второй результаты ссылаются только на почтовую рассылке, а это признак того, что для нее еще нет спецификации.
Что я могу?
Для начала, совсем не использовать проприетарные фичи. Не используйте их, не популяризируйте, и определенно, не полагайтесь на них. Но я понимаю, что проще сказать, чем сделать. Если вы не можете полностью отказаться от проприетарных свойств, то вот несколько советов. Я уверена, вы можете им следовать:
- Убедитесь что использование фичи отвечает принципам progressive enhancement (прим. не нашел аналога на русском; вариант перевода — постепенное улучшение), так чтобы дизайн мог работать и без нее.
- Не рассказываете про такие фичи, а если все же рассказываете, то обязательно сообщайте, что они проприетарные и что это означает.
- Если вы используете такую фичу в вашем коде, добавляйте комментарий, что-то вроде /* Осторожно: нестандартное свойство */. Многие люди учатся изучая существующие сайты. Даже если вы не читаете лекций и не пишете обучающих статей, вы все равно косвенно учите остальных каждой строчкой своего кода.
- Критикуйте статьи, доклады, демонстрации и пр., которые популяризируют такие фичи без предупреждений, или те, которые используют только один вендорный префикс (что так же очень серьезная проблема). Или, что лучше, исправьте это, если возможно.
Как я могу помочь стандартизировать фичу?
Если вы обнаруживаете, что используете проприетарную фичу слишком часто, примите участие в ее стандартизации. Я могу порекомендовать несколько шагов, которые, впрочем, могут быть применены к любым предложениям в целом:
- Изучите альтернативы, которые предлагают стандарты
Прежде всего, изучите альтернативы, которые есть в спецификациях. Они могут быть плохими или без должной браузерной поддержки, но вы по крайней мере будете знать чего ожидать в будущем. Так же можно добавить поддержку фичи на будущее, тем самым вы не оставите за бортом другие браузеры, когда в них появится соответствующая поддержка.
Вы так же можете ускорить внедрение фичи, создав тикет в трекере браузера, которые ее не поддерживает, а если тикет уже заведен, оставьте комментарий, покажите как это важно для вас. Разработчики браузеров учитывают это определяя приоритет для новых фич.
- Проверьте, возможно фича уже обсуждается
W3C обсуждает фичи и доводит их до совершенства используя почтовые рассылки. У каждой рабочей группы своя рассылка. Иногда группы объединяются, когда разрабатывается фича, которая затрагивает несколько технологий. Например, рабочая группа CSS используется рассылку www-style, а рабочая группа SVG использует рассылку www-svg. Тем не менее для фич, которые затрагивают и CSS и SVG используется рассылка public-fx.
Если вы нашли обсуждение фичи, но это обсуждение ни к чему не пришло, можете попробовать возобновить обсуждение. Но прежде изучите всю переписку и убедитесь, что ваши доводы еще не приводились в дискуссии и вам есть что добавить.
- Предложите фичу
Постарайтесь включить как можно больше сопутствующей информации в свое предложение. Вы можете указать:
- Ситуации когда фича может использоваться. Это очень важно. Никто не заинтересован в стандартизации новых возможностей, которые используются в редких случаях. Покажите, что предлагаемая фича решает и как может использоваться.
- Ваш опыт использования. Что вам нравится, что бы вы хотели поменять, как это может быть обобщено для более широкого круга задач и т.п.
Так же следует помнить, что новые фичи не добавляются в спецификации, которые уже достигли статуса Candidate Recommendation (кандидат в рекомендации), и конечно же это так же справедливо для всех последующих статусов, то есть Proposed Recommendation (предложенная рекомендация) и Recommendation (по сути утвержденная спецификация). Например, если вы предлагаете добавить новый селектор, не предлагайте внести его в модуль Selectors Level 3, который имеет статус рекомендации. Однако вы можете предложить внести его в модуль Selectors Level 4.
Если вы хотите побольше узнать о процессе стандартизации, почитайте замечательную серию статей Inside the CSS WG за авторством fantasai.
Это все сложно и скучно!
То же можно сказать и про любую экологическую проблему. Да, это определенно сложнее чем просто использовать проприетарные фичи, решая задачи сегодняшнего дня. Но в долгосрочной перспективе, в интересах каждого этого не делать.
Translated with the permission of A List Apart Magazine and the author[s].
