Безусловно, слепо следовать этим правилам тоже не всегда бывает удобно. В этом примере, согласен, удобнее сделать глобально.
Хорошо, что ты про ссылки сказал, для меня это тоже узкий момент, потому что действительно приходится прописывать стили для ссылок в каждом новом блоке заново и добавлять им еще и классы типа .block__link, но такая техника вполне оправдана — это создает независимость блока.
Ну, а если нужно все ссылки переделать, то придется пользоваться поиском по проекту, благо это не так сложно, или если использовать LESS или подобные техники, то это вообще не будет проблемой.
по первому пункту:
Если у нас есть повторяющийся элемент, то логично сделать из него блок, мы легко можем использовать «блок в блоке», при это их стили все равно будут полностью независимы друг от друга.
по второму пункту:
да, действительно, иногда у элемента или блока может быть довольно много модификаторов, но такая ситуация вполне логична, как правило один модификатор имеет очень узкий функционал, например, только меняет цвет блока или добавляет отступ — это и создает универсальность, а вот класс .btn-primary-large-active-block вряд ли возможно будет использовать в другом месте.
Кстати, когда я начал использовать БЭМ, для меня тоже было странно не использовать глобальный сброс, но как оказалось он совершенно и не нужен.
БЭМ и оригинальный Bootstrap будет сложно использовать, так как БЕМ предполагает отказаться от описания стилей элементов, а описывать только классы, отказаться (на сколько это возможно) от наследований и отказаться от глобального сброса стилей. Делается это для увеличения скорости рендера страницы и для того, чтобы блоки родители не могли влиять на вложенные в них блоки. Так что, лучше использовать просто БЭМ.
На счет css стандартов, я использую следующую схему наименования классов:.названиеБлока__названиеЭлемента_названиеМодификатора — то есть везде используем camelcase, ну и соответственно двойным нижним подчеркиванием отделяется элемент, а одинарным модификатор. Если в модификаторе используется некое значение (например, модификатор убирает все маргины у блока), то это значение отделяю минусом, например, .header_margin-null
И естественно, имеет смысл писать не точное значение в модификаторе, а более абстрактное описание, например, не .header_margin-10, а .header_margin-little
Если использовать БЭМ, то можно слегка изменить схему организации шаблонов. Например, я использую такую:
По-скольку в БЭМ центральным элементом является блок, то я создал каталог с блоками, куда вместе складываю .css, .js и .tpl файлы, отвечающие за функциональность конкретного блока, получается примерно следующее:
/blocks/ — это каталог с блоками
/blocks/header/ — здесь хранятся файлы, относящиеся к блоку header, то есть:
/blocks/header/header.tpl
/blocks/header/header.css
/blocks/header/header.js
Таким образом, я могу очень быстро ориентироваться в достаточно большом и даже незнакомом проекте.
В экшенах же я наследую мастер шаблон и только подключаю необходимые блоки.
Отличное предложение, готов помочь чем смогу. В своих проектах (не на ls), уже давно используем наследование шаблонов и это очень помогает при разработке и упрощает код.
Еще хочу предложить при верстке использовать методологию, которую продвигает Яндекс — БЭМ (http://ru.bem.info/method/ а здесь интересные тесты: clubs.ya.ru/bem/replies.xml?item_no=338). С ее помощью можно будет как угодно масштабировать команду, занимающуюся версткой или доработкой проекта, и можно будет решить проблему со «слетающей» версткой блоков, которые добавляют плагины. И вообще это очень удобно, когда стили в проекте строго организованы
Спасибо
но работать такой вариант будет только для фиксированной ширины
где 150 — количество видимых символов, а "..." будет на месте обрезанного текста, плюс документация www.smarty.net/docsv2/ru/language.modifier.truncate.tpl
еще не ставил, но просмотрел сделанный вами мануал — от него стало тепло на сердце :)
github.com/yo-stepan/modjo
БЭМ блоки лежат в папке _blocks
Большая часть шаблонов в /actions/ осталась от дефолтного шаблона и не работают
Хорошо, что ты про ссылки сказал, для меня это тоже узкий момент, потому что действительно приходится прописывать стили для ссылок в каждом новом блоке заново и добавлять им еще и классы типа .block__link, но такая техника вполне оправдана — это создает независимость блока.
Ну, а если нужно все ссылки переделать, то придется пользоваться поиском по проекту, благо это не так сложно, или если использовать LESS или подобные техники, то это вообще не будет проблемой.
Я могу выложить шаблон для LS с БЭМ, который так и не закончил, но общее представление он может дать.
Если у нас есть повторяющийся элемент, то логично сделать из него блок, мы легко можем использовать «блок в блоке», при это их стили все равно будут полностью независимы друг от друга.
по второму пункту:
да, действительно, иногда у элемента или блока может быть довольно много модификаторов, но такая ситуация вполне логична, как правило один модификатор имеет очень узкий функционал, например, только меняет цвет блока или добавляет отступ — это и создает универсальность, а вот класс .btn-primary-large-active-block вряд ли возможно будет использовать в другом месте.
Кстати, когда я начал использовать БЭМ, для меня тоже было странно не использовать глобальный сброс, но как оказалось он совершенно и не нужен.
На счет css стандартов, я использую следующую схему наименования классов:.названиеБлока__названиеЭлемента_названиеМодификатора — то есть везде используем camelcase, ну и соответственно двойным нижним подчеркиванием отделяется элемент, а одинарным модификатор. Если в модификаторе используется некое значение (например, модификатор убирает все маргины у блока), то это значение отделяю минусом, например, .header_margin-null
И естественно, имеет смысл писать не точное значение в модификаторе, а более абстрактное описание, например, не .header_margin-10, а .header_margin-little
По-скольку в БЭМ центральным элементом является блок, то я создал каталог с блоками, куда вместе складываю .css, .js и .tpl файлы, отвечающие за функциональность конкретного блока, получается примерно следующее:
/blocks/ — это каталог с блоками
/blocks/header/ — здесь хранятся файлы, относящиеся к блоку header, то есть:
/blocks/header/header.tpl
/blocks/header/header.css
/blocks/header/header.js
Таким образом, я могу очень быстро ориентироваться в достаточно большом и даже незнакомом проекте.
В экшенах же я наследую мастер шаблон и только подключаю необходимые блоки.
Еще хочу предложить при верстке использовать методологию, которую продвигает Яндекс — БЭМ (http://ru.bem.info/method/ а здесь интересные тесты: clubs.ya.ru/bem/replies.xml?item_no=338). С ее помощью можно будет как угодно масштабировать команду, занимающуюся версткой или доработкой проекта, и можно будет решить проблему со «слетающей» версткой блоков, которые добавляют плагины. И вообще это очень удобно, когда стили в проекте строго организованы
В вашем случае будет примерно такое правило: