имена классов в html верстке
 

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

известным аналогом является БЭМ . на текуший момент основные отличия это другие "разделители", подход к префиксам, также отличается понятие модификатор.

в сочетании с domMaster и css_стилей в js коде (пример) получается убойная штука.

вообще, для меня основное преимущество подобных подходов - упрощение поддержки, т.е. поменьше наследования и связей. Вот недавно понял, что лучше написать отдельные стили для нескольких контейнеров, пусть и похожих, чем сделать один компонент, который учитывает все варианты. Дизайнеры, они ведь такие люди, что обязательно скажут: "А вот здесь пожалуйста на 1px больше" :) От префиксов сейчас решил попробовать отказаться, по-моему они не дают значительной выгоды. Для имен использую camelCase (имяКомпонента-имяЭлемената), да и вообще на клиентской стороне - в результате проще искать по проекту. И собственно по этой же причине идея с дефисом в именах мне больше всего не нравится, в этом случае vim считает такое имя, состоящим из нескольких слов.

в чем убойность? Мне такой вариант больше нравится

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

префиксы нужны хотябы для того чтобы отличить какрас те классы (описал выше) которые модифицируют компонента. еше классы без префиксов использую только для связки с полным именем"

<style>
    .b-project_ubutton--icon .icon {....}
</style>
<button class="b-project_ubutton b-project_ubutton--icon">
    <span class="b-project_ubutton-icon icon">..</span>
</button>.

но это на этапе разработке а позже ".icon" привожу по возможности к полной форме

<style>
    .b-project_ubutton--icon .b-project_ubutton-icon {....}
</style>
<button class="b-project_ubutton b-project_ubutton--icon">
    <span class="b-project_ubutton-icon">..</span>
</button>

естественно такое можно делать только с соблюдением "независимости блока"
так что префиксы полезны. да и потом в проекте всегда присутствуют чтота не из этой схемы и префикс упрощает идентифицировать эти моменты

ну смотри, есть две крайности: абсолютная универсальность и отсутствие связей вообще. Реальность где-то между, причем если и можно найти среднее арифметическое, всем оно не подойдет. Мне сейчас мешают связи, поэтому я от них избавляюсь.

вообще, наверное, в первую очередь дело в том, что я решил сделать для форм какой-то общий стиль. А потом пожалел. Но в любом случае, я модификаторами почти не пользуюсь, посмотрим...

... пример придумал, в контакте есть информация о пользователе (имя: ..., университет: ..., город: ...) в списке пользователей и на страничке профайла. Ты бы сделал это отдельным компонентом?

лакировка. теперь "компонент" называют "объектом" :) это слово хорошо вписывается и в интернете встречается.

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

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

там минимум три места похожих: в списке друзей, в поиске и на странице профайла, причем на странице профайла расстояние между строками чуть больше. Но вообще да, это какие-то неважные детали. Хотя я на самом деле собирался спросить, одним бы ты компонентом ты это сделал или двумя.

а слово объект по-моему не подходит: оно более общее и не обязательно обозначает что-то визуальное. Да и подобных названий и так много: элемент, виджет, компонент. Зачем еще одно?

vflash,


А есть ссылка на какойнибудь готовый сайт с использованием этого приёма?

я по коду лучше пойму....

x-yuri,

<div class="clear_fix miniblock">
  <div class="label fl_l">Любимые игры:</div>
  <div class="labeled fl_l">...</div>
</div>

если речь об этом то там вроде только в одном месте. потому не стал бы делать новый объект. можно выделить в отдельный объект а не понравиться потом слить обратно, и это нормально.

объект уже употреблялся для верстки как "ОПП верстка", потому решил что лучше не плодить термины. нет такой проблемы как у БЭМ. в БЭМ это блок, а блок уже давно употребляется в верстке как div элемент или display:block; . у меня както с этим путаница, потому не нравиться их термин.

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

тут мои
http://vflash.ru/xm/dev.html
http://mail.rambler.ru/m/beta/#/contacts
есть еше но не покажу.

спасибо ознакомлюсь....


По второй ссылке нужна авторизация...

что-то подобное есть в поиске и списке друзей. Только там другие названия полей (Имя, Выпуск, Факультет) и расстояние между строками немного другое. А вообще я согласен, что это не важно. Если что, можно переделать.

веб-почта такая веб-почта...

можешь вот это еще почитать...

этот принцип какбы и был основой развития. ведь по сути способ наименования нужен для того чтобы в итоге получились уникальные имена классов. уникальные классы нужны чтоб соблюсти независимость "css правил" , а эта независимость нужна чтоб можно было строить объектами.
доклад Харисова дал основу. точнее удачное название доклада "Вёрстка независимыми блоками" , а сам доклад очень долго не мог найти. И сейчас документация для БЭМ появилась вот только этой осенью ито если не понимать смысла происходящего то сложно понять о чем она.

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

вот кстати способствующие этому нововведения css
http://habrahabr.ru/blogs/css/112101/

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

нету ничего что должно быть везде где можно ;)

нет ничего что должно быть везде...

НО там где МОЖНО должно быть....

можно развести костер прямо в доме, но я бы этого не делал. Твоя фраза пропагандирует бездумное использование. Использовать надо если нужно, а не можно. Я понимаю, что тебе очень нравится ООП, но это не значит, что его нужно пихать во все дыры. ;)

x-yuri,


Моя фраза говорит какраз о том что что ООП нужно использоать там где необходимо...

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

имелось ввиду где можно (есть необходимость ,надобность) а не можно как разрешение пихать везде где влезит...

