Comments 60
Из примера не понятно чем
будет лучше, чем
А вообще — Ура!
color: var(header-color);
будет лучше, чем
color: #99D1FF;
А вообще — Ура!
-13
Пример просто показывает синтаксис
более глобальный пример смысла нет приводить — по-идее и так все очевидно :)
если у вас в коде 20 раз встречается color: #99D1FF, то лучше один раз объявить этот цвет сверху как переменную, чем общей заменой потом бегать по всему документу
более глобальный пример смысла нет приводить — по-идее и так все очевидно :)
если у вас в коде 20 раз встречается color: #99D1FF, то лучше один раз объявить этот цвет сверху как переменную, чем общей заменой потом бегать по всему документу
0
UFO just landed and posted this here
интересно, чем обоснован именно такой, странный на мой взгляд, способ объявления и использования.
+15
Если почитать черновики, там этот вопрос обсуждается, например тут
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.
На сколько я понял, не факт, что это будет конечным вариантом. плюс могут быть какие-нибудь ограничения в существующих спецификациях.
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.
На сколько я понял, не факт, что это будет конечным вариантом. плюс могут быть какие-нибудь ограничения в существующих спецификациях.
+2
Как я понимаю, такой синтаксис позволяет создавать локальные переменные, контролировать область видимости.
+1
а вообще, наверное для того, чтобы стили могли писать только верстальщики — у программистов рука не поднимется ломать устоявщиеся стереотипы объявления переменных )
0
Это объясняеся тем, что не вводится новый синтаксис, а используется старый. В итоге старые браузеры просто проигнорируют, а новые обработают, как положено. ИМХО :).
0
UFO just landed and posted this here
Может, это просто разные штуки?
Т.е. есть спека CSS Variables, состоящая из модулей. Этот модуль первый. И этот модуль является частью какого-то раздела спек CSS3, посвященных переменным
Т.е. есть спека CSS Variables, состоящая из модулей. Этот модуль первый. И этот модуль является частью какого-то раздела спек CSS3, посвященных переменным
0
Как то это больше похоже на константы
+4
Только не после внедрения calc(…).
var-foo: calc( var(foo) + 1 );
0
Не ясно, зачем они переменные с функциями мешают. Солянка какая-то в итоге выходит.
Сама идея объявлять переменную идентификатором с var-, а в правилах обращаться к ней через некую функцию var(), выглядит в css инородно.
Если документ про переменные, как написано в заголовке черновика, то делать нужно было примерно в таком ключе — pypi.python.org/pypi/pycsse/
Сама идея объявлять переменную идентификатором с var-, а в правилах обращаться к ней через некую функцию var(), выглядит в css инородно.
Если документ про переменные, как написано в заголовке черновика, то делать нужно было примерно в таком ключе — pypi.python.org/pypi/pycsse/
+12
Странно что это не понятно сначала — это сделано для того, чтоб можно было ввести этот новый функционал не изменяя синтаксические правила CSS (обратная совместимость). var-foo — это свойство. И написано оно по правилам написания свойств. То что старый бразуер его не распознает — беды нет. var(foo) — это значение свойства, написанное по правилам написания значений (см. url, linear-gradient итд). В таком написании это значение никогда не совпадет с каким-либо уже определенным значением.
+1
Обратная совместимость css представляется мне химерой: браузеры давно, смачно и с успехом плюют на невалидные части документов. Не будем здесь рассуждать, хорошо это или плохо, просто примем к сведению этот факт. Плюс к этому, предложенный в черновике вариант не самый лучший пример сохранения совместимости, с сопутствующими жертвами в виде удобства принятия синтаксиса.
+2
Вообще в sass куча интересных плюшек. Например написав одно правило — он дополнит его -web-… -moz-… filter:… для кроссбраузерности, или например можно указать что один элемент светлее другого на 10 процентов. Иногда использую его когда верстаю с нуля. Жаль браузеры сами не могут разобрать этот синтаксис.
-1
Когда нибудь…
А пока, у меня, вместо переменных группировки по 20 селекторов.
А пока, у меня, вместо переменных группировки по 20 селекторов.
0
из дока, все объявленные переменные — глобальные. теперь непонятно как объявить две переменные var-color.
Из предложенного синтаксиса, :root явно просится на роль неймспейса. Давая возможность получить переменную таким образом var(:root.foo)
Из предложенного синтаксиса, :root явно просится на роль неймспейса. Давая возможность получить переменную таким образом var(:root.foo)
+1
Простите за любопытство, а зачем вам две переменные color?
0
вы правы, мне не зачем две переменные 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'.
: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'.
+1
Я, конечно, не знаю как у вас организуются стили, но обычно есть некий гайд-лайн, в котором все цвета заданы, и, по-моему, вполне логично задать по новому синтаксису что-то вроде:
:root {
light_yellow: #bla;
dark_green: #blabla;
}
Иметь свой локальный цвет в зависимости от контекста применения это, конечно, круто, но зачем?
:root {
light_yellow: #bla;
dark_green: #blabla;
}
Иметь свой локальный цвет в зависимости от контекста применения это, конечно, круто, но зачем?
0
Возникает вопрос почему они начали придумывать свое «нечто» и свой синтаксис (который приходится обосновывать, не очень вразумительным комментарием приведенным здесь в топике), когда есть уже сейчас как минимум два уже давно зарекомендовавшие себя решения такие как sass(scss) и lesscss с продуманным синтаксическим с иерархическим наследованием и прочим «сахором».
Приведенные в топике куски когда не вызывают душевного трепета, а плюс нативности обработки браузерами(неизвестно когда и какими) полностью нивелируется — простотой автоматизации сборки sass(scss) и lesscss серверными скриптами в обычный css.
Приведенные в топике куски когда не вызывают душевного трепета, а плюс нативности обработки браузерами(неизвестно когда и какими) полностью нивелируется — простотой автоматизации сборки sass(scss) и lesscss серверными скриптами в обычный css.
+4
Видимо, потому что с сахаром можно переборщить — приторно.
0
Но можно ведь положить по желанию?
— Вам два кусочка или кофе налить в сахарницу?
— Вам два кусочка или кофе налить в сахарницу?
+2
А это уже индивидуально — кто-то может себя сдержать, кто-то нет.
Трудость создания хороших тортов в том, чтобы вовремя остановиться при добавлении ингридиентов: шаг влево, и получится ирландское рагу; шаг вправо, и повысится риск вызвать диатез у потребителя. С ПО та же история.
И, да, есть немало любителей как солянок, так и диатеза %) Неисповедимы!
Трудость создания хороших тортов в том, чтобы вовремя остановиться при добавлении ингридиентов: шаг влево, и получится ирландское рагу; шаг вправо, и повысится риск вызвать диатез у потребителя. С ПО та же история.
И, да, есть немало любителей как солянок, так и диатеза %) Неисповедимы!
0
А теперь CSS превращается, превращается в какой-то язык программирования!
Шутка, но, как говорится, в каждой из них есть доля правды.
А вообще подобные плюшки в стилях, действительно, очень нужны.
Шутка, но, как говорится, в каждой из них есть доля правды.
А вообще подобные плюшки в стилях, действительно, очень нужны.
-1
Коряво выглядит с этими var-.
Надо было как Less/Sass делать — просто впереди один спецсимвол (а какой именно, не так уж важно: хоть доллар, хоть адрес, хоть вообще амперсанд).
Надо было как Less/Sass делать — просто впереди один спецсимвол (а какой именно, не так уж важно: хоть доллар, хоть адрес, хоть вообще амперсанд).
+3
Да, префикс — лучшее решение, так как кто-то ранее уже мог теоретически именовать классы, начиная с «var-», что не запрещено существующими стандартами и спецификациями, а это в свою очередь может привести к кривому парсингу тех страниц и к последующему усложнению парсеров, которым надо будет распознавать и различать старые и новые CSS, или же приведёт к необходимости заполнять атрибут version тега link при подключении таблиц стилей, в общем героически решать создаваемые самим себе проблемы, которые можно и не создавать. Путь, которым пошли в less, мне видится наиболее гармоничным и это касается не только переменных, но и вложений, и миксинов, и операций над классами. Простое внедрение поддержки синтаксиса less в браузеры не добавит проблем с проверкой существующих страниц, а поддержка новых фич старыми браузерами — задача на пару строк, как сегодня это делается подключением уже написанной js-библиотеки.
0
UFO just landed and posted this here
Действительно, чего это я? Но всё равно префиксы мне больше нравятся, а скобочки оставить для классического примера:
.rounded-corners (@radius: 5px) {
border-radius: @radius;
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
}
#footer {
.rounded-corners(10px);
}
.rounded-corners (@radius: 5px) {
border-radius: @radius;
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
}
#footer {
.rounded-corners(10px);
}
0
UFO just landed and posted this here
Не очень понятно рассказано про область видимости этих переменных.
В любом классе объявляем-в любом используем или как?
Или же объявляем в :root и используем где угодно?
Или же как-то еще?
В любом классе объявляем-в любом используем или как?
Или же объявляем в :root и используем где угодно?
Или же как-то еще?
0
Конечно радует нововведение, но, как всегда есть много но. Мне интересно одно: а можно ли будет в переменную (которая, напоминает константу) вписывать целый css-класс? Похоже, что в данной реализации этого не будет, а было бы полезно, ИМХО.
0
UFO just landed and posted this here
Они заново изобретают lesscss/sass (scss)?
«Молодцы», при том, что упомянутые технологии уже давно и успешно работают, обсуждаемые изменения CSS по стандартному пути (читай — пути черновиков и одобрений) затянутся еще на месяцы/годы. Когда предложенное обсудят и примут, окажется, что какой-нибудь lesscss («как, опять?!») убежал вперед, в сторону удобства практики, и опять начнутся очередные нелепые попытки изобрести изобретенное другими. А уж с поддержкой на стороне браузера — вообще песня, будем делать не одну таблицу стилей (как по логике надо бы), и не две (ie6 vs все остальные), а минимум три: i6 vs сегодня нормальные браузеры vs завтрашние браузеры с поддержкой переменных в css.
Я уж как-нибудь с less, честно слово, останусь — оно хотя бы работать будет.
«Молодцы», при том, что упомянутые технологии уже давно и успешно работают, обсуждаемые изменения CSS по стандартному пути (читай — пути черновиков и одобрений) затянутся еще на месяцы/годы. Когда предложенное обсудят и примут, окажется, что какой-нибудь lesscss («как, опять?!») убежал вперед, в сторону удобства практики, и опять начнутся очередные нелепые попытки изобрести изобретенное другими. А уж с поддержкой на стороне браузера — вообще песня, будем делать не одну таблицу стилей (как по логике надо бы), и не две (ie6 vs все остальные), а минимум три: i6 vs сегодня нормальные браузеры vs завтрашние браузеры с поддержкой переменных в css.
Я уж как-нибудь с less, честно слово, останусь — оно хотя бы работать будет.
+3
UFO just landed and posted this here
Почему-то мне кажется (возможно, я заблуждаюсь), что переменные (не константы, а именно переменные, если их значения действительно можно будет менять посредством calc() или чего-то еще) в коде CSS приведут к жуткой каше. Во всяком случае, это будут уже совсем не те таблицы стилей, как их понимают сегодня.
0
Тут многое зависит от пряморукости того, кто пишет css. У некоторых сейчас и без переменных в стилях такая каша, что без ста грамм не разобраться )
+1
А я, можно сказать, мечтаю о вводе calc. Так часто не хватает возможности написать 50%+5px что аж печаль.
Ну а переменные пригодятся для хранения результатов вычисления, что-бы не пересчитывать одно и то-же. Короче верю, надеюсь, жду.
Ну а переменные пригодятся для хранения результатов вычисления, что-бы не пересчитывать одно и то-же. Короче верю, надеюсь, жду.
0
Пример с цветами не очень, можно и просто сделать как-то так:
h1,h2,h3 {
color:#FFF;
}
.class1, class2 {
color:#000;
}
и цвета будут лежать в одном месте.
calc() возможно и будет иногда полезен, но боюсь при неоправданном использовании Очень все запутает.
Случается, конечно, когда хочется ширину некоего элемента вычислить «100%-100px», но обычно все можно решить и по-другому.
h1,h2,h3 {
color:#FFF;
}
.class1, class2 {
color:#000;
}
и цвета будут лежать в одном месте.
calc() возможно и будет иногда полезен, но боюсь при неоправданном использовании Очень все запутает.
Случается, конечно, когда хочется ширину некоего элемента вычислить «100%-100px», но обычно все можно решить и по-другому.
0
отлично-отлично, ждем с нетерпением.
Давно бы пора.
p.s.
Интересно, насколько толково будет работать, к примеру, выравнивание высоты одного элемента на странице по высоте другого путем присваивания последнему значения высоты первого (height_1).
Правда работать наверняка не будет в случае, если в 1ом элементе сидит какая-нибудь дрянь динамических размеров, подгружаемая скриптом, т.к. значение константе height_1 присвоится еще до прогрузки оного, а постоянно проверять, не изменилось ли height1 уже совсем не задача языка стилей.
Давно бы пора.
p.s.
Интересно, насколько толково будет работать, к примеру, выравнивание высоты одного элемента на странице по высоте другого путем присваивания последнему значения высоты первого (height_1).
Правда работать наверняка не будет в случае, если в 1ом элементе сидит какая-нибудь дрянь динамических размеров, подгружаемая скриптом, т.к. значение константе height_1 присвоится еще до прогрузки оного, а постоянно проверять, не изменилось ли height1 уже совсем не задача языка стилей.
0
дык? чем дело кончилось?
0
Sign up to leave a comment.
Articles
Change theme settings
Переменные в CSS