Префикс или постхак

Эрик Мейер 19 августа 2010

В то время, как поддержка CSS в браузерах улучшается с каждым днём — включая впечатляющие успехи команды разработчиков IE9 — всё больше и больше авторов увлекаются CSS3. По этой причине им приходится сталкиваться с браузерными префиксами — свойствами вида -*-, вроде -moz-border-radius, -webkit-animation и так далее.

И конечно же, по поводу этих префиксов слышится ворчание. Звучат призывы совсем отказаться от них или объединить все специфичные браузерные префиксы в один вида -beta-. Главная причина всего этого шума — никто, на самом деле, не хочет писать одно и то же свойство четыре или пять раз подряд только для того, чтобы, скажем, скруглить уголки.

Даже если это ворчание и можно понять, оно всё равно несправедливо. На самом деле, мы должны благодарить производителей браузеров за использование префиксов и безусловно поощрять их развитие. Более того, я уверен, что префиксы должны стать основой процесса развития стандарта CSS. И я говорю это не от большой любви к повторению правил, а, напротив — от большого желания видеть последовательное развитие CSS. Я верю, что префиксы на самом деле могут ускорить развитие и совершенствование CSS.

Вспоминая ужасы

Для понимания того, почему браузерные префиксы в принципе существуют, очень поучительно будет вспомнить историю с блочной моделью, которая чуть не убила CSS на пороге второго тысячелетия. Противоречивые реализации блочной модели в браузерах привели тогда к серьёзному кризису. Для того, чтобы обезопасить себя от такой ситуации в будущем, мы должны придумать новый механизм на основе существующих возможностей языка и изобрести принципиально новый тип хаков.

Для наших самых маленьких читателей, пропустивших всё веселье, — история произошла следующая: среди первых браузеров, поддерживающих CSS, Netscape внедрил блочную модель, найденную в CSS-спецификации. Это означало, что свойства width и height соотносились с шириной и высотой границ содержимого блока. А Internet Explorer внедрил интуитивную блочную модель, в которой свойства width и height обозначали размеры по внешней границе блока.

Какая бы из реализаций ни казалась удачнее, факт оставался фактом — в тот момент на рынке существовало два браузера принципиально несовместимых друг с другом, и у каждого из них была большая пользовательская база. Дело было в конце 90-х, когда мы боролись как проклятые, чтобы вырваться из трясины предупреждений «этот сайт лучше всего отображается в…», и обычной была ситуация, когда одна и та же вёрстка отлично работала в одном браузере, но напрочь разваливалась в другом.

Суть проблемы состояла в том, что каждый из браузеров не мог изменить своего поведения до зеркального соответствия другому. Представим на секунду, что команда разработчиков IE решает изменить поддержку CSS для большего соответствия спецификации. Подобный поступок привёл бы к тому, что десятки или даже сотни тысяч сайтов, работавших в IE, не просто где-то там сломаются, а буквально развалятся на части в определённых версиях браузера. И пока всё сообщество веб-стандартистов будет рукоплескать этому поступку, весь остальной мир откажется от браузера по причине полной его бесполезности. И даже если Рабочая группа CSS (CSS Working Group) решит изменить спецификацию для соответствия поведению IE, то Netscape столкнётся ровно с теми же трудностями.

Таким образом и был придуман механизм переключения <DOCTYPE>. Вся эта история со «стандартным» (standards mode) и «хитрым» (quirks mode) режимами выросла как раз из этой ситуации. Механизм переключения <DOCTYPE> решал многие проблемы, но его появление спровоцировали именно сложности с блочной моделью. Вдумайтесь: из-за того, что два браузера вели себя по-разному, сегодняшние браузеры вынуждены поддерживать два основных режима обработки страниц и выбирать нужный на основании SGML-декларации, в которой вообще ничего не сказано про обработку страниц.

Более того, все CSS-хаки первой волны были посвящены именно этой проблеме. Название классического представителя хаков той поры говорит само за себя: «хак для блочной модели» (The Box Model Hack). Фактически, сам хак был основан на ошибке в синтаксической обработке значения свойства voice-family, но почему-то никто ни разу не назвал его «voice-family-хак».

Самое смешное, что это был не единственный случай, в котором непоследовательность внедрения спецификации привела к проблемам. Спустя некоторое время после появления механизма переключения <DOCTYPE>, спасшего CSS, команда разработчиков IE внедрила некоторые CSS-свойства позиционирования. Одним из внедрённых свойств было clip. Наученные горьким опытом шумихи с блочной моделью, инженеры Microsoft с большим вниманием отнеслись к спецификации и сделали всё в точности так, как там было сказано.

