Расширение языка HTML

[s0rr0w]

Безусловно 10px, т.к. это правило применяется последним к классу c1.

А кто сказал, что свойства присваиваются по значению? А если по ссылке? Тогда порядок следования деклараций переменных имеет значение. И вот тут начинается форменный трындец.

Давайте рассмотрим следующий пример

$h {
value: 10px;
}
.c1 { height: $h }
$h {
value: 20px;
}

Чему равна высота блока?

[psywalker]

Безусловно 10px, т.к. это правило применяется последним к классу c1.

А кто сказал, что свойства присваиваются по значению? А если по ссылке? Тогда порядок следования деклараций переменных имеет значение. И вот тут начинается форменный трындец.

Давайте рассмотрим следующий пример

$h {
value: 10px;
}
.c1 { height: $h }
$h {
value: 20px;
}

Чему равна высота блока?

А нафига такое делать? Это же глупо и разраб сам себе злобный буратино. Константы ты в JS где врубаешь? В конце или в начале кода?

[s0rr0w]

А нафига такое делать? Это же глупо и разраб сам себе злобный буратино. Константы ты в JS где врубаешь? В конце или в начале кода?

Когда у тебя в проекте не один CSS файл, а их сотня, то вопрос, нафига так делать, не стоИт. Я могу банально перекрыть значение существующей переменной.

Мало того, в этом поведении есть смысл, я могу сделать базовые настройки и потом перекрывать их в скинах.

[psywalker]

А нафига такое делать? Это же глупо и разраб сам себе злобный буратино. Константы ты в JS где врубаешь? В конце или в начале кода?

Когда у тебя в проекте не один CSS файл, а их сотня, то вопрос, нафига так делать, не стоИт. Я могу банально перекрыть значение существующей переменной.

Когда у тебя в проекте не один CSS файл, CSS reset ты всё равно подрубаешь первым, так же и здесь. Сделай отдельную таблицу констант и подключай её первой. Ты высасываешь проблему из пальца, имхо.

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

[s0rr0w]

Когда у тебя в проекте не один CSS файл, CSS reset ты всё равно подрубаешь первым, так же и здесь.

У меня нет css-ресета в проектах.

Сделай отдельную таблицу констант и подключай её первой. Ты высасываешь проблему из пальца, имхо.

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

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

http://www.csszengarden.com вот пример хорошо скинящегося кода.

[psywalker]

s0rr0w,

У меня нет css-ресета в проектах.

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

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

Вообще-то, правильно делать именно так. Есть отдельная таблица стилей, допустим тех же классов. Классы разбрасываются по всему сайту. Если нужно поменять визуальный вид элемента, модифицируешь этот CSS-файл и идёшь пить пиво.

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

[smevok239]

А в чем проблема меняющиеся параметры(параметры скрина) вынести в отдельный файл, и подключать нужный?

[s0rr0w]

Вообще-то, правильно делать именно так. Есть отдельная таблица стилей, допустим тех же классов. Классы разбрасываются по всему сайту. Если нужно поменять визуальный вид элемента, модифицируешь этот CSS-файл и идёшь пить пиво.

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

А кто сказал, что твой способ именно самый правильный? Сколько людей, столько мнений. Не бывает 100% правильных решений, бывает только наиболее подходящие в это время и в этом месте.

Если у тебя в проекте используется слабосвязанная архитектура, в которой каждый модуль имеет свои собственные стили (БЭМ, кстати, результат построения слабосвязанной архитектуры), то вынос переменных в один файл приведет к тотальной проблеме неконсистентности стилей.

А в чем проблема меняющиеся параметры(параметры скрина) вынести в отдельный файл, и подключать нужный?

В том, что каждый скин обязан хранить полный набор всех переменных. При модификации базового скина придется модифицировать все остальные. Пока это делает один человек, проблем нет, но когда это проект с большим количеством независимых разработчиков, то они будут пускать неведомое количество лучей ненависти в адрес того, кто придумал переменные не давать переопределять.

[psywalker]

s0rr0w,

А кто сказал, что твой способ именно самый правильный?

