Комментарии 101
Спасибо, подозреваю, что это действительно удобно на начальных стадиях верстки. :-)
В первом же попавшемся случае попробую применить.
В первом же попавшемся случае попробую применить.
я тоже использую подобную загатовку для своих версток,
я просто подключаю загатовку в рабочий css файл, и используется наследование
но я использую их и на рабочих сайтах,
и чесно говоря не совсем понимаю почему «не следует» их использовать.
а про улучшение…
в стиле .clear-both
я обычно использую
потому как IE рисует широкую полосу высотой в размер шрифта
я просто подключаю загатовку в рабочий css файл, и используется наследование
но я использую их и на рабочих сайтах,
и чесно говоря не совсем понимаю почему «не следует» их использовать.
а про улучшение…
в стиле .clear-both
я обычно использую
clear:both;
font-size:0px;
height:0px;
потому как IE рисует широкую полосу высотой в размер шрифта
не следует в том плане, что вместо них должны быть определены «правильные» постоянные классы для элементов
впрочем, в статье я написал, что можно и по минимуму использовать, например тот же .clear-both или .l-flat
все же, мне кажется, что данный набор, скорее, вспомогательный
впрочем, в статье я написал, что можно и по минимуму использовать, например тот же .clear-both или .l-flat
все же, мне кажется, что данный набор, скорее, вспомогательный
Если класс с одним только «clear:both» поставить для блока с пустым комментарием, то никто ничего не рисует.
В Opera иногда приходится задавать высоту блока с clear:both… хотя бы в 1 пиксель.
Вставлять пустой комментарий это хуже чем в стиле для clear:both указать фонт-сайз и высоту раз и навсегда)
Вставлять пустой комментарий это хуже чем в стиле для clear:both указать фонт-сайз и высоту раз и навсегда)
Сам всегда использовал такую вещь для стиля .clear-both, но как-то столкнулся с ситуацией, когда для IE этого оказалось недостаточно.
Выход был следующим:
clear-both {clear: both; height: 0; overflow: hidden; font-size: 0; padding: 0px; margin: 0px; line-height: 0; width: 100%}
*+html clear-both {clear: none}
* html clear-both {clear: none}
Выход был следующим:
clear-both {clear: both; height: 0; overflow: hidden; font-size: 0; padding: 0px; margin: 0px; line-height: 0; width: 100%}
*+html clear-both {clear: none}
* html clear-both {clear: none}
Вот обьясните чем лучше это class=«clear-both» чем style=«clear:both». Количество букв тоже само так что быстрее не будет. Зато в style есть преимущество в конце верстки можно поиском отыскать все style сгруппировать в классы и записать в стили.
пишите как вам нравится, я вам не мешаю
О_о человек не любит критеку, А я ведь просто спросил какие преимущества class от style если в класе прописано одно свойства и весь смысл отображение заложен в имени класса, получается изобрели тот же style только в другой упаковки. Я понимаю если назвать класс=«Раздел_каталога» и в стилях настраивать кок он будет отображать, т.е. мы разделяем отображение от семантики. Или так класс=«Раздел_каталога Последний» а в стилях к последнему элементу приписывается какое либо свойство либо бордер либо clear:both а может то и другое. Но вот в классах clear-both не каково смысла.
ААА верстальщики профи налетели на не опытного который хочет в этом лучше разобраться и как давай минусовать без аргументов.
Примените style=«clear:both» в десяти элементах страницы, а потом решите вместо both использовать left (к примеру). В случае с классами это правится в одном месте, а в Вашем? :)
Ага пишется
.clear-both
{
clear:left;
}
И где же по вашему логика самже в конце концов не сможете понять почему же вы написали clear-both f отчистилось только слева.
Надо называть имена классов не по свойствам находящемся в них, а потому что данный класс символизирует если колонка то и назови ее «col» а не «w-30 f-left»
.clear-both
{
clear:left;
}
И где же по вашему логика самже в конце концов не сможете понять почему же вы написали clear-both f отчистилось только слева.
Надо называть имена классов не по свойствам находящемся в них, а потому что данный класс символизирует если колонка то и назови ее «col» а не «w-30 f-left»
Лоханулся, согласен ;)
Хотя некоторые классы (типа hidden) считаю полезными (например, при обработке JS, когда надо скрыть/показать какой-то блок)
Хотя некоторые классы (типа hidden) считаю полезными (например, при обработке JS, когда надо скрыть/показать какой-то блок)
Да есть там пару вменяемых классов. Вот только на счет hidden для javascrip я бы все таки назвал close, open мало ли как они отображаются в разных случаях, может просто сворачиваются в какую либо панельку :) но это надо смотреть в конкретном случае.
Кстати, об имени класса и его внутренностях:
#result_table td.white {
color: red;
}
Реальный пример стиля :) Дело в том, что это из области шахмат — кто играет белыми, у того определенные данные выделяются красным цветом. Правда, наверное стоит подумать над другим именем для класса, но все же забавно
#result_table td.white {
color: red;
}
Реальный пример стиля :) Дело в том, что это из области шахмат — кто играет белыми, у того определенные данные выделяются красным цветом. Правда, наверное стоит подумать над другим именем для класса, но все же забавно
color: #F00; не так в глаза бросается :)
все же наверно стоило назвать #player1, #player2 с уникальными свойствами как цвет шахмат и класс .player для общих свойств как вид шахмат ну а выделение будет .selected, а стиль
.player {
width: 10px;
height: 10px;
background-image:url('');
}
#player1 {
background-position:0 0;
}
#player2 {
background-position:0 10;
}
#player1.selected {
color:red;
}
как то так
.player {
width: 10px;
height: 10px;
background-image:url('');
}
#player1 {
background-position:0 0;
}
#player2 {
background-position:0 10;
}
#player1.selected {
color:red;
}
как то так
open и close ???
лично у меня всегда был и есть стиль .hide { display:none; }
лично у меня всегда был и есть стиль .hide { display:none; }
Эти классы не даром названы вспомогательными. Их удобно использовать в сочетании с другими: например
class=«catalog-item clear-both», и это уже значительно лучше, нежели class=«catalog-item» style=«clear:both;»
class=«catalog-item clear-both», и это уже значительно лучше, нежели class=«catalog-item» style=«clear:both;»
«PS: прошу всех противников создания своих велосипедов проходить мимо, мне ваше мнение заранее известно»
Интересный у вас «PS» получился — выходит можно писать только хвалебные комментарии, а с критикой не вмешиваться?
Интересный у вас «PS» получился — выходит можно писать только хвалебные комментарии, а с критикой не вмешиваться?
«после верстки» вы всеравно будите производить какие либо манипуляции
либо создавать класс
либо группировать классы и группе присвоить clear:both; (а таких классов может быть много, посему не самый лучший вариант имхо)
а если посмотреть на мой предыдущий коммент то поймете почему лучше писать в классе, а не в стиле
либо создавать класс
либо группировать классы и группе присвоить clear:both; (а таких классов может быть много, посему не самый лучший вариант имхо)
а если посмотреть на мой предыдущий коммент то поймете почему лучше писать в классе, а не в стиле
ну никто ведь вам не мешает на этапе разработки писать стили в атрибут style. А потом уж и переносите в css файлы все ваше добро. Человек просто поделился своими идеями.
Наверное тем, что .clear-both может быть разным… вот вам пример
div.header .clear-both { height:5px;clear:both; }
div.footer .clear-both { height:10px;clear;both; }
Это всего лишь пример того, что используя css вместо style вы имеете больше возможностей
div.header .clear-both { height:5px;clear:both; }
div.footer .clear-both { height:10px;clear;both; }
Это всего лишь пример того, что используя css вместо style вы имеете больше возможностей
Сравним
table class=«amar w80 brd1»
с
table style=«margin-left: auto; margin-right: auto; width: 80%; border: 1px solid #ccc;»
table class=«amar w80 brd1»
с
table style=«margin-left: auto; margin-right: auto; width: 80%; border: 1px solid #ccc;»
Вот вы реально не понимаете, что кроме меньшего размера — разницы ваще никакой нет между вашими примерами?
Я реально понимаю, что таким способом очень во многих случаях можно получать быстрый и пригодный результат. Еще я понимаю, что композиция классов действительно отличается от прямого перечисления атрибутов. А Вы?
Пример, кстати, может быть не такой тривиальный и вовсе не с прямым соответствием параметров.
Если искать аналогии в компьютерной науке, то это скорее будет называться как-то вроде «множественное наследование при помощи агрегирования».
Пример, кстати, может быть не такой тривиальный и вовсе не с прямым соответствием параметров.
Если искать аналогии в компьютерной науке, то это скорее будет называться как-то вроде «множественное наследование при помощи агрегирования».
>Пример, кстати, может быть не такой тривиальный и вовсе не с прямым соответствием параметров.
А с каким? Расскажите, мне интересно.
Я вот о чем:
table class=«amar w80 brd1»
когда дизайнер решит, что эта табличка должна быть без бордера вообще (ну или с двухпиксельным), то вы либо побежите по всему проекту менять класс на brd2 (кстати, если дизайнер решит поменять цвет бордера, то вы какой класс заведете?), и это как раз ничем не будет отличаться от прямого перечисления атрибутов, либо ловко сделаете в css-файле вот так:
.brd1 {
border: 0px solid;
}
что, во-первых, само по себе выглядит достаточно глупо, во-вторых, все элементы, на которые вы понавешали этот чудесный класс, останутся без бордера.
В то же время, если бы вы выдавали классы в зависимости от того, какую логическую роль этот элемент играет в документе, а не от того, как он должен выглядеть, то вам достаточно было бы поменять одну строчку в css-файле.
А с каким? Расскажите, мне интересно.
Я вот о чем:
table class=«amar w80 brd1»
когда дизайнер решит, что эта табличка должна быть без бордера вообще (ну или с двухпиксельным), то вы либо побежите по всему проекту менять класс на brd2 (кстати, если дизайнер решит поменять цвет бордера, то вы какой класс заведете?), и это как раз ничем не будет отличаться от прямого перечисления атрибутов, либо ловко сделаете в css-файле вот так:
.brd1 {
border: 0px solid;
}
что, во-первых, само по себе выглядит достаточно глупо, во-вторых, все элементы, на которые вы понавешали этот чудесный класс, останутся без бордера.
В то же время, если бы вы выдавали классы в зависимости от того, какую логическую роль этот элемент играет в документе, а не от того, как он должен выглядеть, то вам достаточно было бы поменять одну строчку в css-файле.
Если рассматривать идеальную ситуацию с идеальными дизайнерами и верстальшиками готовыми всё заново переделать «чтоб было кошерно», то это всё хорошо и правильно.
Но в реалиях всё далеко не всегда так здорово. В случае с бордером «сделайте мне вот эту табличку повиднее» говорит вовсе не дизайнер, а заказчик. Дизайнер в это время может вообще уже заниматься другими делами. Еще тот же заказчик может попросить дополнительно покрасить определенные ячейки разных таблиц в разные цвета.
И здесь получается выбор — либо звать дизайнера, чтобы он переписал все классы этих таблиц и везде добавил по три варианта цветов, а потом программеры воткнули бы эти новые классы в логику.
Либо просто сделать monkey patch и добавить в логике доп.классы bgclr1,bgclr2,bgclr3
к нужным div/td/… длолго не парясь.
Про прототипирование, когда вообще дизайнер может привлекаться по минимуму я и не говорю.
Всё началось с чего? С того что я написал вопрос — «кому должен?».
Это повод задуматься о том, что абстрактная чистота кода сама по себе мало кому интересна в реальной жизни. Но интересен результат, желательно быстрый и недорогой.
Но в реалиях всё далеко не всегда так здорово. В случае с бордером «сделайте мне вот эту табличку повиднее» говорит вовсе не дизайнер, а заказчик. Дизайнер в это время может вообще уже заниматься другими делами. Еще тот же заказчик может попросить дополнительно покрасить определенные ячейки разных таблиц в разные цвета.
И здесь получается выбор — либо звать дизайнера, чтобы он переписал все классы этих таблиц и везде добавил по три варианта цветов, а потом программеры воткнули бы эти новые классы в логику.
Либо просто сделать monkey patch и добавить в логике доп.классы bgclr1,bgclr2,bgclr3
к нужным div/td/… длолго не парясь.
Про прототипирование, когда вообще дизайнер может привлекаться по минимуму я и не говорю.
Всё началось с чего? С того что я написал вопрос — «кому должен?».
Это повод задуматься о том, что абстрактная чистота кода сама по себе мало кому интересна в реальной жизни. Но интересен результат, желательно быстрый и недорогой.
когда три класса у одного элемента, то это конечно не очень хорошо. лучше стараться так не допускать, но например по пару классов с использованием вспомогательных — это помоему вполне реальная ситуация.
вы вот еще тако пример рассмотрите:
допустим основной цвет текста на сайте черный. мало-значимый текст пишется серым шрифтом. и такие кусочки текста присутствуют в разных блоках на сайте. например есть блок с последними сообщениями на форуме, а под ним серым цветом «смотреть все»; под списком новостей такая же надпись «архив» и тд и тп. как я понял, вы придерживаетесь принципа, что для каждого элемента будет создаваться отдельный класс. тогда в случае если вдруг заказчик попросит везде на сайте поменять этот серый цвет на зеленый например, а используется это например в 40 местах, то вам придется в css вносить 40 правок… а если использовать вспомогательные классы, то исправить надо будет только в одном месте.
плюс если в такой ситуации проанализировать количество кода. то у вас например при использовании отдельного класса каждому такому элементу в css'е будет фигурировать запись «color: #123123» 40раз, а при использовании вспомогательного класса только один раз. вот вам и разница.
разумеется есть случаи, когда использование вспомогательных классов не нужно, но, на сколько я помню, абсолютно на всех проектах мне приходилось использовать вспомогательные классы. и я уверен, что код написанный с использованием вспомогательных классов весит меньше, чем вовсе без них.
вы вот еще тако пример рассмотрите:
допустим основной цвет текста на сайте черный. мало-значимый текст пишется серым шрифтом. и такие кусочки текста присутствуют в разных блоках на сайте. например есть блок с последними сообщениями на форуме, а под ним серым цветом «смотреть все»; под списком новостей такая же надпись «архив» и тд и тп. как я понял, вы придерживаетесь принципа, что для каждого элемента будет создаваться отдельный класс. тогда в случае если вдруг заказчик попросит везде на сайте поменять этот серый цвет на зеленый например, а используется это например в 40 местах, то вам придется в css вносить 40 правок… а если использовать вспомогательные классы, то исправить надо будет только в одном месте.
плюс если в такой ситуации проанализировать количество кода. то у вас например при использовании отдельного класса каждому такому элементу в css'е будет фигурировать запись «color: #123123» 40раз, а при использовании вспомогательного класса только один раз. вот вам и разница.
разумеется есть случаи, когда использование вспомогательных классов не нужно, но, на сколько я помню, абсолютно на всех проектах мне приходилось использовать вспомогательные классы. и я уверен, что код написанный с использованием вспомогательных классов весит меньше, чем вовсе без них.
а разве меньший размер, а следовательно и вес странички недостаточная причина??
а как же оптимизация?
а как же оптимизация?
Вот сравните есть две сверстанных странички первая по вашему принципу вторая где классы названы по семантическому признаку.
И вот приспичило вам поменять дизайн, или нет сделать два отображения в зависимости от настроек пользователя в вашем случае прейдется не только стили переписывать но и шаблон преверствовать.
И тогда поймете мой вопрос. Я же не говорил что стили не надо использовать я только хотел подвести к тому что их надо использовать правильно.
И вот приспичило вам поменять дизайн, или нет сделать два отображения в зависимости от настроек пользователя в вашем случае прейдется не только стили переписывать но и шаблон преверствовать.
И тогда поймете мой вопрос. Я же не говорил что стили не надо использовать я только хотел подвести к тому что их надо использовать правильно.
я например использую другое наименование классов:
cBoth {clear: both}
cLeft {clear: left}
fLeft {float: left}
fRight {float: right}
Букв определенно меньше.
cBoth {clear: both}
cLeft {clear: left}
fLeft {float: left}
fRight {float: right}
Букв определенно меньше.
Сколько верстаю никогда не было необходимости использовать подобное. Точнее выносить в отдельные классы определённые свойства. Опять же причина в отделении оформления от данных т. е. правильнее в html написать class=«column», чем class=«column w-half b-center clear-both».
Если в будущем при редизайне вам нужна будет колонка 100% ширины, а не 50%, то не придёться перекапывать все шаблоны, вместо того, что-бы в css в классе column заменить 50% на 100%.
На мой взгляд в присвоении классов элементам html не должно быть привязки к их текущему отображению, что-бы при редизайне не возникало путаницы и не нужно было править html шаблоны.
Если в будущем при редизайне вам нужна будет колонка 100% ширины, а не 50%, то не придёться перекапывать все шаблоны, вместо того, что-бы в css в классе column заменить 50% на 100%.
На мой взгляд в присвоении классов элементам html не должно быть привязки к их текущему отображению, что-бы при редизайне не возникало путаницы и не нужно было править html шаблоны.
Смысл как бы понятен, но для себя смысла в таком не вижу. Мне удобнее сразу задавать нужным блокам необходимые логические классы и идентификаторы и писать им стили.
А вообще использование несемантичных имен классов может быть иногда очень полезно и интересно. Например, для сложной верстки контента.
А вообще использование несемантичных имен классов может быть иногда очень полезно и интересно. Например, для сложной верстки контента.
А что по ссылке вы назвали не семантическим именем класса
Под несемантичными именами имел ввиду презентационные: left, right, inset, outset и остальные.
В принципе расположение тоже к семантики относится не всегда можно по менять столбцы и чтобы при этом остался тот же смысл но все же стоило бы называть колонке осмысленно. Вот если бы в css было бы наследование тогда можно было бы в стилях делать что то типо
.menu-col extend .left {
…
}
Тогда можно было бы сделать классы шаблонов страниц и наследовать от них форматирования а не заниматься копипастом :)
.menu-col extend .left {
…
}
Тогда можно было бы сделать классы шаблонов страниц и наследовать от них форматирования а не заниматься копипастом :)
А у меня на работе используются постоянно такие классы, и в процессе разметки, и в финальной версии :(
Напомнило:
.red {color: red}.
.red {color: red}.
(это плохой подход к вёрстке, т.к. прямо в коде страницы задаёт оформление, хотя это должны делать стили)
Всё относительно кстати. Такой класс имеет право на жизнь в слуае, скажем, верстки таблицы цветов. :-)
хорошая статья, человек не поленился, т.к css смеет свойство постоянно увеличиваться
Спасибо. Хороший подход. Сам давно использую нечто подобное, но префиксы «b-» и прочие (а еще то, что они обозначены в комментарии) — очень понравились.
Одно замечание:
ul.l-nostyle — имхо, более «семантическим» было бы название «ul.l-nobullets»
Одно замечание:
ul.l-nostyle — имхо, более «семантическим» было бы название «ul.l-nobullets»
.b-center{margin: 0 auto;} — спорно, для ИЕ не котируется ;)
НЛО прилетело и опубликовало эту надпись здесь
мне одному кажется эта затея глупостью? ладно clear — это служебный класс,
но
назад в 1999? А потом когда классы раскиданы по 100 страниц и нужно изменить ширину блока до 150px и поменять колонки местами, то получается маразм типа
однажды уже воевал с таким проектом, никакого удовольствия.
зы: можете заминусовать, но когда вы это примените у себя сайте и прийдет время менять все это, то вы поймете о чем я.
но
<div class="clear t-left w-full enum" /> не сильно отличается от <div style="clear: both; width: 100%; float:left; padding-left: 10px;" />
назад в 1999? А потом когда классы раскиданы по 100 страниц и нужно изменить ширину блока до 150px и поменять колонки местами, то получается маразм типа
w-half: 150px, t-left: float-right; r-left: float-left;
однажды уже воевал с таким проектом, никакого удовольствия.
зы: можете заминусовать, но когда вы это примените у себя сайте и прийдет время менять все это, то вы поймете о чем я.
в статье написано:
«Окончательный вариант ваших страниц не должен содержать эти классы...»
«Окончательный вариант ваших страниц не должен содержать эти классы...»
да, и это прочитал :) вообще все прочитал, но «в минимальном количестве» не исключает возможности использования.
Или как это сначала использовать, а потом в конечной верстке нет? — типа сверстал как хотел, потом начинаешь вычищать/вылизывать, а они(классы) разбегаются как котята и макет без них ползет.
Может лучше сразу увидеть логику макета и ограничиться универсальными классами типа box, wrapper, section, inner и тд.?
Или как это сначала использовать, а потом в конечной верстке нет? — типа сверстал как хотел, потом начинаешь вычищать/вылизывать, а они(классы) разбегаются как котята и макет без них ползет.
Может лучше сразу увидеть логику макета и ограничиться универсальными классами типа box, wrapper, section, inner и тд.?
НЛО прилетело и опубликовало эту надпись здесь
Недавно совсем попытался так же собрать небольшое собрание вспомогательных CSS Еще очень далеко до идеала. Главное — начать.
Сорри за небольшой оффтоп. Не подскажете, что за текстовый редактор изображён на картинке к этому посту? Очень понравилась подстветка кода на тёмном фоне, хотесь бы узнать название
ИМХО бред. Народ уже настолько ушёл в сторону от изначальной вёрстки, что страшно становится. Классы в названии должны отображать имя группы, а не как эта группа будет отображаться! Всякие .half, .w100px уже выбешивают. Хотите понять что такое вёрстка? Не надо смотреть на поделья людей, которые прочитав «css для чайников» (не на автора показываю, а вообще), а посмотрите как это делают профи в этой области. Обратите внимание на сайт csszengarden.com и посмотрите что люди творят при ПРАВИЛЬНОЙ разметке. HTML это всего лишь разметка, а не средство указания где это должно находится и как должно выглядеть.
НЛО прилетело и опубликовало эту надпись здесь
фублин
НЛО прилетело и опубликовало эту надпись здесь
Ну тогда проще теги одноименные использовать так даже короче, да и семантика присутствует, типа вот это слово надо выделить. :)
вы когда нибудь задумывались зачем то «как выглядит» вынесено в CSS?
вот то, что предлагаете вы имеет абсолютно обратный смысл.
извините, что резко ответил — но это действительно не правильно.
в один прекрасный момент попросят «измените шрифт в таком-то блоке с наклонного на жирный» и вместо того чтобы зати и написать в css #box123 small{font-weight: bold;} вы будете чистить html или писать ахинея типа #box123 i{font-weight: bold;}, ну и тд.
вот то, что предлагаете вы имеет абсолютно обратный смысл.
извините, что резко ответил — но это действительно не правильно.
в один прекрасный момент попросят «измените шрифт в таком-то блоке с наклонного на жирный» и вместо того чтобы зати и написать в css #box123 small{font-weight: bold;} вы будете чистить html или писать ахинея типа #box123 i{font-weight: bold;}, ну и тд.
Если мне не изменяет память, была проблема с тем, что опера раньше не «понимала» стили в которых использовался символ "-", как альтернативу приходилось использовать символ подчёркивания. Судя по тому, что тут ни одного вопроса об этом, проблема устранилась? А как с обратной совместимостью?
мне кажется все это неверный подход. потому как разметка не должны знать и подсказывать как ее верстать. если вы захотите менять стиль/дизайн то там не факт что будет .clear-both и т.п. как следствие менять разметку (html). Зачем таки проблемы? HTML размечает данные, CSS задает стиль. В вашем случае HTML задает стиль.
> Когда это не следует использовать. Окончательный вариант ваших страниц не должен содержать эти классы или должен содержать их в минимальном количестве, поскольку, по-хорошему, все элементы страниц должны иметь свои классы со строгим определением стилей.
тут с автором не согласен. у меня например на всех проектах встречается использование вспомогательных классов и я в этом не вижу ничего плохого…
вот например я вырал кусок миниклассов из первого попавшегося своего проекта:
.auto-width{width: auto!important;}
.t_small{ font-size: 11px;}
.t_red{color: #e30605}
.t_grey{color: #898989}
.fl_right{float: right;}
.fl_left{float: left;}
ничего плохого в том, что это всё у меня в финальной версии не вижу. а скорее наоборот
тут с автором не согласен. у меня например на всех проектах встречается использование вспомогательных классов и я в этом не вижу ничего плохого…
вот например я вырал кусок миниклассов из первого попавшегося своего проекта:
.auto-width{width: auto!important;}
.t_small{ font-size: 11px;}
.t_red{color: #e30605}
.t_grey{color: #898989}
.fl_right{float: right;}
.fl_left{float: left;}
ничего плохого в том, что это всё у меня в финальной версии не вижу. а скорее наоборот
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вспомогательные классы