Вскоре после публичного релиза браузера, Рабочая группа CSS серьёзно поменяла принцип работы свойства clip. Синтаксис выглядел точно так же, однако приводил совсем к другим результатам.

В очередной раз спецификация вошла в противоречие с публично доступным браузером — или, если хотите, наоборот. Окончательным решением стало возвращение к прежнему поведению и полный отказ от нового. Фактически, это свойство стало бесполезным для элементов с непредсказуемой высотой и шириной — т.е. для всех незамещаемых элементов в нормальном потоке, вроде элементов <div> и <p>. Подробнее о типах элементов (replaced, non-replaced) можно прочитать в документации W3C. Несмотря на то, что были предложены и другие варианты решения, они так и не были реализованы, и свойство clip утратило часть своей полезности.

Представим себе другой исход

Предположим, что вместо внедрения свойства clip разработчики IE внедрили бы свойство -ms-clip. В этом случае было бы не так сложно справиться с последующим изменением поведения в спецификации. Из-за того, что префикс обозначает для свойства статус «в разработке», в дальнейшем производителю браузера будет гораздо проще пересмотреть работу свойства. Таким образом, разработчики IE могли бы поменять поведение свойства -ms-clip, в следующем релизе и объяснить разработчикам, что они обновили экспериментальное свойство для соответствия спецификации.

И даже если бы они решили, что сделать это невозможно, вся опасность «неправильного» внедрения была бы изолирована в рамках префиксной версии свойства. Другие производители браузеров могли бы внедрить новую версию свойства clip (со своим префиксом) и это никак бы не повлияло на то, что сделали разработчики IE. Один производитель никак не смог бы навредить своими действиями спецификации и другим производителям.

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

Мы конечно можем заявить: «Когда браузер неправ по отношению к спецификации, то он должен изменить реализацию, даже если это сломает вёрстку сайтов». Благодаря предупреждению о рабочем статусе свойства, которое подразумевают префиксы, сделать это становится гораздо проще. Без использования префиксов это крайне сложно или, зачастую, просто невозможно. Microsoft так и не изменила способ расчёта width и height для устаревших сайтов — вместо этого она использовала объявление <DOCTYPE> для включения другого поведения для новых (теоретически, более совместимых со стандартами) сайтов. Это был очень полезный и необходимый трюк, но один из тех, что срабатывают только один раз.

И даже сейчас мы страдаем

И если вы думаете, что все эти глупости стали частью истории, вот вам два примера несовместимости, существующие прямо сейчас:

Браузеры на движках Mozilla и Webkit обрабатывают размытие для свойства box-shadow по-разному, и ни одна из реализаций полностью не соответствует спецификации. И пока я пишу эти строки, длинные и жаркие дебаты кипят в рассылке www-style. По меньшей мере одной, а, возможно, и обеим реализациям размытия тени придётся измениться для достижения совместимости. То же самое справедливо и для реализаций Opera и Microsoft.

Браузеры на движках Mozilla и Webkit поддерживают градиенты, используя категорически разный синтаксис для достижения простых результатов. А теперь представьте ситуацию, в которой производители браузеров внедрили бы градиенты без префиксов. В ней мы имеем три варианта:

  1. Выбрать, какой браузер получит градиенты, а какой нет;
  2. использовать CSS-хаки или фильтрацию браузеров для выдачи разных стилей разным браузерам;
  3. полностью отказаться от использования градиентов.

И мы имеем здесь целых три варианта только потому, что градиенты, реализованные в этих браузерах, имеют очень разный синтаксис, что открывает дорогу для первого варианта. В случае, когда обе реализации имели бы схожий синтаксис значения, но различную реализацию — как в истории со свойством clip — у нас были бы только два последних варианта: хакать и фильтровать для выдачи разных стилей, либо просто отказаться от этой затеи.

Мы уже вдоволь находились по этим граблям за всю историю развития CSS. Нет смысла наступать на них ещё раз, если первая дюжина попыток закончилась плохо.

Пре-фикс или пост-хак

Но настолько ли хороши префиксы? В конце концов, было же сказано, что префиксы — это всего лишь новые CSS-хаки. Как сказал Аарон Густафсон в недавней статье, это:

-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
 border-radius: 10px 5px;

…слишком напоминает вот эту историю:

padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;

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

Более того, префиксы — это временный хак. Со временем, когда реализация свойств станет более совместимой, браузеры просто откажутся от префиксов. И тогда авторы смогут писать всего одну строку вместо шести с чем-то для свойства border-radius. Без префиксов мы будем вынуждены ждать очередных сомнительных реализаций и год от года поддерживать их при помощи хаков.

Поэтому создание единого префикса, вроде -beta- или -w3c- — это, по меньшей мере, полшага назад. Это, конечно, позволит производителям помечать свойства префиксом «в разработке» и делать в дальнейшем необходимые изменения, но, к сожалению, полностью закроет для авторов возможность исключать поддержку или просто отдавать различные значения каждому отдельному браузеру, в случае очередной сомнительной реализации. С точки зрения авторов, единый префикс ничем не лучше, чем полный отказ от них.

Иногда мне кажется, что так же история обстоит и с методами предварительной обработки кода для работы с префиксами — серверными (при помощи LESS) или клиентскими (куча JS-фреймворков). Использование этих инструментов позволяет просто писать правило border-radius и поручать им разворачивание этой строки в список необходимых правил с префиксами. С одной стороны, это уменьшает количество необходимого кода и повышает его чистоту и понятность. С другой стороны, этот подход мало чем отличается от ситуации с единым префиксом или вообще без них — всего одна неудачная реализация, и ваша вёрстка развалится.

Преимущество этого способа состоит в том, что если что-то пойдёт не так, то любой автор сможет вернуться, отключить препроцессинг и написать все префиксы вручную. Или сами препроцессоры кода могут обновиться для решения проблемы. В любом случае, это некоторый перебор сложности для авторов, хотя и не такой большой.

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

Делаем префиксы действительно важными

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

Вот что я имею в виду: предположим, что кто-то изобрёл новое свойство под названием text-curl. Тотчас же трое производителей реализуют его. Каждый из них будет обязан добавить префикс к своей реализации. Таким образом, получается следующая картина:

h1 {
    -webkit-text-curl: minor;
    -moz-text-curl: minor;
    -o-text-curl: minor;
    text-curl: minor;
}

Со временем производители совершенствуют свои реализации в ответ на сообщения об ошибках и уточнения от Рабочей группы CSS. В какой-то момент Рабочая группа решает, что две из трёх реализаций вполне совместимы со спецификацией. Тогда две эти реализации начинают поддерживать оригинальное свойство. Третья — нет.

В этот момент авторы могут решить упростить свои стили до следующих:

h1 {
    -webkit-text-curl: minor;
    text-curl: minor;
}

В отличие от ситуации с хаками, которые только разрастаются со временем, мы просто отбрасываем ненужное. В итоге, всё, что остаётся — это одна строчка с text-curl.

И что же происходит, когда дебютирует очередная реализация? В первом своём релизе она также использует префикс, вне зависимости от количества уже существующих удачных реализаций. Значит, нам придётся вернуться к нашему CSS и поменять его следующим образом:

h1 {
    -ms-text-curl: minor;
    text-curl: minor;
}

Как только Рабочая группа сочтёт реализацию свойства -ms-text-curl полной, префикс сможет быть отброшен в следующей версии IE. После чего CSS снова может быть уменьшен до единственной беспрефиксной строчки. И снова — количество хаков только уменьшается со временем.

Конечно, каждый из производителей продолжит поддерживать свойства с префиксами, так что даже если мы и не удалим эти правила, каждый из поддерживаемых браузеров распознает и использует свойство без префикса, если конечно оно будет следовать после правила с префиксом. Для любого браузера, который внедрил свойство с префиксом и не позаботился о том, чтобы привести его в беспрефиксное состояние, это свойство по-прежнему будет работать. Даже если CSS-код останется нетронутым, он всё равно продолжит функционировать.

Вернёмся к тому моменту, когда Рабочая группа называет две реализации полностью совместимыми и даёт им право избавиться от префиксов. Эта ситуация приводит к двум результатам. Во-первых, как я уже говорил, это говорит о том, что свойство имеет достаточный уровень совместимости, и это позволяет развивать процесс стандартизации дальше.

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

Это полностью меняет существующий сейчас порядок вещей. Так уж пошло, что когда CSS-модуль достигает статуса возможной рекомендации (CR), производители начинают отказываться от префиксов для свойств из этого модуля. Но такая ситуация снова приводит к возможности появления некачественных реализаций и новых хаков для решения возникших проблем.

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

Заключение

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

И когда в следующий раз вы начнёте ворчать по поводу указания одних и тех же правил четыре раза, по одному на каждый из браузеров, вспомните, что это временная проблема. Это немного напоминает вакцинацию — укол побаливает, это правда, но всё не настолько плохо по сравнению с болезнью, которую он предотвращает. И в нашем случае вы вакцинируетесь от многолетней возни с хаками, от фильтрации браузеров, и от других скверных вещей. Мы уже однажды пережили эту эпидемию. При должном использовании префиксы позволят надолго сдержать очередную вспышку этой напасти.

Перевод оригинальной статьи «Prefix or Posthack» Эрика Мейера (Eric Meyer), опубликованной на сайте A List Apart.

Теги: ,

Комментарии +

  1. A.I. 19 августа 2010 в 2:07

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

  2. trice4 19 августа 2010 в 3:37

    Кстати, для некоторых свойств можно ведь создать свой класс. Например:

    
    .border-radius-10-5 {
        -moz-border-radius: 10px 5px;
        -webkit-border-top-left-radius: 10px;
        -webkit-border-top-right-radius: 5px;
        -webkit-border-bottom-right-radius: 10px;
        -webkit-border-bottom-left-radius: 5px;
        border-radius: 10px 5px;
    }
    
    

    И затем просто этот класс подставлять к нужным элементам. Тогда пропадет раздражение из-за повторения.

  3. Вадим Макеев 19 августа 2010 в 3:47

    A.I., никто не предлагает верстать под конкретные браузеры. Это всего лишь удобный способ для обкатки новых свойств и разрешения некоторых проблем, вроде различного синтаксиса для градиентов. История с будущими браузерами и их префиксами пока звучит крайне теоретически — попробуйте придумать пример.

    trice4, так и до классов no-border-right доберёмся, сомнительное удовольствие.

  4. Алексей 19 августа 2010 в 6:34

    Ух, на одном дыхании, спасибо

  5. tibalt 19 августа 2010 в 7:02

    Не вижу проблем с новыми браузерами. Просто кому надо напишут:

    
    {
      -conq-border-radius: 10px;
      border-radius: 10px;
    }
    
    

    При этом, как написано в статье, конкверер должен понимать обе строчки, отдавая приоритет второй (если вдруг свойство уже зарелизено).

  6. tibalt 19 августа 2010 в 7:03

    п.с. кстати, статья очень интересная)

  7. settler 19 августа 2010 в 9:14

    A.I., согласен. Могли бы уже для таких случаев ввести еще и тот же префикс -beta, которым бы пользовались какие-то непопулярные браузеры, или чтобы при появлении поддержки свойства в браузере, оно уже могло использоваться, а не ждать пока на каждом сайте подправят стили:
    -beta-border-radius: 10px 5px;
    -moz-border-radius: 10px 5px;
    border-radius: 10px 5px;

  8. bolk 19 августа 2010 в 9:57

    Самое неудобное, это не имена свойств, а имена псевдоселекторов. По спефикации браузер обязан игнорировать стиль, если в его селекторе ему что-то неизвестно. Отсюда получается, что стиль придётся повторить по числу префиксов, плюс ещё раз без префикса.

  9. jin 19 августа 2010 в 10:19

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

  10. Cuprum 19 августа 2010 в 15:12

    Спасибо за перевод!
    Я думаю, мало кто из верстальщиков постоянно будет проверять, можно ли отбросить префикс и использовать оригинальное свойство, тем самым сократив объем стилей. Человек ленив и код в итоге все равно будет оставаться расбухшим.
    Раздражает еще различный синтаксис написания свойств с префиксом у разных браузеров. Пусть рендерят по своему, пусть. Но разве трудно начать применять рекомендованные w3c правила написания уже на стадии свойства-с-префиксом?

  11. dec5e 20 августа 2010 в 13:02

    Сценарий, описанный в разделе «Делаем префиксы действительно важными» звучит красиво, но слишком уж он идеальный. Ну не будут браузеры ждать W3C. Никогда не ждали. Потому, чаще всего, и возникали разногласия в реализациях свойств.
    Но идея префиксов для всех свойств (вообще всех) — это интересно. Удобный вариант Conditional Comments для CSS получился бы. Писать -ms-height вместо *height — красота. Жаль, это если и появится, то в тех браузерах, где большинство таких хаков будет уже не нужно.

  12. Роман 22 августа 2010 в 8:57

    Ага, а после выхода новых версий браузеров клиенты несутся с деньгами к вам для того что бы вы поубирали ненужные свойства : )

  13. tenshi 29 августа 2010 в 23:41

    автор недальновидный совсем.
    префиксы не решают проблемы, ибо они - костыль.

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

    для крутых браузеров:
    outline: 1px solid red;

    но для неподдерживающих outline придётся эмулировать:
    border: 1px solid red;
    margin: -1px;
    padding: 1px;

    префиксами эту проблему совсем не решить.

  14. myfreeweb 30 августа 2010 в 12:54

    Когда читал оригинал на ALA, не заметил, кто автор :D

    tenshi, ну да, Эрик Майер такой недальновидный ;) А тебе нужен Modernizr.

  15. matt 4 сентября 2010 в 18:48

    Спасибо за перевод. В целом абсолютно согласен с Майером в плюсах префиксов, но это, имо, лишь шаг вперёд между войной движков, брендов и версий браузеров. Поддерживаю в этом вопросе Тенши и полностью с ним согласаюсь на счёт CC. Печально, что ни один из производителей не понял преимуществ данного инструмента.

  16. Shift-Web 24 декабря 2010 в 3:52

    Я довольно долго думал, что делать с невалидностью и решил проблему подключением дополнительного CSS, который содержит все вендоры. Это избавляет от пересмотра большого числа кода и позволяет одним махом избавиться от всего тестового функционала. Метод описан тут: http://www.shift-web.ru/validniy-css3-vendornye-prefiksy

  17. Анимешная девочка 12 апреля 2011 в 22:02

    Очень хорошая статья и перевод, спасибо.
    В отношении префиксов, хаков и несовместимостей: исходить нужно из того, что всегда будут программы, технологически отстающие и/или реализующие стандарт неверно. На эту проблему нельзя закрыть глаза, потому что она существует и реальна — идеализм напрочь разбивается об IE8 и 9, и не только, к сожалению.
    Все равно вендорные префиксы — гораздо меньшее зло, чем одно и то же свойство, по-разному реализованное в каждом браузере. Можно считать их хаками by design.
    А идеальная верстка не содержит conditional comments, хаков, вендорных префиксов, не ломается в актуальных браузерах и не существует.

  18. Grawl 6 декабря 2011 в 12:47

    Префиксы — это хорошо. Эта статья многое объяснила. Благодарю.
    Но всё это может быть воспринято как “мы всё равно верстаем под разные браузеры”. А на деле же — под разные движки браузеров.
    '-webkit-' — WebKit (Chrome, Safari, Stainless, Raven)
    '-o-' — Presto (Opera, Opera Mobile, Nintendo DS Browser, Nokia 770, Internet Channel)
    '-ms-' — Trident (IE6, IE7, IE 8, Internet Explorer 9, Internet Explorer 10)
    '-moz-' — Gecko (Firefox, Thunderbird, Epiphany).
    Но почему префиксы были названы не в честь движков, а — как-будто в спешке — как попало? Было бы удобнее (для читаемости кода, для логичности) назвать их трёхбуквенными сокращениями имён движков, как-то так: wkt, pre, tri, gck.

  19. Grawl 6 декабря 2011 в 12:58

    А для избавления от возни с префиксами, кстати, использую примеси LESS. Чумовая вещица.

  20. Grawl 6 декабря 2011 в 14:01

    А вообще, можно было бы сделать эдакий скриптец для ленивых, который прогонял бы через себя CSS, добавляя там, где надо, префиксы. И обновлять этот скриптец. Что скажете?

  21. Вадим Макеев 6 декабря 2011 в 14:04

    Grawl, такой скриптец уже есть: -prefix-free но я бы не стал его рекомендовать. Теперь вы знаете зачем писать префиксы, а если вам это лень, то значит вам лень работать

  22. Urrri 5 марта 2012 в 17:32

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

    
    @browser gecko>6- gecko>7+ gecko>8+-9{
    ...
    }
    
    

    Где + определяет версии начиная с указанной, а - версии до указанной включительно. +- определяет диапазон версий.

  23. Сергей 14 мая 2012 в 15:17

    Для всех свойств справедлив порядок — «последним идет без префикса» или есть исключения? Например, для border-radius такой порядок также критичен, как для box-shadow?

  24. Вадим Макеев 14 мая 2012 в 15:23

    Сергей, указанный порядок следования универсален для всех свойст с префиксами и позволяет вашему коду оставаться максимально совместимым в условиях, когда производители браузеров улучшают реализацию свойств в версиях без префикса. Пример с box-shadow и Webkit-ом самый яркий, но есть и другие.

  25. Михаил 25 декабря 2012 в 16:25

    Непонимаю, почему в примере с border-radius нельзя писать просто одной строкой, а обязательно транслировать с -moz ...
    Мозила не может просто брать border-radius и обрабатывать его по своему?
    Мне то как верстальщику все-равно как там что будет на уровне браузера, главное - отображение.

Разрешённые HTML-теги: <blockquote>, <a href="…">, <del>, <strong>, <b>, <em>, <i>.
Исходный код блочного уровня для лучшего отображения обрамляйте в элемент <source>.

Перейти к началу