CSS
Comments 60
-13
Из примера не понятно чем

color: var(header-color);

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

color:  #99D1FF;


А вообще — Ура!
0
Пример просто показывает синтаксис
более глобальный пример смысла нет приводить — по-идее и так все очевидно :)
если у вас в коде 20 раз встречается color: #99D1FF, то лучше один раз объявить этот цвет сверху как переменную, чем общей заменой потом бегать по всему документу
UFO landed and left these words here
+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
Это объясняеся тем, что не вводится новый синтаксис, а используется старый. В итоге старые браузеры просто проигнорируют, а новые обработают, как положено. ИМХО :).
UFO landed and left these words here
0
Может, это просто разные штуки?
Т.е. есть спека CSS Variables, состоящая из модулей. Этот модуль первый. И этот модуль является частью какого-то раздела спек CSS3, посвященных переменным
UFO landed and left these words here
+2
Задумался. Действительно, не совсем ясно
Надо звать в пост приближенных, пусть объясняют )
-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
Если мы говорим о мире, где все соблюдают спецификации, то всё верно: как только в спецификациях появился пункт обработки ошибок разбора и трактовки документа, вендоры стали плевать на них по правилам.
UFO landed and left these words here
0
ЕМНИП ...

Может ваша вам изменяет, а вполне возможно, что моя мне. Старые спецификации, наверное, ещё можно где-нибудь отыскать, если очень любопытно.
UFO landed and left these words here
-1
Вообще в sass куча интересных плюшек. Например написав одно правило — он дополнит его -web-… -moz-… filter:… для кроссбраузерности, или например можно указать что один элемент светлее другого на 10 процентов. Иногда использую его когда верстаю с нуля. Жаль браузеры сами не могут разобрать этот синтаксис.
0
Когда нибудь…

А пока, у меня, вместо переменных группировки по 20 селекторов.
+1
из дока, все объявленные переменные — глобальные. теперь непонятно как объявить две переменные var-color.
Из предложенного синтаксиса, :root явно просится на роль неймспейса. Давая возможность получить переменную таким образом var(:root.foo)
+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-библиотеки.
UFO landed and left these words here
0
Действительно, чего это я? Но всё равно префиксы мне больше нравятся, а скобочки оставить для классического примера:

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

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

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

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

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

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

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

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

Правда работать наверняка не будет в случае, если в 1ом элементе сидит какая-нибудь дрянь динамических размеров, подгружаемая скриптом, т.к. значение константе height_1 присвоится еще до прогрузки оного, а постоянно проверять, не изменилось ли height1 уже совсем не задача языка стилей.
Only those users with full accounts are able to leave comments. , please.