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