0,0
рейтинг
12 апреля 2012 в 01:39

Разработка → Переменные в CSS перевод

CSS*
Если вы разработчик, то вы точно хорошо знакомы с переменными, и возможно, они одни из ваших лучших друзей. По определению, переменная — это временное хранилище, которое содержит некое значение величины или информации.
Но каким образом это относится к тому CSS, который мы все знаем? Год назад на Хабре был пост о планируемых новшествах в CSS, которые были оглашены членом рабочей группы CSS и команды Google Chrome. Среди этих новшеств было введение поддержки переменных.
И вот, буквально на днях, поступили новости о выходе первого релиза рабочего черновика CSS Переменных (CSS Variables).




Почему CSS переменные?


Переменные в CSS — эта та штука, о которой народ спрашивал и хотел довольно долгое время.
Подумайте обо всех этих цветах (colors), высотах (heights), ширинах (widths) и размерах (sizes): как бы было прекрасно объявить их всего лишь один раз. И наконец, пришло время того, чего мы так долго ждали: писать меньше, но делать больше.

Установившиеся практики в CSS


Когда люди просят об объявлении переменных цвета в css (color), добавление комментариев в верней части CSS-файла было чем-то вроде симуляции поведения переменных:

/*--------------------------
link color: #99D1FF (light blue)
box color: #555 (dark gray)
--------------------------*/

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

Как это делается в LESS/Sass


Идея использовать переменные для таблицы стилей было одной из тех причин, по которым появились LESS и Sass.

LESS




Sass




Как это будет работать теперь


Прежде всего, не забывайте, что это ни один из браузеров пока не поддерживает. Но это то, как оно будет работать в будущем:
var-foo для определения, var(foo) для использования.
Следуя черновикам:
Любое имя свойства, начинающееся с префикса “var-” является свойством переменной. (Any property name starting with the prefix “var-” is a variable property)

Пример


Следующее правило декларирует имя свойства “var-header-color” для элемента root и присваивает для него значение “#99D1FF”:

:root {
  var-header-color: #99D1FF;
}

Далее, его значение может передаваться с помощью переменной “header-color”:

h1 {
  color: var(header-color);
}

Использование переменных цвета в определении градиентов также может быть очень полезным. Вам всего лишь нужно будет заменить значение переменных, и вуаля: все градиенты обновились. Звучит довольно круто, как по мне.
Также, при создании макета, применив переменные и функцию calc() можно сделать интересные вычисления.

Вывод