Потому что в данной ситуации это самый разумный и логичный способ. Изначально уже правильные дядьки так делали в JS-е Переменные и константы всегда назначались ДО цели, а НЕ после. Иначе ты делаешь что-то не так, либо точно знаешь, что ты делаешь.

Если у тебя в проекте используется слабосвязанная архитектура, в которой каждый модуль имеет свои собственные стили (БЭМ, кстати, результат построения слабосвязанной архитектуры), то вынос переменных в один файл приведет к тотальной проблеме неконсистентности стилей.

Нуу БЭМ - это вообще отдельная методология. Если Яндекс захочет внедрить переменные, то они найдут просто правильный способ их использования в БЭМ. А что касается обычных смертных, то они и так миксуют всякую муть кто во что горазд) Поэтому здесь и переменным найдётся местечко при правильном использовании)

В том, что каждый скин обязан хранить полный набор всех переменных. При модификации базового скина придется модифицировать все остальные. Пока это делает один человек, проблем нет, но когда это проект с большим количеством независимых разработчиков, то они будут пускать неведомое количество лучей ненависти в адрес того, кто придумал переменные не давать переопределять.

Значит берёшь и меняешь свои стили вместе со стилями переменных на свои и не пукаешь.

[MiksIr]

<!--# set var="borderColor" value="#000000" -->
<!--# set var="backgroundColor" value="#FFFFFF" -->
...
.block {
  border-color: <!--# echo var="borderColor" -->;
  background: <!--# echo var="backgroundColor" -->;
}

:rofl:

[s0rr0w]

Потому что в данной ситуации это самый разумный и логичный способ. Изначально уже правильные дядьки так делали в JS-е Переменные и константы всегда назначались ДО цели, а НЕ после. Иначе ты делаешь что-то не так, либо точно знаешь, что ты делаешь.

Хочу тебе напомнить, что в коде

foo();
function foo(){ alert('Ok'); }

алерт выведет таки Ok. Это правильные дядьки сделали в JS-e

Значит берёшь и меняешь свои стили вместе со стилями переменных на свои и не пукаешь.

Тогда мы снова возвращаемся к проблеме перекрытия переменных?

[psywalker]

s0rr0w,

Хочу тебе напомнить, что в коде

foo();

function foo(){ alert('Ok'); }

алерт выведет таки Ok. Это правильные дядьки сделали в JS-e

Хочу тебе напомнить, что в коде

foo();
var foo = function(){ alert('Облом'); }

алерт не выведет абсолютно ничего. Это правильные дядьки сделали в JS-e, потому что они сказали, что переменные должны идти перед вызовом

Тогда мы снова возвращаемся к проблеме перекрытия переменных?

Вот такой код априори уже выглядит по нубски. Правильный разраб такого никогда не сделает. Поэтому если ты собираешься именно так юзать переменные, то тогда тебе лучше этого не делать вообще.

$h {
value: 10px;
}
.c1 { height: $h }
$h {
value: 20px;
}

[s0rr0w]

Вот такой код априори уже выглядит по нубски. Правильный разраб такого никогда не сделает. Поэтому если ты собираешься именно так юзать переменные, то тогда тебе лучше этого не делать вообще.

file main.css

$h {
value: 10px;
}
.c1 { height: $h }

file myModule_1.css

$h {
value: 20px;
}

<link rel="stylesheet" href="main.css">
<link rel="stylesheet" href="myModule_1.css">

По-нубски говоришь?

Правильный разраб как раз так и сделает. Неправильный разраб считает, что на странице может быть только один подключаемый CSS файл.

Хотя нет, вру, правильный разраб склеит два файла в один на стороне сервера. И мы получаем в итоге мой первоначальный пример

[Catherine]

Секунду, леди. Вам не предлагают переносить программинг в CSS полностью. Задача минимум - это перенести только те части, которые часто требуются для обычной вёрстки, но при этом находятся за рамками CSS. Чуть анимации и переменных не заменят весь программинг, согласна?

Зачем мне чуть анимации и чуть-чуть переменных, если можно пойти другим путем и использовать всю мощь, как выразились "программинга"? Зато можно будет однозначно сказать, что за что отвечает, а не "допиливать" недореализованное СSS-решение программными способами под собственные нужды при малейшем изменении ТЗ. А искать косяки в таком случае - очень увлекательное и позитивное занятие.

