Comments 92
css переменные - надеюсь от них откужутса!
да вы что, а если у вас куча мест, где один и тот же цвет упомянут? гораздо удобнее юзать переменную
это можно решить просто используя коменнтарии в стилях - одно из правил хорошего css кодинга. Переменные лишь увеличат вес кода.
Ерунду вы какую-то сказали..
Проще завести 1 переменную, и в случае чего ее менять, чем листать CSS-файл, читая код, переделывать.
К тому же 1 переменная врядли увеличит вес больше, чем комменты.
Проще завести 1 переменную, и в случае чего ее менять, чем листать CSS-файл, читая код, переделывать.
К тому же 1 переменная врядли увеличит вес больше, чем комменты.
переменная = код инициализации + имя переменной в селекторе:
А если вдруг нужно у одного из селекторов поменять значение, то нужно новую переменную вводить?:
и где логика?
@variables {
CorporateLogoBGColor: #fe8d12;
}
селектор { свойство: var(CorporateLogoBGColor); }
селектор { свойство: var(CorporateLogoBGColor); }
селектор { свойство: var(CorporateLogoBGColor); }
либо:
селектор1, селектор2, селектор3 { свойство: var(CorporateLogoBGColor); }
<strong>без переменной:</strong>
селектор1 { свойство: значение }
селектор2 { свойство: значение }
селектор3 { свойство: значение }
либо:
/* цвет фона красный */
селектор1, селектор2, селектор3 { свойство: значение }А если вдруг нужно у одного из селекторов поменять значение, то нужно новую переменную вводить?:
@variables {
CorporateLogoBGColor: #fe8d12;
CorporateLogoBGColor2: #eee;
}
селектор { свойство: var(CorporateLogoBGColor); }
селектор { свойство: var(CorporateLogoBGColor2); }
селектор { свойство: var(CorporateLogoBGColor); }
либо:
селектор1, селектор3 { свойство: var(CorporateLogoBGColor); }
селектор2 { свойство: var(CorporateLogoBGColor2); }
<strong>без переменной:</strong>
селектор1 { свойство: значение }
селектор2 { свойство: новое_значение }
селектор3 { свойство: значение }
либо:
/* цвет фона логотипа */
селектор1, селектор3 { свойство: значение }
селектор2 { свойство: новое_значение }и где логика?
я не против переменных, я за логику :) И если уж введут таковое, то логично из вышеуказанного использовать это:
Если вы хотя бы раз пользовались Css валидатором, то именно так он и поступает. Это называется оптимизированный код. И гибкость изменений он никак не ухудшает, а наоборот, упрощает. Читабельность кода - зависит от того насколько вы опытны в css вообще. И если опыт все же есть, то группировка вас только выручит.
селектор1, селектор2, селектор3 { свойство: var(CorporateLogoBGColor); }
Если вы хотя бы раз пользовались Css валидатором, то именно так он и поступает. Это называется оптимизированный код. И гибкость изменений он никак не ухудшает, а наоборот, упрощает. Читабельность кода - зависит от того насколько вы опытны в css вообще. И если опыт все же есть, то группировка вас только выручит.
есле куча мест где один и тот же цвет - надо групировать селекторы! Это вам любой CSS валидатор посоветует. А внедрение переменных значительно услжниит выполнение CSS. Вот хотябы почитай здесь
Группировка снижает читабельность кода и гибкость изменений. Этот [самый примитивный, что и говорить] метод обобщения не выдерживает никакого сравнения с удобством переменных.
1. Ты сначала почитай какие изменение это внесёт в обработчик CSS
2. Приведи реальные примеры с использованием CSS переменных.
2. Приведи реальные примеры с использованием CSS переменных.
1. Какое это имеет значение? Любые дополнения в стандарте ориентированы на удобство в будущем. По-вашему, новые возможности добавлять не нужно?
2. Один и тот же цвет, указанный 10 раз. Бритва Оккама, все пироги. ;-)
2. Один и тот же цвет, указанный 10 раз. Бритва Оккама, все пироги. ;-)
так имя переменной тоже 10 раз придется указывать (10 селекторов) :)
зато менять цвет, если что, придётся один раз а не 10
a, b, c, d, e, f { color: white }
разве ты этого не знал?
разве ты этого не знал?
Знал. Но не применяю, так как это сделает код почти нечитабельным: всё описание класса находится в одном месте, а его цвета — через 150 строчек, в куче с другими какими-то классами?
вот скажи мне что лучше:
a, b, c, d, e, f { color: white }
или
a { color: var(myvar) }
b { color: var(myvar) }
c { color: var(myvar) }
d { color: var(myvar) }
e { color: var(myvar) }
f { color: var(myvar) }
Какой из этих двух примеров правельние?
a, b, c, d, e, f { color: white }
или
a { color: var(myvar) }
b { color: var(myvar) }
c { color: var(myvar) }
d { color: var(myvar) }
e { color: var(myvar) }
f { color: var(myvar) }
Какой из этих двух примеров правельние?
a, b, c, d, e, f { color: var(myvar) }
Слишком однобоко вы мыслите, товарищь. Но код-то более читабельный получается с переменной, да и сменить значение одной переменной для всего CSS проще имхо.
Слишком однобоко вы мыслите, товарищь. Но код-то более читабельный получается с переменной, да и сменить значение одной переменной для всего CSS проще имхо.
А смысл объявлять переменную?!
a { color: var(myColor) }
b { background-color: var(myColor) }
c { border-color: var(myColor) }
Попробуйте оптимизировать.
Другой пример, с которым приходится часто сталкиваться - решается проще с переменными:
.sidebar { width: var(sidebarWidth) }
.content { margin-left: var(sidebarWidth) }
.panel { left: var(sidebarWidth); position: absolute; }
b { background-color: var(myColor) }
c { border-color: var(myColor) }
Попробуйте оптимизировать.
Другой пример, с которым приходится часто сталкиваться - решается проще с переменными:
.sidebar { width: var(sidebarWidth) }
.content { margin-left: var(sidebarWidth) }
.panel { left: var(sidebarWidth); position: absolute; }
Не путайте примеры и реальность. Если вам так повезло и есть возможность — группируйте. Разуемеется, если есть классы a и b, в которых примерно треть описаний совпадает, их можно вынести в одно. А если в них указано по 10 свойств, и из них одна совпадает — смысла группировки нет. Ситуация усугубляется, когда классов много (а так обычно и есть) и из, допустим, a и b можно вынести одно свойство, из a и c — ещё одно. В итоге код, хоть и становится короче, время, за которое его распарсит мозг — увеличивается в разы.
Правильнее второй, потому что, надеюсь, можно будет написать что-то, похожее:
a { color: var(maincolor); font:var(myvar01); border: var(myvar02); }
b { color: var(maincolor); font:var(myvar11); border: var(myvar12); }
c { color: var(maincolor); font:var(myvar21); border: var(myvar22); }
etc.
При этом осмысленно группируется набор стилей для отдельных элементов и появляется гибкость при изменении сходных параметров для этих элементов.
К тому же, что будет понятнее, некий абстрактный "white" который встречается в семи местах или mainBackGroundColor, встречающийся в тех же семи местах?
Программисты уже давно пользуются именованными константами и переменными, чего и всем остальным желают;).
a { color: var(maincolor); font:var(myvar01); border: var(myvar02); }
b { color: var(maincolor); font:var(myvar11); border: var(myvar12); }
c { color: var(maincolor); font:var(myvar21); border: var(myvar22); }
etc.
При этом осмысленно группируется набор стилей для отдельных элементов и появляется гибкость при изменении сходных параметров для этих элементов.
К тому же, что будет понятнее, некий абстрактный "white" который встречается в семи местах или mainBackGroundColor, встречающийся в тех же семи местах?
Программисты уже давно пользуются именованными константами и переменными, чего и всем остальным желают;).
а вот и нет:
a, b, c { color: white }
a { font: value; border: value}
b { font: value; border: value}
c { font: value; border: value}
Читайте CSS спеки...
a, b, c { color: white }
a { font: value; border: value}
b { font: value; border: value}
c { font: value; border: value}
Читайте CSS спеки...
Пример приведён только для примера - не стоит за него цепляться.
Если вам требуется описать большое количество элементов, у которых совпадают некоторые параметры, причём у разных элементов разные параметры, то .css-файл превратится в нечто неудобоваримое.
Согласен, ваша точка зрения имеет право на жизнь, т.к. заставляет группировать большее количество элементов в одном месте, таким образом ограничивая возможности css читаемостью самого .css-файла. Плюс к тому добавляет общность в дизайн различных элементов.
Если вам требуется описать большое количество элементов, у которых совпадают некоторые параметры, причём у разных элементов разные параметры, то .css-файл превратится в нечто неудобоваримое.
Согласен, ваша точка зрения имеет право на жизнь, т.к. заставляет группировать большее количество элементов в одном месте, таким образом ограничивая возможности css читаемостью самого .css-файла. Плюс к тому добавляет общность в дизайн различных элементов.
В таких случаях это тоже эффективно?
#myBlock0 .class1 .class2 .class3 DIV,
#myBlock1 .class2 .class3 P,
#myBlock2 .class5 .class6 .class7 { color }
#myBlock0 .class1 .class2 .class3 DIV { ... }
#myBlock1 .class2 .class3 P { ... }
#myBlock2 .class5 .class6 .class7 { ... }
?
а если все три правила описаны в разных файлах?
К тому же если вынести переменные в отдельный файл, то можно делать цветовые схемы, к примеру. То есть не переписывать весь стиль (копи-паст с подменой цвета), менять только переменные отвечающие за цвет.
#myBlock0 .class1 .class2 .class3 DIV,
#myBlock1 .class2 .class3 P,
#myBlock2 .class5 .class6 .class7 { color }
#myBlock0 .class1 .class2 .class3 DIV { ... }
#myBlock1 .class2 .class3 P { ... }
#myBlock2 .class5 .class6 .class7 { ... }
?
а если все три правила описаны в разных файлах?
К тому же если вынести переменные в отдельный файл, то можно делать цветовые схемы, к примеру. То есть не переписывать весь стиль (копи-паст с подменой цвета), менять только переменные отвечающие за цвет.
Я думаю что луше
a, b, c, d, e, f { color: var(myvar) }
;)
на старнице может быть 30 цветов
находясь на стрчоке 200 ты можешь вспомнить что твой цвет называеться purple shit и вставить его спокойно не листая выше и не тратив время на его поиск.
Было бы оень круто, если бы добавили селектор с перменными как в пхп:
$mycolor = #cccccc;
.obj_1 { color: $mycolor }
a, b, c, d, e, f { color: var(myvar) }
;)
на старнице может быть 30 цветов
находясь на стрчоке 200 ты можешь вспомнить что твой цвет называеться purple shit и вставить его спокойно не листая выше и не тратив время на его поиск.
Было бы оень круто, если бы добавили селектор с перменными как в пхп:
$mycolor = #cccccc;
.obj_1 { color: $mycolor }
цена не оправдывает средства! в переменных нет необходимости, во всяком случае я ещё не увидел дельного примера.
вы просто писсимист
у меня на сайте порядка 10 основных цветов, все они настраиваются, кроме этого существует порядка 30 цветовых схем, которые тоже настраиваются, и множество элементов имеют цвета основанные на этих настройках, и для меня, как для разработчика, внедрение переменных очень облегчило бы управление всем этим добром, а главное дальнейшую поддержку.
господи, зачем 10 раз менять??
Ctrl+F -> Replace
Ctrl+F -> Replace
простите, заминусовали потому что автозаменой никто не пользуется, и заменяете вручную? Вот это логика о_О
Да просто используя автозамену можно поменять один цвет на другой во всем проекте, даже там где не надо :) Согласитесь, неприкольно получится. Конешно и регекспы при замене использовать мона, но надо оно, если появится такой замечательный способ как переменные?
коли вам интересно, я поставил минус комменту т.к. считаю, что find&replace как средство для рефакторинга кода - это чудовищно
"заменятель подстрок в строке" - не знает про синтаксис и семантику языка программы и используют такое только в режиме предварительного просмотра каждой замены - это глупая трата времени, когда есть (будет) возможность использовать константы
разумеется, существуют такие find&replace которые aware of syntax & semantics, например, для C#, но это уже оффтопик
"заменятель подстрок в строке" - не знает про синтаксис и семантику языка программы и используют такое только в режиме предварительного просмотра каждой замены - это глупая трата времени, когда есть (будет) возможность использовать константы
разумеется, существуют такие find&replace которые aware of syntax & semantics, например, для C#, но это уже оффтопик
Если у вас несколько файлов со стилями - Ctrl+F вам не очень то поможет. Хотя конечно поможет, но проделать это придется для каждого файла. У меня например в проекте более 20 файлов стилей - конечно на продакшене они собираются в один - но на стадии разработки это все разные файлы, и внесение изменений (поменять везде цвет, к примеру) это большая головная боль.
Я ещё не виде в спеке слова Accepted! Твой пример можно реализовать и без переменных.
искать переменные по коду придется так же как и нужное значение. Группировка для того и существует, чтобы оптимизировать код. Читабельность обеспечивается комментариями.
На практике часто хотелось бы задать один цвет для фона, текста, рамок... Так, что простая группировка по цвету, это очень частный случай.
Переменным нет, константам да! 8)
Понимание необходимости переменных приходит с опытом. Это логично, удобно, гибко, лежит на поверхности (почему до этого хоть кто-то в рабочей группе CSS додумался только сейчас, уму непостижимо) и уж никак не безумно. ;-)
вот с таким применением переменных я согласна, это было бы заменой exсeption в первую очередь
И уж совсем здорово было бы, если бы их можно было использовать в выражениях
такое в CSS3 может быть будет возможно с помощью специальной функции calc
в вашем случае получится
min-height: calc(var(MainContainerMinHeight) - var(MainContainerPaddingTop) - var(MainContainerPaddingBottom));
"min-height: var(MainContainerMinHeight) - var(MainContainerPaddingTop) - var(MainContainerPaddingBottom)"
Это да, особенно если бы из %% можно было em или px вычитать.
Это да, особенно если бы из %% можно было em или px вычитать.
"в Aplle" - исправьте название Яббла
Эти трое впринципе "никто" и даже если w3c это оценит и приймет, то мы сможем воспользоваться этим без фиксов лет через 6-7
Эти трое впринципе "никто" и даже если w3c это оценит и приймет, то мы сможем воспользоваться этим без фиксов лет через 6-7
Тьфу ты, бред какой...
Такими темпами скоро все языки будут дублировать друг друга...
полноценные ЯП и так друг друга "дублируют" - они все эквивалентны машине Тьюринга
если CSS вдруг станет (а может, уже стал) Тьюринг-эквивалентным, то ничего страшного, думаю, не произойдет.. просто появится еще пара способовотстрелить себе ногу сделать одну и ту же фичу по-разному
это ведь не плохо само по себе, плохо когда это неправильно используют
если CSS вдруг станет (а может, уже стал) Тьюринг-эквивалентным, то ничего страшного, думаю, не произойдет.. просто появится еще пара способов
это ведь не плохо само по себе, плохо когда это неправильно используют
Вот вот... например анимацию и трансформацию ещё можно допустить так как в худшем случае они не будут отображены, елементы останутса на своих местах и с своими свойствами. Есле же броузер не будет потдерживать переменные вы рискуете остатвить свои свойства без значений... ИМХО полная ерунда!
+1
Почти слово в слово то, что хотел я написать. Я точно ещё слишком молод ля того, чтобы понять зачем всё это нужно.
Почти слово в слово то, что хотел я написать. Я точно ещё слишком молод ля того, чтобы понять зачем всё это нужно.
языки не затачивают под "программирование"
языки затачивают под задачи
пока круг задач довольно узок - такой язык называется Domain-Specific Language (aka DSL), сейчас CSS попадает под это определение
веб на месте не стоит, и задачи, которые решает стайлинг все усложняются - вместе с ними усложняется и язык, это нормально
языки затачивают под задачи
пока круг задач довольно узок - такой язык называется Domain-Specific Language (aka DSL), сейчас CSS попадает под это определение
веб на месте не стоит, и задачи, которые решает стайлинг все усложняются - вместе с ними усложняется и язык, это нормально
Зачем это всё в CSS?
Почему нельзя через JS?
Это же новые стандарты, поддержку которых везде (в ie) не гарантируют.
Почему нельзя через JS?
Это же новые стандарты, поддержку которых везде (в ie) не гарантируют.
Ну если уж совсем правильно, то это не стандарты а рекомендации. И само собой что их реализация не гарантируется производителями браузеров (вспомнить хотя бы пример, когда из-за разногласий во мнениях между W3C и производителями браузеров относительно XHTML2, последнии решили разрабатывать свой собственный стандарт HTML5).
А вот по поводу того, что перекладывать функции яваскриптов на CSS - это глупо, я с вами соглашусь.
Из предложенных нововвидений понравилась только идея с ротацией и масштабированием элементов. Анимация - это же прерогатива JS - зачем изобретать велосипед? В полезности использования переменных тоже чесно говоря сомневаюсь (лично мне и без них прекрасно живёться).
А вот по поводу того, что перекладывать функции яваскриптов на CSS - это глупо, я с вами соглашусь.
Из предложенных нововвидений понравилась только идея с ротацией и масштабированием элементов. Анимация - это же прерогатива JS - зачем изобретать велосипед? В полезности использования переменных тоже чесно говоря сомневаюсь (лично мне и без них прекрасно живёться).
потому что декларативность - лучше, чем императивность
JS достаточно гибок, чтобы сделать декларативно и в нем - но тогда не будет статических проверок такого кода на консистентность перед компиляцией и все ошибки вылезут уже при исполнении скрипта (это как статическая система типов vs. duck typing)
JS достаточно гибок, чтобы сделать декларативно и в нем - но тогда не будет статических проверок такого кода на консистентность перед компиляцией и все ошибки вылезут уже при исполнении скрипта (это как статическая система типов vs. duck typing)
Потому что анимация элемента на странице — это отображение, а не поведение.
Вот зачем в карму нагадили?!
Apple тиха атакуе галактеко?
По-моему бредятина это уже...Выходит нафиг нам флеши с сильверлайтами и яваскриптами...
По-моему бредятина это уже...Выходит нафиг нам флеши с сильверлайтами и яваскриптами...
Хорошая новость)
...клево, черт побери :))
Походу, ребята из W3C почитали книжку по WPF и то, что реализовала Microsoft теперь им не даёт покоя и они решили всё "слизать". Только вот ради WPF MS фактически с нуля WinForms переделала, а они хотят малой кровью натянуть всё это на старые стандарты. Идея, конечно, неплоха, но как программисту мне кажеться, что это всё довить ещё больше камней в огород кроссбраузерности.
WPF? WTF? Они прочитали книжку по SVG. А если быть точным, то один из них (Dean Jackson) один из создателей SVG.
Отличный перевод. Думаю Вам стоит почитать Пепелсбея, и Вы измените своё отношение к переменным. Это на самом деле отличнейшая штука! Скорей бы их добавили...
Именно в переменных я смысла тоже не вижу, а вот в строковых константах - вполне. Т.е. скорее даже просто аналог #define.
По-моему, ничего плохого не произойдет если из CSS сделать что-то типа, языка программирования, если конечно весь синтаксис не измениться. Ну подумаешь появятся у языка новые возможности, разве это плохо? Никто не заставляет ими пользоваться. Можно также продолжать писать JS+CSS. Да и вообще если с помощью CSS можно будет решить решить задачи которые решаются с помощью того же JS, то это будет просто волшебно. У многих, например, отпадет нужда учить и CSS и JS.
программирование - всегда гуд. думаю если кто-то из верстальщиков не осиливает кодинга, ничто не помешает им оставаться в CSS2 или не использовать новый функционал в CSS3. я, как программист, за переменные, за операторы и за возможность более тонкого управления и интерактивность. думаю все эффекты отображения (имею в виду динамические эффекты) должны отойти к CSS оставив JavaScript программирование функционала. думаю тогда функциональное структурирование страниц возрастёт, а стало быть изменение их станет проще и прозрачнее...
Sign up to leave a comment.
Новое в CSS 3: анимация, трансформация, переменные.