Сделайте простой интрумент на основе любого шаблонизатора. Я сделал когда-то себе банальный «молоток» на базе TT и perl и постоянно пользуюсь. Потом добавил строчку кода, что бы всё моё добро компилировалось перед запуском (либо при сохранении).
Плюсодин, как говорится обычно, однако saas удобнее с импортом тем, что при грамотном использовании, он будет выплевывать клиенту 1 цсс файл, который клиентский браузер закеширует.
всякие препроцессоры — эт, конечно, хорошо, но как отлаживать продукт их жизнедеятельности?
я себе сделал так: по умолчанию все цсс-ки собираются в один файл, жмутся, все дела, но в режиме отладки — все цсс-ки подключаются по отдельности, в результате чего в отладчике на против каждого правила пишется имя файла и номер строки соответствующие действительности в исходниках.
>но как отлаживать продукт их жизнедеятельности?
Наверное так же как и любой другой продукт препроцессора/компилятора/интерпретатора.
HTML сейчас в чистом виде можно только в исходниках страницы увидеть — все пропускается через шаблонизаторы да еще и в несколько проходов.
ага, мало гемора с хтмл, так давайте ещё и цсс с яваскриптом сделаем также >_<
вообще говоря, проблему бэктрейса хтмл можно было бы решить средстами шаблонизатора, который бы добавлял спец-аттрибут, но… нормальных шаблонизаторов вообще кот наплакал, а что б ещё и такое счастье…
> мало гемора с хтмл
Ну а как без шаблонизаторов? Никак. 2009 год все-таки. Чистую статику сейчас не встретить.
Хотя для CSS никакого геморроя не вижу. Применение подобных средств только повышает читаемость кода и сокращает его объем. Соответственно и ошибок должно быть меньше. При условии что препроцессор не начнет вносить свои ошибки.
Переменные в CSS напрашивались сами собой. Но их и в CSS3 нет. Хотя WebKit их давно ввел в оборот disruptive-innovations.com/zoo/cssvariables/
Каскадирование в стиле HSS/SASS- тоже существенно облегчает читабельность кода, но хрен дождешься от идиотов из w3c.
необходимость шаблонизации хтмл обоснована необходимостью вставки динамических данных. для цсс такой необходимости нет.
от каскадирования больше проблем чем пользы: гигантские отступы, жёсткая привязка к селектору родителя, «разбрасывание» частей селектора по разным концам файла.
необходимость того или иного инструментария вытекает из сложности задачи.
За последний год сообщения о cssvariables/HSS/SASS слишком часто стали появляться. Через некоторое время количество явно перерастет в качество.
Хотя может получится как с шаблонизаторами — вырастет зоопарк самоделок + каждый броузер обзаведется своим собственным прибабахом.
про арифметику интересно, а вот «константы» и «Абстрактные классы» — так это можно решить средствами CSS подсовывая в HTML в один параметр class несколько разных из CSS. Мне кажеться разницы от этого никакой, что в самом файле стилей приплюсовать, что в HTML написать 2 класса подряд… К примеру:
CSS:
.main_border {
border: 10px solid #ff0000;
}
.main_color {
color: #00ff00;
}
HTML:
<div class="main_border main_color">bla bla</div>
соответственно этим мы решаем первые 2 пункта…
поправьте если я не прав
выше уже говорили об этом… я соглашусь что можно, но стоит ли? это образует огромное количество классов как в HTML так и в CSS, что в принципе имхо не есть хорошо, дык от них потом еще и в глазаx рябит))) а тут на выходе получится одна css в которой минимум классов и все «абстрактные классы» и «константы» заменены на параметры с определенными значениями.
почему это огромное кол-во? ровно столько же.
можно в CSS это вынести в отдельнй файл (только для «абстрактных» классов)…
в принципе велосипед тот-же только понавороченей :)
на самом деле я только за, а то CSS всетаки убогий и полного наследования ой как не хватает да и много чего не хватает.
любой подобный велосипед требует серверного времени и внимания = потеря в производительности. для небольших проектов, которые никогда не вырастут — может и интересно, для интересных проектов — не стоит овчинка выделенки
безусловно в использовании есть свои нюансы. Но никто ведь не говорит что этим нужно пользоваться а про css забыть… ни в коем разе.
Это пища для размышлений для вас и для меня.
Прописывая классы, описывающие отображение в HTML, мы нарушаем семантичность и отделение содержание от представления.
Класс по-хорошему должен отражать, чем является элемент, а не как его показывать.
гм… а разве не *имя тэга* должно отражать /чем/ является элемент? ;-)
классы для того и были введены, чтобы можно было указывать _как_ отображать элемент независимо от его семантики.
Это уже идеальный случай. В XML-то пожалуйста, а вот в том html, на котором приходится писать, возможностей, кроссбраузерности и набора стандартных тегов не всегда хватает. Да и продвинутые селекторы типа «прямой потомок» или выборка по значению свойства не работают в IE6, а их можно заменить только классами. Это раз.
Во-вторых, да, имя тега показывает что это за элемент, а класс его классифицирует. Но не по отображению, а по назначению. Вот эта ссылка внешняя, вон тот пункт меню активный, вон тот комментарий непрочитанный (а не «синенький»), вон тот div.item — контейнер для карточки чего-либо. Так как он в списке товаров, допустим, #tovars, то его показать так-то, а h4 в нём так-то, а ссылочку в нём вправо прибить, а p.short-description показать меленьким, а img прибить влево и бордюром обвести. А если совершенно такой же div.item положить в другой #контейнер, допустим, боковую панель спецпредложений, то правила могут быть другие. А серверу тем временем один и тот же шаблон в совершенно разных задачах.
2. нет, классы не для этого. для этого предназначены аттрибуты. checked=«checked», а не class=«checked» другое дело, что ие6 вынуждает использовать для этого классы…
3. одна вёрстка для любых случаев — это либо утопия, либо жестокое самоограничение.
1. И часто ли вы видели вёрстку с изменённым DTD?
2. Вот именно, что ие6, я это и пишу. Плюс свои аттрибуты нам опять же придумывать так просто не дают.
3. Совсем нет. Очень удобно порой скопипастить HTML из одного места в другое и лишь переписать css.
ты предложил валидные цсс-хаки…
при этом они не так удобны, как например _height: 1%
к тому же оперу нужно точнее хачить, ибо 9.0, 9.1, 9.2 и 9.5 имеют свои, уникальные баги…
ну цсс как бы формируется на лету и поэтому он, по идее, будет перезатираться, а использовать условные коментарие я не очень привык, ибо хак удобней писать в контексте селектора, а не где то там на странице сайта, или в отдельной цсске.
Не понимаю, честно говоря, зачем было придумывать синтаксис с нуля. Ведь есть привычка ставить двоеточие после аттрибута, а не до, и будут постоянно возникать противоречия. По моему неудобно. А у кого то не только привычка, но и сниппеты, система подстветки синтаксиса — и все это конфликтует с новым синтаксисом.
По хорошему — надо было расширять css а не заменять. Ну и синтаксис типа !a = value мне тоже не нравится, так как лишние значки вносят доп. сложность (вспомните Перл с его зуболомными сокращениями к примеру). Нигде так присваивание не делается (ну еслитолько в каком нибудь малоизвестном языке) и это плохо. Например, в php для переменных используют $ — почему бы не использвоть привычный символ?
Если быть точным, изначально SASS и писался для таких тривиальных вещей как склейка CSS файлов, для этого требовался совместимый синтаксис, поэтому в редакции SCSS синтаксис с импортами в точности соответствует CSS. Это даже не заимствованая возможность, а целенаправленно созданная.
Вкусный CSS: Sass + Compass