Можешь озвучить список необходимых для обычной верстки недостающих частей? Насколько он совпадает с запланированными новшествами?

Как верно замечено, "только те части, которые часто требуются для обычной вёрстки, но при этом находятся за рамками CSS". Давайте исходить из этого.

Имхо, если браузеры в итоге придёт к беспрефиксной записи (а это будет рано или поздно), то, во-первых, правил уже будет меньше, а во-вторых, сами они по себе не такие уж сложные. Это как сравнивать jQ и JS, где в первом случае даже дизайнер, не знающий JS может смастерить многосложные вещи, вызвав всего пару функций.

И дизайнер, и горе-верстальщик может смастерить несложные вещи, но никак не "многосложные" - рухнут, как карточный домик от малейшего дуновения по-незнанию самой технологии. А если и не рухнут - легче от этого все-равно не становится, и почему-то все-равно нужны специалисты в областях jQ и js

Правил будет меньше - отлично, следовательно, будет выше управляемость и надежность системы. Я за принцип "разделяй и властвуй", а не "навороти и сломай всем мозг неподконтрольными наворотами".

[psywalker]

s0rr0w,

По-нубски говоришь?

Правильный разраб как раз так и сделает.

Правильный разраб не станет так делать, потому что он понимает, что это игра с огнём.

Неправильный разраб считает, что на странице может быть только один подключаемый CSS файл.

Правильно, поэтому я и предлагаю делать отдельную таблицу для переменных.

Хотя нет, вру, правильный разраб склеит два файла в один на стороне сервера.

Надеюсь правильно склеит-то?

[psywalker]

Catherine,

Зачем мне чуть анимации и чуть-чуть переменных, если можно пойти другим путем и использовать всю мощь, как выразились "программинга"?

А зачем тебе вся мощь + заморочка другом языке, если тебе нужно всего лишь сделать константы?

Зато можно будет однозначно сказать, что за что отвечает

Чистый код всегда тебе об этом скажет.

а не "допиливать" недореализованное СSS-решение программными способами под собственные нужды при малейшем изменении ТЗ.

Если тебе нужно что-то допиливать, значит ты выбрала неправильную технологию.

А искать косяки в таком случае - очень увлекательное и позитивное занятие.

Хм... тогда беру слова обратно))

Можешь озвучить список необходимых для обычной верстки недостающих частей? Насколько он совпадает с запланированными новшествами?

Как верно замечено, "только те части, которые часто требуются для обычной вёрстки, но при этом находятся за рамками CSS". Давайте исходить из этого.

Могу конечно) Плавные переходы при ховерах, выпадающие менюхи, медиа-запросы ща очень актуальны, детка

И дизайнер, и горе-верстальщик может смастерить несложные вещи, но никак не "многосложные" - рухнут, как карточный домик от малейшего дуновения по-незнанию самой технологии. А если и не рухнут - легче от этого все-равно не становится, и почему-то все-равно нужны специалисты в областях jQ и js

Пример:

$('.div1').romoveClass('class')

А теперь представь себе, что ты дизайнер и сделай тоже самое на нативном JS.

Правил будет меньше - отлично, следовательно, будет выше управляемость и надежность системы. Я за принцип "разделяй и властвуй", а не "навороти и сломай всем мозг неподконтрольными наворотами".

Последнее относится ты знаешь к кому

[Catherine]

Пример:

$('.div1').romoveClass('class')

А теперь представь себе, что ты дизайнер и сделай тоже самое на нативном JS.

А теперь представь, что ты дизайнер и не можешь понять, почему это не работает

[psywalker]

Пример:

$('.div1').romoveClass('class')

А теперь представь себе, что ты дизайнер и сделай тоже самое на нативном JS.

А теперь представь, что ты дизайнер и не можешь понять, почему это не работает

Жиквери и придумано для таких вот непонятливых и ленивых дизингеров. Поэтому если они не способны понять и это, тогда им вообще не следует заходить дальше дизайна

[Great Rash]