CSS не является языком программирования, но он и не должен быть сложным. Однако, я думаю вы согласитесь, что использование CSS переменных поможет избежать дублирования и позволит создавать более гибкие таблицы стилей.
Теперь, когда вышел в свет первый модуль CSS переменных, мы с нетерпением ждем поддержку их браузерами в ближайшем будущем.
Перевод: Catalin Rosu
Александр Смолянинов @derSmoll
карма
110,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (60)

  • –13
    Из примера не понятно чем

    color: var(header-color);
    

    будет лучше, чем

    color:  #99D1FF;
    


    А вообще — Ура!
    • 0
      Пример просто показывает синтаксис
      более глобальный пример смысла нет приводить — по-идее и так все очевидно :)
      если у вас в коде 20 раз встречается color: #99D1FF, то лучше один раз объявить этот цвет сверху как переменную, чем общей заменой потом бегать по всему документу
    • НЛО прилетело и опубликовало эту надпись здесь
  • +15
    интересно, чем обоснован именно такой, странный на мой взгляд, способ объявления и использования.
    • +2
      Если почитать черновики, там этот вопрос обсуждается, например тут
      ISSUE 1: As defined here, the syntax for variable usage is different from the syntax for variable definition (i.e. var-foo for definition, var(foo) for usage). Some have suggested that the syntaxes should should match, using functional syntax in both cases. Others have suggested using a prefixed symbol instead of functional syntax (e.g. $foo) for both the property and usage.
      На сколько я понял, не факт, что это будет конечным вариантом. плюс могут быть какие-нибудь ограничения в существующих спецификациях.
    • +1
      Как я понимаю, такой синтаксис позволяет создавать локальные переменные, контролировать область видимости.
    • 0
      а вообще, наверное для того, чтобы стили могли писать только верстальщики — у программистов рука не поднимется ломать устоявщиеся стереотипы объявления переменных )
    • 0
      Это объясняеся тем, что не вводится новый синтаксис, а используется старый. В итоге старые браузеры просто проигнорируют, а новые обработают, как положено. ИМХО :).
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Может, это просто разные штуки?
      Т.е. есть спека CSS Variables, состоящая из модулей. Этот модуль первый. И этот модуль является частью какого-то раздела спек CSS3, посвященных переменным
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          Задумался. Действительно, не совсем ясно
          Надо звать в пост приближенных, пусть объясняют )
  • +4
    Как то это больше похоже на константы
    • 0
      Только не после внедрения calc().

      var-foo: calc( var(foo) + 1 );
      
      • 0
        Рекурсия!
        • 0
          Где тут рекурсия?
        • +1
          По вашему, "$i = $i + 1" — это тоже рекурсия? =)
          • –1
            Определённо. Многие языки такой конструкции не допускают, как то GNU Make, Erlang.

            Ясно, что в CSS будет переопределение переменной изменённым значением, но красоты этому расширению такое поведение явно не добавляет.
  • +12
    Не ясно, зачем они переменные с функциями мешают. Солянка какая-то в итоге выходит.

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

    Если документ про переменные, как написано в заголовке черновика, то делать нужно было примерно в таком ключе — pypi.python.org/pypi/pycsse/
    • +1
      Странно что это не понятно сначала — это сделано для того, чтоб можно было ввести этот новый функционал не изменяя синтаксические правила CSS (обратная совместимость). var-foo — это свойство. И написано оно по правилам написания свойств. То что старый бразуер его не распознает — беды нет. var(foo) — это значение свойства, написанное по правилам написания значений (см. url, linear-gradient итд). В таком написании это значение никогда не совпадет с каким-либо уже определенным значением.
      • +2
        Обратная совместимость css представляется мне химерой: браузеры давно, смачно и с успехом плюют на невалидные части документов. Не будем здесь рассуждать, хорошо это или плохо, просто примем к сведению этот факт. Плюс к этому, предложенный в черновике вариант не самый лучший пример сохранения совместимости, с сопутствующими жертвами в виде удобства принятия синтаксиса.
        • +2
          Они не плюют, они ведут себя так, как описано в спецификации, обработка ошибок там тоже описана
          • –1
            Если мы говорим о мире, где все соблюдают спецификации, то всё верно: как только в спецификациях появился пункт обработки ошибок разбора и трактовки документа, вендоры стали плевать на них по правилам.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                ЕМНИП ...

                Может ваша вам изменяет, а вполне возможно, что моя мне. Старые спецификации, наверное, ещё можно где-нибудь отыскать, если очень любопытно.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Спасибо, плюс вам ;)
  • –1
    Вообще в sass куча интересных плюшек. Например написав одно правило — он дополнит его -web-… -moz-… filter:… для кроссбраузерности, или например можно указать что один элемент светлее другого на 10 процентов. Иногда использую его когда верстаю с нуля. Жаль браузеры сами не могут разобрать этот синтаксис.
  • 0
    Когда нибудь…

    А пока, у меня, вместо переменных группировки по 20 селекторов.
  • +1
    из дока, все объявленные переменные — глобальные. теперь непонятно как объявить две переменные var-color.
    Из предложенного синтаксиса, :root явно просится на роль неймспейса. Давая возможность получить переменную таким образом var(:root.foo)
    • 0
      Простите за любопытство, а зачем вам две переменные color?
      • +1
        вы правы, мне не зачем две переменные color. дело в том что предложенный синтаксис немного вводит в заблуждение.

        :root { var-color: blue; }
        div { var-color: green; }
        #alert { var-color: red; }
        * { color: var(color); }

        визуально мы видим 3 разных блока, и логично принять что переменная color своя для каждого блока.

        таким образом логично иметь возможность доступа к переменным каждого блока.
        например:
        var(:root.color)
        var(div.color)
        var(#alert.color).

        Но этой возможности нет. И более того, как я понимаю, они перезапишут друг друга, и значением var(color) будет 'red'.

        • 0
          Я, конечно, не знаю как у вас организуются стили, но обычно есть некий гайд-лайн, в котором все цвета заданы, и, по-моему, вполне логично задать по новому синтаксису что-то вроде:

          :root {
          light_yellow: #bla;
          dark_green: #blabla;
          }

          Иметь свой локальный цвет в зависимости от контекста применения это, конечно, круто, но зачем?
          • +1
            мои высказывания касались именно визуального восприятия синтаксиса, не более.
  • +4
    Возникает вопрос почему они начали придумывать свое «нечто» и свой синтаксис (который приходится обосновывать, не очень вразумительным комментарием приведенным здесь в топике), когда есть уже сейчас как минимум два уже давно зарекомендовавшие себя решения такие как sass(scss) и lesscss с продуманным синтаксическим с иерархическим наследованием и прочим «сахором».
    Приведенные в топике куски когда не вызывают душевного трепета, а плюс нативности обработки браузерами(неизвестно когда и какими) полностью нивелируется — простотой автоматизации сборки sass(scss) и lesscss серверными скриптами в обычный css.
    • 0
      Видимо, потому что с сахаром можно переборщить — приторно.
      • +2
        Но можно ведь положить по желанию?
        — Вам два кусочка или кофе налить в сахарницу?
        • 0
          А это уже индивидуально — кто-то может себя сдержать, кто-то нет.
          Трудость создания хороших тортов в том, чтобы вовремя остановиться при добавлении ингридиентов: шаг влево, и получится ирландское рагу; шаг вправо, и повысится риск вызвать диатез у потребителя. С ПО та же история.
          И, да, есть немало любителей как солянок, так и диатеза %) Неисповедимы!
          • 0
            Конечно, собственно мы и не спорим вроде.
            — Сколько, когда и к месту ли? Ответить на данные вопросы можно только с опытом и учитывая максимум факторов как внешних так и внутренних, индивидуально в каждом случае.
  • –1
    А теперь CSS превращается, превращается в какой-то язык программирования!
    Шутка, но, как говорится, в каждой из них есть доля правды.
    А вообще подобные плюшки в стилях, действительно, очень нужны.
  • +3
    Коряво выглядит с этими var-.
    Надо было как Less/Sass делать — просто впереди один спецсимвол (а какой именно, не так уж важно: хоть доллар, хоть адрес, хоть вообще амперсанд).
    • 0
      Да, префикс — лучшее решение, так как кто-то ранее уже мог теоретически именовать классы, начиная с «var-», что не запрещено существующими стандартами и спецификациями, а это в свою очередь может привести к кривому парсингу тех страниц и к последующему усложнению парсеров, которым надо будет распознавать и различать старые и новые CSS, или же приведёт к необходимости заполнять атрибут version тега link при подключении таблиц стилей, в общем героически решать создаваемые самим себе проблемы, которые можно и не создавать. Путь, которым пошли в less, мне видится наиболее гармоничным и это касается не только переменных, но и вложений, и миксинов, и операций над классами. Простое внедрение поддержки синтаксиса less в браузеры не добавит проблем с проверкой существующих страниц, а поддержка новых фич старыми браузерами — задача на пару строк, как сегодня это делается подключением уже написанной js-библиотеки.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Действительно, чего это я? Но всё равно префиксы мне больше нравятся, а скобочки оставить для классического примера:

          .rounded-corners (@radius: 5px) {
          border-radius: @radius;
          -webkit-border-radius: @radius;
          -moz-border-radius: @radius;
          }

          #footer {
          .rounded-corners(10px);
          }
          • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Сложно, сложно… посмотрите на Stylus. Вот там хардкор!
  • 0
    Не очень понятно рассказано про область видимости этих переменных.
    В любом классе объявляем-в любом используем или как?
    Или же объявляем в :root и используем где угодно?
    Или же как-то еще?
  • 0
    Конечно радует нововведение, но, как всегда есть много но. Мне интересно одно: а можно ли будет в переменную (которая, напоминает константу) вписывать целый css-класс? Похоже, что в данной реализации этого не будет, а было бы полезно, ИМХО.
  • +2
    >>Прежде всего, не забывайте, что это ни один из браузеров пока не поддерживает
    Less может бегать и на клиенте
  • +3
    Они заново изобретают lesscss/sass (scss)?

    «Молодцы», при том, что упомянутые технологии уже давно и успешно работают, обсуждаемые изменения CSS по стандартному пути (читай — пути черновиков и одобрений) затянутся еще на месяцы/годы. Когда предложенное обсудят и примут, окажется, что какой-нибудь lesscss («как, опять?!») убежал вперед, в сторону удобства практики, и опять начнутся очередные нелепые попытки изобрести изобретенное другими. А уж с поддержкой на стороне браузера — вообще песня, будем делать не одну таблицу стилей (как по логике надо бы), и не две (ie6 vs все остальные), а минимум три: i6 vs сегодня нормальные браузеры vs завтрашние браузеры с поддержкой переменных в css.

    Я уж как-нибудь с less, честно слово, останусь — оно хотя бы работать будет.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Почему-то мне кажется (возможно, я заблуждаюсь), что переменные (не константы, а именно переменные, если их значения действительно можно будет менять посредством calc() или чего-то еще) в коде CSS приведут к жуткой каше. Во всяком случае, это будут уже совсем не те таблицы стилей, как их понимают сегодня.
    • +1
      Тут многое зависит от пряморукости того, кто пишет css. У некоторых сейчас и без переменных в стилях такая каша, что без ста грамм не разобраться )
    • 0
      А я, можно сказать, мечтаю о вводе calc. Так часто не хватает возможности написать 50%+5px что аж печаль.
      Ну а переменные пригодятся для хранения результатов вычисления, что-бы не пересчитывать одно и то-же. Короче верю, надеюсь, жду.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Посмотрю в эту сторону, всегда считал эту задачу невыполнимой.
  • 0
    Пример с цветами не очень, можно и просто сделать как-то так:

    h1,h2,h3 {
    color:#FFF;
    }

    .class1, class2 {
    color:#000;
    }
    и цвета будут лежать в одном месте.

    calc() возможно и будет иногда полезен, но боюсь при неоправданном использовании Очень все запутает.
    Случается, конечно, когда хочется ширину некоего элемента вычислить «100%-100px», но обычно все можно решить и по-другому.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    отлично-отлично, ждем с нетерпением.
    Давно бы пора.

    p.s.
    Интересно, насколько толково будет работать, к примеру, выравнивание высоты одного элемента на странице по высоте другого путем присваивания последнему значения высоты первого (height_1).

    Правда работать наверняка не будет в случае, если в 1ом элементе сидит какая-нибудь дрянь динамических размеров, подгружаемая скриптом, т.к. значение константе height_1 присвоится еще до прогрузки оного, а постоянно проверять, не изменилось ли height1 уже совсем не задача языка стилей.
  • 0
    дык? чем дело кончилось?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.