Comments 78
Mixins != абстрактные классы.
А вообще интересно, как в CSS реализовать какую-нибудь абстракцию… А то уже запарило одни и те же фиксы/layout'ы писать по многу раз.
А вообще интересно, как в CSS реализовать какую-нибудь абстракцию… А то уже запарило одни и те же фиксы/layout'ы писать по многу раз.
на некотрый своих проектах использую php в css для чего просто обратчику php подсовываю расширение css
Сделайте простой интрумент на основе любого шаблонизатора. Я сделал когда-то себе банальный «молоток» на базе TT и perl и постоянно пользуюсь. Потом добавил строчку кода, что бы всё моё добро компилировалось перед запуском (либо при сохранении).
хитро)
Плюсодин, как говорится обычно, однако saas удобнее с импортом тем, что при грамотном использовании, он будет выплевывать клиенту 1 цсс файл, который клиентский браузер закеширует.
Кстати, и подобие Mixins в CSS тоже есть, только в другом ключе: <element class=«class1 class2 ...» >
всякие препроцессоры — эт, конечно, хорошо, но как отлаживать продукт их жизнедеятельности?
я себе сделал так: по умолчанию все цсс-ки собираются в один файл, жмутся, все дела, но в режиме отладки — все цсс-ки подключаются по отдельности, в результате чего в отладчике на против каждого правила пишется имя файла и номер строки соответствующие действительности в исходниках.
я себе сделал так: по умолчанию все цсс-ки собираются в один файл, жмутся, все дела, но в режиме отладки — все цсс-ки подключаются по отдельности, в результате чего в отладчике на против каждого правила пишется имя файла и номер строки соответствующие действительности в исходниках.
>но как отлаживать продукт их жизнедеятельности?
Наверное так же как и любой другой продукт препроцессора/компилятора/интерпретатора.
HTML сейчас в чистом виде можно только в исходниках страницы увидеть — все пропускается через шаблонизаторы да еще и в несколько проходов.
Наверное так же как и любой другой продукт препроцессора/компилятора/интерпретатора.
HTML сейчас в чистом виде можно только в исходниках страницы увидеть — все пропускается через шаблонизаторы да еще и в несколько проходов.
ага, мало гемора с хтмл, так давайте ещё и цсс с яваскриптом сделаем также >_<
вообще говоря, проблему бэктрейса хтмл можно было бы решить средстами шаблонизатора, который бы добавлял спец-аттрибут, но… нормальных шаблонизаторов вообще кот наплакал, а что б ещё и такое счастье…
вообще говоря, проблему бэктрейса хтмл можно было бы решить средстами шаблонизатора, который бы добавлял спец-аттрибут, но… нормальных шаблонизаторов вообще кот наплакал, а что б ещё и такое счастье…
> мало гемора с хтмл
Ну а как без шаблонизаторов? Никак. 2009 год все-таки. Чистую статику сейчас не встретить.
Хотя для CSS никакого геморроя не вижу. Применение подобных средств только повышает читаемость кода и сокращает его объем. Соответственно и ошибок должно быть меньше. При условии что препроцессор не начнет вносить свои ошибки.
Переменные в CSS напрашивались сами собой. Но их и в CSS3 нет. Хотя WebKit их давно ввел в оборот disruptive-innovations.com/zoo/cssvariables/
Каскадирование в стиле HSS/SASS- тоже существенно облегчает читабельность кода, но хрен дождешься от идиотов из w3c.
Ну а как без шаблонизаторов? Никак. 2009 год все-таки. Чистую статику сейчас не встретить.
Хотя для CSS никакого геморроя не вижу. Применение подобных средств только повышает читаемость кода и сокращает его объем. Соответственно и ошибок должно быть меньше. При условии что препроцессор не начнет вносить свои ошибки.
Переменные в CSS напрашивались сами собой. Но их и в CSS3 нет. Хотя WebKit их давно ввел в оборот disruptive-innovations.com/zoo/cssvariables/
Каскадирование в стиле HSS/SASS- тоже существенно облегчает читабельность кода, но хрен дождешься от идиотов из w3c.
необходимость шаблонизации хтмл обоснована необходимостью вставки динамических данных. для цсс такой необходимости нет.
от каскадирования больше проблем чем пользы: гигантские отступы, жёсткая привязка к селектору родителя, «разбрасывание» частей селектора по разным концам файла.
от каскадирования больше проблем чем пользы: гигантские отступы, жёсткая привязка к селектору родителя, «разбрасывание» частей селектора по разным концам файла.
необходимость того или иного инструментария вытекает из сложности задачи.
За последний год сообщения о cssvariables/HSS/SASS слишком часто стали появляться. Через некоторое время количество явно перерастет в качество.
Хотя может получится как с шаблонизаторами — вырастет зоопарк самоделок + каждый броузер обзаведется своим собственным прибабахом.
За последний год сообщения о 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 пункта…
поправьте если я не прав
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 в которой минимум классов и все «абстрактные классы» и «константы» заменены на параметры с определенными значениями.
вот вот хотел сказать что вы привели лишь подобие mixins, а констант что то не увидел. ну да ладно в прочем. обсуждаем.
почему это огромное кол-во? ровно столько же.
можно в CSS это вынести в отдельнй файл (только для «абстрактных» классов)…
в принципе велосипед тот-же только понавороченей :)
на самом деле я только за, а то CSS всетаки убогий и полного наследования ой как не хватает да и много чего не хватает.
можно в CSS это вынести в отдельнй файл (только для «абстрактных» классов)…
в принципе велосипед тот-же только понавороченей :)
на самом деле я только за, а то CSS всетаки убогий и полного наследования ой как не хватает да и много чего не хватает.
во первых лишние классы в html.
и как я уже сказал в итоговой css абстрактные классы будут заменены на присвоенные им параметры и значения.
пс: может велосипед, но велосипеды тоже не все одинаковые.
и как я уже сказал в итоговой css абстрактные классы будут заменены на присвоенные им параметры и значения.
пс: может велосипед, но велосипеды тоже не все одинаковые.
любой подобный велосипед требует серверного времени и внимания = потеря в производительности. для небольших проектов, которые никогда не вырастут — может и интересно, для интересных проектов — не стоит овчинка выделенки
Прописывая классы, описывающие отображение в HTML, мы нарушаем семантичность и отделение содержание от представления.
Класс по-хорошему должен отражать, чем является элемент, а не как его показывать.
Класс по-хорошему должен отражать, чем является элемент, а не как его показывать.
гм… а разве не *имя тэга* должно отражать /чем/ является элемент? ;-)
классы для того и были введены, чтобы можно было указывать _как_ отображать элемент независимо от его семантики.
классы для того и были введены, чтобы можно было указывать _как_ отображать элемент независимо от его семантики.
Это уже идеальный случай. В XML-то пожалуйста, а вот в том html, на котором приходится писать, возможностей, кроссбраузерности и набора стандартных тегов не всегда хватает. Да и продвинутые селекторы типа «прямой потомок» или выборка по значению свойства не работают в IE6, а их можно заменить только классами. Это раз.
Во-вторых, да, имя тега показывает что это за элемент, а класс его классифицирует. Но не по отображению, а по назначению. Вот эта ссылка внешняя, вон тот пункт меню активный, вон тот комментарий непрочитанный (а не «синенький»), вон тот div.item — контейнер для карточки чего-либо. Так как он в списке товаров, допустим, #tovars, то его показать так-то, а h4 в нём так-то, а ссылочку в нём вправо прибить, а p.short-description показать меленьким, а img прибить влево и бордюром обвести. А если совершенно такой же div.item положить в другой #контейнер, допустим, боковую панель спецпредложений, то правила могут быть другие. А серверу тем временем один и тот же шаблон в совершенно разных задачах.
Во-вторых, да, имя тега показывает что это за элемент, а класс его классифицирует. Но не по отображению, а по назначению. Вот эта ссылка внешняя, вон тот пункт меню активный, вон тот комментарий непрочитанный (а не «синенький»), вон тот div.item — контейнер для карточки чего-либо. Так как он в списке товаров, допустим, #tovars, то его показать так-то, а h4 в нём так-то, а ссылочку в нём вправо прибить, а p.short-description показать меленьким, а img прибить влево и бордюром обвести. А если совершенно такой же div.item положить в другой #контейнер, допустим, боковую панель спецпредложений, то правила могут быть другие. А серверу тем временем один и тот же шаблон в совершенно разных задачах.
1. xhtml как бэ не вчера появился…
2. нет, классы не для этого. для этого предназначены аттрибуты. checked=«checked», а не class=«checked» другое дело, что ие6 вынуждает использовать для этого классы…
3. одна вёрстка для любых случаев — это либо утопия, либо жестокое самоограничение.
2. нет, классы не для этого. для этого предназначены аттрибуты. checked=«checked», а не class=«checked» другое дело, что ие6 вынуждает использовать для этого классы…
3. одна вёрстка для любых случаев — это либо утопия, либо жестокое самоограничение.
все конечно классно, а как писать там фиксы для браузеров? например только для ие, чонить в стиле _height: 1%
Там можно так?
Там можно так?
а чем вас не устраивает?
блин, хабр скушал:( Я имел ввиду такую конструкцию: !--[if IE]> ![endif]-->
когда это заработает для оперы — я тя расцелую XD
а если серьёзно — я очень не люблю, когда правила для одного класса раскиданны по десяти файлам…
а если серьёзно — я очень не люблю, когда правила для одного класса раскиданны по десяти файлам…
Ну в основном у всех проблем с ИЕ :) ну на счет раскиданности соглашусь:)
www.webdevout.net/css-hacks#in_css-selectors
Есть цсс-хаки, прекрасно проходящие валидацию, и позволяющие довольно точно таргетнуть браузер.
Есть цсс-хаки, прекрасно проходящие валидацию, и позволяющие довольно точно таргетнуть браузер.
можно сделать отдельный css для ie и импортировать в нее основную css, как делает blueprint например… ну или дописать хак в готовую css…
ой ) кстати _height: 1% легко делаееца
:_height: 1%
:-)
:_height: 1%
:-)
HSS в первой версии мне кажется значительно вкуснее.
PS в гугле не просто найти ncannasse.fr/projects/hss
PS в гугле не просто найти ncannasse.fr/projects/hss
посмотрим))
расскажете об его ингредиентах и рецепте приготовления?
в принципе по ссылке все написано.
пока еще это просто утилита-транслятор из HSS в CSS, т.е. на входе задаем hss файл, а на выходе получаем css.
В отличии от CSS в HSS есть:
— переменные;
— блоки переменных;
— вложенные блоки;
В процессе трансляции проверяет синтаксис.
Для работы требуется neko (http://nekovm.org) и как следствие кросс-платформенная штуковина.
пока еще это просто утилита-транслятор из HSS в CSS, т.е. на входе задаем hss файл, а на выходе получаем css.
В отличии от CSS в HSS есть:
— переменные;
— блоки переменных;
— вложенные блоки;
В процессе трансляции проверяет синтаксис.
Для работы требуется neko (http://nekovm.org) и как следствие кросс-платформенная штуковина.
До сих пор не понимает некоторые css свойства, а значит отказывается «компилировать» :(
#header
background: #ccc
border= !width "solid" #777
Мне одного взгляда на такой синтаксис хватило, чтоб понять, что автор sass не сильно парился об интуитивности языка.
Использовать не хочется…
Никому здесь не кажется, что можно было бы и поднапрячься и сделать унифицированный синтаксис. Вот такой:
#header
background: #ccc
border: !width solid #777
Синтаксис уродливый.
у sass?)))))
как правило такие резкие высказывания надо хотя бы прокомментировать.
Код:
.page-title
+large-text
:padding 4px
:margin
:top 10px
Не понимаю, честно говоря, зачем было придумывать синтаксис с нуля. Ведь есть привычка ставить двоеточие после аттрибута, а не до, и будут постоянно возникать противоречия. По моему неудобно. А у кого то не только привычка, но и сниппеты, система подстветки синтаксиса — и все это конфликтует с новым синтаксисом.
По хорошему — надо было расширять css а не заменять. Ну и синтаксис типа !a = value мне тоже не нравится, так как лишние значки вносят доп. сложность (вспомните Перл с его зуболомными сокращениями к примеру). Нигде так присваивание не делается (ну еслитолько в каком нибудь малоизвестном языке) и это плохо. Например, в php для переменных используют $ — почему бы не использвоть привычный символ?
.page-title
+large-text
:padding 4px
:margin
:top 10px
Не понимаю, честно говоря, зачем было придумывать синтаксис с нуля. Ведь есть привычка ставить двоеточие после аттрибута, а не до, и будут постоянно возникать противоречия. По моему неудобно. А у кого то не только привычка, но и сниппеты, система подстветки синтаксиса — и все это конфликтует с новым синтаксисом.
По хорошему — надо было расширять css а не заменять. Ну и синтаксис типа !a = value мне тоже не нравится, так как лишние значки вносят доп. сложность (вспомните Перл с его зуболомными сокращениями к примеру). Нигде так присваивание не делается (ну еслитолько в каком нибудь малоизвестном языке) и это плохо. Например, в php для переменных используют $ — почему бы не использвоть привычный символ?
А редакторы под это дело есть? С подсветкой синтаксиса, автокомплитом и прочими радостями…
Просто развращенный удобными средами разработки, облегчающими написание кода, уже не хочу возвращаться к блокнот-стайл.
А к хамлу я давно присматриваюсь, мне он кажется весьма удобным.
Просто развращенный удобными средами разработки, облегчающими написание кода, уже не хочу возвращаться к блокнот-стайл.
А к хамлу я давно присматриваюсь, мне он кажется весьма удобным.
Если быть точным, изначально SASS и писался для таких тривиальных вещей как склейка CSS файлов, для этого требовался совместимый синтаксис, поэтому в редакции SCSS синтаксис с импортами в точности соответствует CSS. Это даже не заимствованая возможность, а целенаправленно созданная.
Sign up to leave a comment.
Вкусный CSS: Sass + Compass