Шаблоны для LS - вырабатываем стандарты верстки (продолжение)
Затравка темы здесь: «Супер-хуки» в шаблонах — вставка кода в любое место
Более четко сформулировано и начало обсуждения здесь: Новые шаблоны для LS — стандарт верстки
По откликам на мой топик по стандартам верстки, я понял, что тема эта актуальна, и есть энтузиасты, готовые участвовать в реализации. Это хорошо.
Хотелось бы услышать еще мнение наиболее активных разработчиков плагинов и самого Макса (ака ort ). А то, может, «проблемы негров шерифа не волнуют» ©… :)
Но я пока не вижу в предложенном подходе никаких минусов, кроме плюсов.
Итак, краткое резюме по результатам обсуждения:
1) нужно структурировать наборы шаблонов к скинам, используя механизм наследования Smarty
2) нужно выработать соглашения по CSS-селекторам, которые в шаблонах используются
3) в обоих направления предлагается опираться на БЭМ-методологию
Важный момент: реализация этого подхода не изменит саму логику движка, и старые скины будут работать, как и прежде!
А теперь, ближе к делу.
Чтобы обсуждение было более продуктивным, предлагаю договориться об используемых терминах:
шаблон — это непосредственно сам tpl-файл
скин — набор файлов (шаблонов, стилей, скриптов) для отображения контента, то, что лежит сейчас в /templates/skin/имя_скина
тема — это вариации отображения одного скина (т.е. скин может иметь более одной темы)
блок — некоторая самостоятельная сущность макета, отображаемой страницы, т.е. используется в терминологии БЭМ
виджет (или виджет-блок) — программный или шаблонный модуль, встраиваемый в страницу (то, что сейчас в LS называется «блоком»)
Разумеется, это лишь предложение, которое можно дополнять, изменять и т.д. Но договориться о терминах нужно, т.к. нередко с этим возникает путаница, что не есть хорошо.
Тут у меня нет пока четких предложений. Считаю, что нужно отталкиваться от БЭМ. Не обязательно копировать конкретные решения Яндекс-разработчиков, но сам подход должен быть таким. Собственно, в CSS-фреймворках, в какой-то степени, это реализовано, правда, по большей части без «Б», а на уровне «Элемент-Модификатор».
Если у кого-то из верстальщиков уже сложилась определенная практика именования CSS-классов для LS-верстки, то поделитесь. Мы можем взять чью-то систему за «нулевой» вариант, и на ее основе уже выработать общие стандарты.
При этом я предлагаю опираться на Bootstrap. Если есть альтернативные предложения — высказывайтесь.
Голая теория мертва без практики. Поэтому, как я уже говорил, нужно сверстать новый скин для LS на основе выработанных стандартов. Было бы классно, если б нашелся дизайнер, который нарисует новый скин — интересный, удобный, технологичный. Если заглянут такие в топик — откликнитесь!
Но разработка нового дизайна — процесс не очень скорый. Поэтому есть другое предложение — взять за основу какую-нибудь интересную тему на базе того же Bootstrap, благо, сейчас все больше ресурсов появляется, где на базе этого фреймворка создаются дизайны с готовой версткой. Можно даже платную взять (в пределах, скажем, 20-30 баксов), главное, чтобы не было лицензионных ограничений и ее можно было бы свободно использовать где угодно и как угодно. И заточить под LS с учетом всего, что говорилось выше.
В предыдущем топике несколько человек уже сказали, что на базе Bootstrap делают верстку для LS. Так может лучше объединить усилия? И получить на теме не просто тупо дефолтный образ фреймворка, а что-то гораздо более интересное и привлекательное? Тем более, что БЭМ-методология отлично подходит для командной работы.
Если такое предложение устраивает, то ищите дизайны на базе Bootstrap и предлагайте их к реализации. Повторюсь — платные (в разумных пределах) тоже годятся.
Для начала хотелось бы, чтобы высказались все, кто не просто согласен с этой инициативой, но и кто готов ее поддержать делом — рисовать/подбирать дизайн, участвовать в подготовке CSS-стандартов, заниматься версткой, писать документацию, адаптировать собственные плагины.
Если видим, что инициатива поддержана, и достаточно желающих ее реализовать, то можем создать отдельный блог по этой инициативе, распределим роли и задачи и уже собственно начнем работать.
В итоге мы должны получить:
1. Новый бесплатный скин. Если Макс поддержит, то я хотел бы, чтобы он вошел в стандартный набор
2. Документ, описывающий стандартную схему шаблонов и именование CSS-классов
Вот, как-то так…
Более четко сформулировано и начало обсуждения здесь: Новые шаблоны для LS — стандарт верстки
По откликам на мой топик по стандартам верстки, я понял, что тема эта актуальна, и есть энтузиасты, готовые участвовать в реализации. Это хорошо.
Хотелось бы услышать еще мнение наиболее активных разработчиков плагинов и самого Макса (ака ort ). А то, может, «проблемы негров шерифа не волнуют» ©… :)
Но я пока не вижу в предложенном подходе никаких минусов, кроме плюсов.
Итак, краткое резюме по результатам обсуждения:
1) нужно структурировать наборы шаблонов к скинам, используя механизм наследования Smarty
2) нужно выработать соглашения по CSS-селекторам, которые в шаблонах используются
3) в обоих направления предлагается опираться на БЭМ-методологию
Важный момент: реализация этого подхода не изменит саму логику движка, и старые скины будут работать, как и прежде!
А теперь, ближе к делу.
Соглашение о терминологии
Чтобы обсуждение было более продуктивным, предлагаю договориться об используемых терминах:
шаблон — это непосредственно сам tpl-файл
скин — набор файлов (шаблонов, стилей, скриптов) для отображения контента, то, что лежит сейчас в /templates/skin/имя_скина
тема — это вариации отображения одного скина (т.е. скин может иметь более одной темы)
блок — некоторая самостоятельная сущность макета, отображаемой страницы, т.е. используется в терминологии БЭМ
виджет (или виджет-блок) — программный или шаблонный модуль, встраиваемый в страницу (то, что сейчас в LS называется «блоком»)
Разумеется, это лишь предложение, которое можно дополнять, изменять и т.д. Но договориться о терминах нужно, т.к. нередко с этим возникает путаница, что не есть хорошо.
CSS-стандарты
Тут у меня нет пока четких предложений. Считаю, что нужно отталкиваться от БЭМ. Не обязательно копировать конкретные решения Яндекс-разработчиков, но сам подход должен быть таким. Собственно, в CSS-фреймворках, в какой-то степени, это реализовано, правда, по большей части без «Б», а на уровне «Элемент-Модификатор».
Если у кого-то из верстальщиков уже сложилась определенная практика именования CSS-классов для LS-верстки, то поделитесь. Мы можем взять чью-то систему за «нулевой» вариант, и на ее основе уже выработать общие стандарты.
При этом я предлагаю опираться на Bootstrap. Если есть альтернативные предложения — высказывайтесь.
Реализация
Голая теория мертва без практики. Поэтому, как я уже говорил, нужно сверстать новый скин для LS на основе выработанных стандартов. Было бы классно, если б нашелся дизайнер, который нарисует новый скин — интересный, удобный, технологичный. Если заглянут такие в топик — откликнитесь!
Но разработка нового дизайна — процесс не очень скорый. Поэтому есть другое предложение — взять за основу какую-нибудь интересную тему на базе того же Bootstrap, благо, сейчас все больше ресурсов появляется, где на базе этого фреймворка создаются дизайны с готовой версткой. Можно даже платную взять (в пределах, скажем, 20-30 баксов), главное, чтобы не было лицензионных ограничений и ее можно было бы свободно использовать где угодно и как угодно. И заточить под LS с учетом всего, что говорилось выше.
В предыдущем топике несколько человек уже сказали, что на базе Bootstrap делают верстку для LS. Так может лучше объединить усилия? И получить на теме не просто тупо дефолтный образ фреймворка, а что-то гораздо более интересное и привлекательное? Тем более, что БЭМ-методология отлично подходит для командной работы.
Если такое предложение устраивает, то ищите дизайны на базе Bootstrap и предлагайте их к реализации. Повторюсь — платные (в разумных пределах) тоже годятся.
Организация
Для начала хотелось бы, чтобы высказались все, кто не просто согласен с этой инициативой, но и кто готов ее поддержать делом — рисовать/подбирать дизайн, участвовать в подготовке CSS-стандартов, заниматься версткой, писать документацию, адаптировать собственные плагины.
Если видим, что инициатива поддержана, и достаточно желающих ее реализовать, то можем создать отдельный блог по этой инициативе, распределим роли и задачи и уже собственно начнем работать.
Результат
В итоге мы должны получить:
1. Новый бесплатный скин. Если Макс поддержит, то я хотел бы, чтобы он вошел в стандартный набор
2. Документ, описывающий стандартную схему шаблонов и именование CSS-классов
Вот, как-то так…
17 комментариев
На счет css стандартов, я использую следующую схему наименования классов:.названиеБлока__названиеЭлемента_названиеМодификатора — то есть везде используем camelcase, ну и соответственно двойным нижним подчеркиванием отделяется элемент, а одинарным модификатор. Если в модификаторе используется некое значение (например, модификатор убирает все маргины у блока), то это значение отделяю минусом, например, .header_margin-null
И естественно, имеет смысл писать не точное значение в модификаторе, а более абстрактное описание, например, не .header_margin-10, а .header_margin-little
А насчет отказа от описания элементов — тут да, БЭМ предлагает опираться исключительно на классы. Но это это лишь значит, что не стоит Bootstrap брать один в один, нужно взять его за основу и создать свой CSS-шаблон. Тем более, что некоторые вещи Bootstrap все же на уровень классов выводит. Тот же .btn, например, может быть применен хоть к диву, хоть к ссылке — практически к любому элементу. Таблицы тоже оснащаются классом .table. Правда, я не пробовал к другим элементам, кроме таблиц, его применять :)
И тут такие еще вопросы возникают:
1) Насколько необходимо буквально каждый элемент привязывать к блоку? Напр., тот же .button-primary — эта кнопка должна одинаково выглядеть в любом блоке. Так стоит ли плодить классы, типа .topic__button_primary-big, .blog__button_primary-big, .sidebar__button_primary-big, .footer__button_primary-big и т.д.? (пользуюсь твоей нотификацией, но названия, конечно, условные). Ведь они будут абсолютно одинаковые! Можно, конечно, перечислить их в CSS и скопом назначить свойства, но добавление любого нового блока повлечет за собой перебор всех таких типовых классов, чтоб добавить в описание новое имя класса, что как-то не очень. Ты как решает эту проблему?
2) Этот вопрос отчасти перекликается с первым. С одной стороны задание класса элемента в Bootstrap может выглядеть слишком длинно:
С другой — это уменьшает размер CSS-файла и, опять же, упрощает само описание класса. Если задать класс так:
То мало того, что нужно много классов описывать с разными вариациями, так еще и запоминать, в каком порядке объявлять модификаторы класса.
Как это решать — тоже пока не знаю. Надо вырабатывать, ИМХО, компромиссные варианты. В принципе, я готов поступиться скоростью рендеринга (для LS-проектов, думаю, это не так критично) в пользу скорости и простоты разработки новых шаблонов и адаптации плагинов.
Смотрите какая штука. Если мы создаем для каждого элемента уникальный класс происходит раздутие файла css. Следовательно, увеличивается время на загрузку этого файла. И увеличивается неудобство использования css файла. Нет той универсальности, которой хотелось бы.
Бутстрап тем и хорош — он относительно универсален. Какие-то вещи можно использовать, а какие-то исключить из сборки просто. А можешь просто при вёрстке назначит элементам свои классы.
Вариант использования бутстрапа мне нравится для тех элементов, где требуется повторяемость — кнопки, строки, иконки. А местами не очень удобно, хоть и универсально — навбар, например. Сложно ему задать тот вид, который мне нужен. Это надо переопределять классы как минимум.
Насчет файловой структуры. Она должна быть максимально логична. Если я не ошибаюсь, у wordpress была довольно логичная файловая структура. Еще мне понравилась у Opencart, хотя, не сильно отличалась от Livestreet. Просто все ключевые блоки разнесены по отдельным файлам. У Livestreet похоже, но вот в чем различие. Папки «templates» есть в каждом плагине, а также в каждом тимплейте (шаблоне сайта), естественно. То есть папок templates может быть в количестве «количество плагинов+1» То есть если я переделываю шаблон, то мне нужно лезть в отдельную папку определенного плагина и там дальше ковыряться. Может, имеет смысл сделать одну папку вида "/templates/skin/default/plugins" — где хранятся все файлы tpl плагинов? А если у новой темы шаблон не определен, то подхватывать шаблон из темы default.
Такие дела. Писал после ночи без сна за версткой пол LS, так что может показаться бредом, но, надеюсь, уловите ход мысли.
А CSS-классы, видимо, нужно делить на две больших группы: общие и специальные. Имена общих классов можно брать из бутстрапа, как есть, а специальные уже именовать по какой-то принятой системе. И тогда в самом шаблоне одному элементу могут присвоены как специальные классы, так и общие. Например, так:
Если у нас есть повторяющийся элемент, то логично сделать из него блок, мы легко можем использовать «блок в блоке», при это их стили все равно будут полностью независимы друг от друга.
по второму пункту:
да, действительно, иногда у элемента или блока может быть довольно много модификаторов, но такая ситуация вполне логична, как правило один модификатор имеет очень узкий функционал, например, только меняет цвет блока или добавляет отступ — это и создает универсальность, а вот класс .btn-primary-large-active-block вряд ли возможно будет использовать в другом месте.
Кстати, когда я начал использовать БЭМ, для меня тоже было странно не использовать глобальный сброс, но как оказалось он совершенно и не нужен.
Ты предлагаешь создавать блок типа «кнопка»? Или как?
ЗЫ Надеюсь, понимаешь, что не спора ради, а чтоб лучше понять суть и выработать наиболее оптимальное решение
Я могу выложить шаблон для LS с БЭМ, который так и не закончил, но общее представление он может дать.
github.com/yo-stepan/modjo
БЭМ блоки лежат в папке _blocks
Большая часть шаблонов в /actions/ осталась от дефолтного шаблона и не работают
К тому же я пока плохо представляю, как это реально на практике работает. Напр., если я хочу, чтобы все ссылки у меня были зеленым болдом неподчеркнутым, а при наведении чтоб подчеркивание было, то, казалось бы, что может быть проще, чем задать это глобально для элемента?
Хорошо, что ты про ссылки сказал, для меня это тоже узкий момент, потому что действительно приходится прописывать стили для ссылок в каждом новом блоке заново и добавлять им еще и классы типа .block__link, но такая техника вполне оправдана — это создает независимость блока.
Ну, а если нужно все ссылки переделать, то придется пользоваться поиском по проекту, благо это не так сложно, или если использовать LESS или подобные техники, то это вообще не будет проблемой.
А из content-main.tpl подхватывается файл topic/topic.tpl. А в папке topic лежат ещё пару файлов: topic-head.tpl и topic-footer.tpl.
Таким образом каждый элемент на своем месте.
Это всё пока в идее — раздумываю над удобством использования такой вложенности.
Идея с БЭМ мне кажется сомнительной, сейчас все универсальные блоки итак вынесены в отдельные файлы, которые можно вставлять куда угодно и стили для таких блоков прописаны в отдельных цсс файлах (table, topic и тд), стили для мелких универсальных блоков находятся в файле common.css. Плюс основные js файлы сейчас вынесены в папку движка, в бэм-блоки их уже не положишь (стоит учитывать что лс расчитан на расширение функционала плагинами в отличии от яндекса например).
Собственно в ЛС стили подобным образом и организованы, только без «Б».
Использовать Бутстрап особого смысла тоже нет, т.к. в ЛС уже есть собственный CSS-JS-фреймворк (который тем не менее требует доработки, например для удобного добавления дропдаунов, изменение сетки и т.п.). Переход на LESS сейчас обдумывается.
Да, кое где стили и яс надо отрефакторить, однотипные шаблоны переместить в одну папку и т.д., шаблоны будут дорабатываться для повышения удобства разработки новых шаблонов и плагинов.
Ключевая идея БЭМ (во всяком случае, как я ее понимаю) — четкая разбивка макета страницы на блоки и элементы. Сейчас у ЛС этого нет, и нынешняя верстка очень плохо с идеологией БЭМ бьется.
Во-первых, в ЛС в отдельные файлы вынесены не блоки, а части макета. И это — блоки и части макета — не одно и то же. Достаточно глянуть в шаблон header.tpl, чтобы это понять. Сам по себе этот файл — действительно типовой кусок страницы, который вставляется везде. Но это ни разу не блок.
Во-вторых, надобность в блоках уже сейчас возникла. Я не очень понимаю, зачем придумывать в шаблонах «блочный» хук, когда есть уже нативная реализация блоков в Смарти.
В-третьих, сейчас среди шаблонов ЛС нет ни одного файла, который давал бы хотя бы самое общее представление о компоновке страницы. Блочная верстка, на которую я предлагаю перейти, позволит все страницы компоновать на базе общего мастер-шаблона, постепенно детализируя отдельные блоки.
И такое еще замечание — есть предположение, что блочная верстка (т.е. в полной мере блочная — с использованием Smarty-блоков) будет гораздо быстрее обрабатываться шаблонизатором. Я глянул мельком скомпилированные шаблоны, что выдает на выходе Смарти при нынешней «поточной» верстке, и при блочной (админка частично на блочной верстке сделана), так вот — как я понял, все инклюды в шаблонах так, по сути, инклюдами и остаются, т.е. если при формировании шаблона было у нас 10 инклюдов, то при отрисовке будет грузиться 10 файлов. А при работе с блоками Смарти собирает один результирующий скомпилированный шаблон. Т.е. переход на блочную верстку в десятки раз уменьшит обращение шаблонизатора к диску.
Это уже на так принципиально. Я предлагал взять не чистый Бутстрап, а какой-нибудь привлекательный дизайн на его основе, получив сразу и новый дизайн для ЛС, и определение CSS-классов. А сами классы могут быть переименованы уже в соответствии с выработанным стандартом.
Кстати, в админке в бета-версии у меня был прикручен LESSphp (т.е. серверная реализация). Я пока отключил, но позже обязательно хочу его использовать.
Так у девелопера итак дизайн по большей части позаимствован у бутстрапа. Над стилями и их именованием надо поработать, да.