наткнулся только что:
http://clubs.ya.ru/bem/replies.xml?i...reply-bem-1124

это был ответ на мой комментарий )

префиксы нужны. без них будет каша как в голове так и на выходе в верстке.
b- это каркас. какбы объект в голом виде. (o- не красиво выглядит)
m- класс от родительского объекта. часто из за лени оставляю как b-. но если выставить то упрощает восприятие результата.
s- использую для классов которые рассчитаны для разных скинов. удалив эти классы каркас не сломается. можно запросто клонировать объекты изменив имя объекта и удаляя эти классы.
i- у меня это картинки в background . можно как в БЭМ сказать что это чтота там.


стоит заметить что у меня префикс не является частью имени объекта. в БЭМ это часть имени объекта. И может по этому в БЭМ префикс дает подсказку на вопрос "что это за объект?" , в моем случаи "что это за класс?"

префиксы нужны и не только в цсс. как бы ни хотелось "не повторять себя", но при рефакторинге это сильно окупается. http://habrahabr.ru/blogs/personal/97670/

кстати, обрати внимание на строчку

.b-person-info.m-user { border-color: red }

без пробела между классами означает пересечение, так что если есть возможность забить на ие6, то такой способ предпочтительнее. чем

.b-person-info_user { border-color: red }

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

<style>
.eee.ccc {color:#F00;}
.sss {color:#0F0;}
</style>
<span class="eee ccc sss">text</span>

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

возможно я ошибаюсь.

не все могут просмотреть твою ссылку, tenshi

там регистрацию чтоли требуют?

ага

вот и публикуй после этого статьи на этом недоресурсе =_="

скопировал сюда: http://javascript.ru/node/12075

делал маленький "доклад" среди своих в компании.
вот презентация . без озвучки это конечно неочем.

бэм со своими разделителями? а смысл?

tenshi,
Презентация была про то чтоб верстать объектно (разбить на мелкие части и верстать маленькими кусками). Так сказать для популяризации. Ничего нового в этом нет.

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

приведу пример почему способ наименования принятый в БЭМ не самый удачный:

При верстке каждый объект описывается в своем шаблоне. Имя этому шаблону задаю такоеже как и имя объекта. И тут есть проблема у БЭМ, не все шаблонизаторы позволяют использовать дефис в имени шаблона.

Еше в редакторе (Notepad++) при двойном клике по имени объекта, это имя объекта будет выделено полностью если в нем использовано подчеркивание , а если будет дефис то выделено будет не полностью . Мелочь , но очень удобно в практике.



Еше так нельзя

var column-proxy = document.querySelector(".b-page-layout__column-proxy");

а так можно

var subj_firstline = document.querySelector(".b-mbox_row-subj_firstline");

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

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

подчёркивание визуально длинее дефиса. и как следствие сильнее разделяет слова. проблема с дефисом в именах шаблонов остаётся и в твоём случае, только реже проявляется (когда для одного модуля нужно несколько шаблонов). по даблклику логичнее было бы выделять вообще всё имя целиком. с ctrl+backspace аналогично.

поэтому лучше так:

var subjFirstLine = document.querySelector(".mboxRow_subjFirstLine");

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

А с этим как раз всё нормально. Есть стандарт преобразования этого в columnProxy.

в js есть стандарт допустимых символов и правила их последовательности. а вот стиль это уже прихоть определенной группы или лица.

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


в таком случаи двойной клик выделит весь класс. выделить весь класс тоже бывает нужно , но мне както чаше бывает нужно выделить часть. или имя объекта или имя элемента.

можно ведь назвать и так. так класс(css) даже привычней выглядит.

var subjFirstLine = document.querySelector(".b-mboxRow-subjFirstLine");

---
Еще в редакторах Ctrl-[вправо/влево] перемешает курсор по словам, а подчеркивание воспринимают как часть слова. Потому дифис как разделитель и тут оказывается более удобным.


_

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

Меня сейчас больше интересуют префиксы. Например целесообразно ли использовать префиксы:
f - форум,
p - персональный,
ph - фотосервис ну и т.д.
помимо b и i
?

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

По поводу повторного использования я в курсе.

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

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

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

Угу, и получится месиво как в PHP. Половина функций в одном стиле, половина в другом. В PHP от этого не избавиться, но зачем и в JavaScript такое творить своими руками?


Я поступил проще. У меня есть метод this.getEl(className), который принимает имя класса, возвращает первый элемент с этим классом (внутри виджета). При этом сама кэширует результаты. Поэтому ссылки на элементы я нигде не сохраняю, при необходимости делаю this.getEl() с нужным классом. В результате имя элемента только в CSS.

префиксы нужны для предотвращения конфликтов. поэтому все имена конкретного программиста должны иметь его префикс. или все имена программистов определённой группы, которые могут друг с другом договориться,чтобы не конфликтовать. при этом одни имена в разных местах должны иметь один префикс (например, класс в цсс и соответствующий скрипт в жс), но при этом имена относящиеся к разным сущностям должны иметь разный префикс (например, у меня есть функция $jam.$doc возвращающая ссылку на документ, а есть модуль wc:doc содержащий базовые стили и скрипты для документации). хотя по хорошему один из них лучше переименовать, чтобы самому же путаться и чтобы не было конфликтов, когда импортируются оба пространства имён типа такого:

with( $jam )
with( $wc )
{
// some code
}

Как это спасёт от того, что ты не помнишь, какие имена со своим префиксом ты использовал год назад?

очень просто: открываешь директорию с модулями, пытаешься создать новый и тебе выдётся ошибка что такой модуль уже есть.