А теперь представь себе, что ты дизайнер и сделай тоже самое на нативном JS.

На нативном JS тоже не сильно много писать:

element.className = element.className.split('class').join('');

Дизайнер должен осилить при желании. Хотя не дело дизайнера писать скрипты.

Ты не работал над большими проектами в команде, допустим из 5 человек?

[s0rr0w]

Пример:

$('.div1').romoveClass('class')

А теперь представь себе, что ты дизайнер и сделай тоже самое на нативном JS.

romove?

Да, дизайнер будет долго думать, почему это не будет работать...

[psywalker]

Great Rash,

На нативном JS тоже не сильно много писать:

element.className = element.className.split('class').join('');

Хаа)) Какие мы наивные)

Ты забыл всего пару условий.

1. Нам нужны элементы с классом '.div1'.

2. У нашего элемента множественные классы.

Ты сможешь одной строкой докопаться до таких элементов и поменять им именно нужный класс? Не забываем про IE7

Дизайнер должен осилить при желании. Хотя не дело дизайнера писать скрипты.

В том-то и дело, что домохозяйки и дизайнеры не обязаны изучать JS, а жиквери нет проблем, для таких и создан)

Ты не работал над большими проектами в команде, допустим из 5 человек?

Нет, но от этого правильные принципы вёрстки у меня не поменяются.

Пример:

$('.div1').romoveClass('class')

А теперь представь себе, что ты дизайнер и сделай тоже самое на нативном JS.

romove?

Да, дизайнер будет долго думать, почему это не будет работать...

Хах) Защитано

[s0rr0w]

Нет, но от этого правильные принципы вёрстки у меня не поменяются.

у тебя каждый год новые, все более правильные принципы верстки. Не поменяются, говоришь?

[psywalker]

Нет, но от этого правильные принципы вёрстки у меня не поменяются.

у тебя каждый год новые, все более правильные принципы верстки. Не поменяются, говоришь?

Я имею ввиду, что, если я писал ресет вверху своих стилей, значит я и буду его там писать, и не важно сколько человек со мной в команде. В противном случае я просто откажусь от него.

[Great Rash]

Я имею ввиду, что, если я писал ресет вверху своих стилей, значит я и буду его там писать, и не важно сколько человек со мной в команде. В противном случае я просто откажусь от него.

Ты не понял. Вот представь ситуацию: есть проект А, он развивается уже 3 года.

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

Через месяц пришел я, посмотрел на твой код и решил его переколбасить так как мне нравится, потому что я считаю, что ресет - это плохо.

Через год пришел s0rr0w, посмотрел на наше с тобой творение и ужаснулся. Но переписывать все с нуля уже дорого, потому что делать надо срочно и прибыль от проекта нужна прямо сейчас. Поэтому ему дешевле понаписать костылей, чем переписывать правильно.

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

Вот примерно так проекты и превращаются в говнокод.

Поэтому то что ты говоришь (объявления переменных только вначале и т.п.) в корне неправильно. Проект изначально должен быть устроен так, чтобы кто угодно мог куда угодно что-то написать, не разбираясь как устроены остальные части.

[psywalker]

Я имею ввиду, что, если я писал ресет вверху своих стилей, значит я и буду его там писать, и не важно сколько человек со мной в команде. В противном случае я просто откажусь от него.

Ты не понял. Вот представь ситуацию: есть проект А, он развивается уже 3 года.

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

Через месяц пришел я, посмотрел на твой код и решил его переколбасить так как мне нравится, потому что я считаю, что ресет - это плохо.

Через год пришел s0rr0w, посмотрел на наше с тобой творение и ужаснулся. Но переписывать все с нуля уже дорого, потому что делать надо срочно и прибыль от проекта нужна прямо сейчас. Поэтому ему дешевле понаписать костылей, чем переписывать правильно.

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

Вот примерно так проекты и превращаются в говнокод.

Поэтому то что ты говоришь (объявления переменных только вначале и т.п.) в корне неправильно. Проект изначально должен быть устроен так, чтобы кто угодно мог куда угодно что-то написать, не разбираясь как устроены остальные части.

Ты ресетом пользуешься на работе?