От переводчика: Продолжая тему имущественных прав (переводы статей один раз И два ), Леа Веру написала свою статью о Список отдельно , в котором она дает советы веб-разработчикам.Теги: #CSS #w3c #Рабочая группа CSS #стандарты #процедура стандартизации #браузеры #WebKit #IE #IT-стандартыНазвание статьи побудило меня ее перевести :) Официальное заявление: Каждый раз, когда вы классифицируете проприетарную функцию как CSS3, умирает котенок.
Любая функция -webkit-, отсутствующая в спецификациях (по крайней мере, в черновиках), не является CSS3. .
Да, некоторые функции выдаются за CSS3, но они вообще не являются частью CSS3. И это не придирки .
Это очень важный момент, так как такое положение дел поощряет определенные компании (*кхе* Яблоко *кхе*) игнорируют процесс стандартизации, реализуя то, что они придумали, в WebKit и популяризируя его среди разработчиков как лучшее изобретение со времен колеса.
Новые блестящие игрушки ослепляют нас, и мы тоже начинаем их приобретать.
продвигать , способствуя широкому использованию.
В нашем стремлении освоить новые гаджеты мы часто забываем, сколько людей боролись за последнее десятилетие за то, чтобы мы могли писать код без ветвей и хаков, и ожидаем, что он будет работать везде одинаково.
Если вы занимаетесь веб-разработкой более пары лет, вам обязательно следует помнить, что так было не всегда.
Основная причина того, что мы имеем сейчас, — это веб-стандарты, тяжелая победа в Браузерная война .
Возможно, вы удивитесь, но веб-стандарты существовали во время войны браузеров .
W3C была основана в 1994 году.
.
Однако тогда разработчики браузеров не заботились о стандартах и вводили инновации по своему усмотрению.
В результате браузеры имели мало общего с веб-стандартами.
Вам это ничего не напоминает? Сегодняшние фирменные функции не лучше, чем фильтры ActiveX и IE. (пример: свойство фильтра в Internet Explorer) .
Разница лишь в том, что сегодняшний пиар лучше, но это все до того, как мы столкнемся с последствиями.
Хочешь верь, хочешь нет, но возможности IE6 тоже когда-то были встречены с большим энтузиазмом .
Да, иногда браузеры предлагают хорошие вещи, которые со временем стандартизируются (XMLHttpRequest, Drag & Drop API, contentEditable, веб-шрифты — это лишь некоторые из них).
Однако ничто не мешает вам внедрять инновации и следовать процессу стандартизации.
Им не помешает придумать что-нибудь крутое для соответствующей рабочей группы W3C, внести предложение и улучшить его посредством коллективного обсуждения, прежде чем сломя голову броситься его реализовывать.
Если бы Microsoft сделала это для API Drag & Drop, то сегодня вам не нужен был бы алмаз для использования этого API. Собственные функции, не прошедшие процесс стандартизации, обычно оказываются плохо спроектированными, даже если идея была хорошей.
Например, градиенты CSS были хорошей идеей, но -webkit-gradient() был избыточным и содержал ошибки.
Веб-шрифты были хорошей идеей, но использовать для этого файлы .
eot — нет. Процесс стандартизации не только помогает обеспечить совместимость, но и помогает улучшить конструкцию каждой функции из-за большого количества разнообразных мнений.
Вот несколько печально известных свойств CSS, которые также довольно популярны:
Не каждое имущество с приставкой является собственностью.
- -webkit-box-reflect
- -webkit-text-stroke
- -webkit-маска
- -webkit-background-clip: текст;
- -webkit-text-size-adjust
- -webkit-tap-highlight-color
- -webkit-text-fill-color
Некоторые из них представляют собой всего лишь экспериментальные реализации функций, включенных в стандарты.
Это подводит нас к следующему вопросу.
Как я могу определить, является ли функция собственностью?
У меня такой метод: в строке поиска Google пишу название функции (в кавычках) и добавляю в конце site:w3.org, чтобы поиск был только внутри домена w3.org. Несколько примеров: Если вы посмотрите на результаты, то для первой функции первый вариант — это ссылка на спецификацию W3C. Во втором случае результаты упоминаются только в списке рассылки, что является признаком того, что для него еще нет спецификации.
Что я могу?
Во-первых, вообще не используйте проприетарные функции.Не используйте их, не рекламируйте и уж точно не полагайтесь на них.
Но я понимаю, что это легче сказать, чем сделать.
Если вы не можете полностью избежать собственности собственности, вот несколько советов.
Я уверен, что вы можете следовать им:
- Убедитесь, что использование функции соответствует принципам прогрессивное улучшение (примечание: аналога на русском языке не нашел; вариант перевода - постепенное улучшение) , чтобы конструкция могла работать и без него.
- Не говорите о таких функциях, а если вы им расскажете, обязательно сообщите им, что они являются собственностью компании и что это значит.
- Если вы используете такую возможность в своем коде, добавьте комментарий вроде /* Внимание: нестандартное свойство */ .
Многие люди учатся, изучая существующие сайты.
Даже если вы не читаете лекции и не пишете образовательные статьи, вы все равно косвенно обучаете других каждой строкой своего кода.
- Критиковать статьи, отчеты, демонстрации и т. д., в которых без предупреждения рекламируются такие функции или которые используют только один префикс поставщика (который также является очень серьезная проблема ).
Или, что лучше, почини это , если это возможно.
Как я могу помочь стандартизировать функцию?
Если вы обнаружите, что слишком часто используете проприетарную функцию, займитесь ее стандартизацией.Могу порекомендовать несколько шагов, которые, впрочем, можно применить к любым предложениям в целом:
- Изучите альтернативы, которые предлагают стандарты.
Прежде всего изучите альтернативы, которые есть в спецификациях.
Они могут быть плохими или не иметь надлежащей поддержки браузера, но, по крайней мере, вы будете знать, чего ожидать в будущем.
Также вы можете добавить поддержку функций на будущее, таким образом вы не оставите позади другие браузеры, когда в них появится соответствующая поддержка.
Вы также можете ускорить реализацию этой функции, создание билета в браузерном трекере, который его не поддерживает, а если тикет уже открыт, оставьте комментарий и покажите, насколько это важно для вас.
Разработчики браузеров учитывают это при определении приоритетности новых функций.
- Проверьте, возможно функция уже обсуждается W3C обсуждает функции и доводит их до совершенства, используя рассылки .
Каждая рабочая группа имеет свой список рассылки.
Иногда команды собираются вместе, когда разрабатывается функция, включающая несколько технологий.
Например, рабочая группа CSS использует список рассылки www-стиль , а рабочая группа SVG использует рассылку www-svg .
Однако для функций, которые влияют как на CSS, так и на SVG, используется список рассылки.
Если вы нашли обсуждение какой-либо функции, но обсуждение никуда не клонит, вы можете попробовать возобновить обсуждение.
Но сначала изучите всю переписку и убедитесь, что ваши аргументы еще не были представлены в обсуждении и вам есть что добавить.
- Предложить функцию Постарайтесь включить в свое предложение как можно больше подтверждающей информации.
Вы можете указать:
Определите, под какую спецификацию попадает ваше предложение (полный список спецификаций CSS можно найти Здесь ).
- Ситуации, когда эту функцию можно использовать.
Это очень важно.
Никто не заинтересован в стандартизации новых функций, которые используются в редких случаях.
Покажите, что решает предлагаемая функция и как ее можно использовать.
- Ваш опыт использования.
Что вам нравится, что бы вы хотели изменить, как это можно обобщить на более широкий круг задач и т.д.
После этого добавить идентификатор спецификации в начало заголовка обсуждения .
Например, для обсуждений модулей Значения и единицы измерения (значения и величины) необходимо добавить [css3-values] (идентификаторы для каждой спецификации можно найти в ее URL).
Это гарантирует, что ваше предложение будет легче найти редакторам спецификаций, а также позволит всем, кто интересуется конкретной спецификацией, следить за ходом обсуждения.
Также следует помнить, что новые функции не добавляются к спецификациям, которые уже достигли статуса «Кандидат в рекомендацию», и, конечно, это справедливо и для всех последующих статусов, то есть «Предложенная рекомендация» и «Рекомендация».
утвержденная спецификация).
Например, если вы предлагаете добавить новый селектор, не предлагайте добавить его в модуль.
Селекторы Уровень 3 , который имеет статус рекомендации.
Однако вы можете предложить добавить его в модуль «Селекторы уровня 4».
Если вы хотите узнать больше о процессе стандартизации, прочтите эту замечательную серию статей.
Внутри рабочей группы CSS от Фантасай.
Это все сложно и скучно!
То же самое можно сказать о любой экологической проблеме.Да, это определенно сложнее, чем просто использовать фирменные возможности для решения сегодняшних задач.
Но в долгосрочной перспективе в интересах всех не делать этого.
Переведено с разрешения Журнал List Apart и автор(ы).
-
Сага Вариантов
19 Oct, 24 -
Когда Новый Год Наступит Рано (Сборка 9716)
19 Oct, 24 -
Eeepc — Идеальный Гаджет Для Блоггера
19 Oct, 24
