Comments 28
Жду продолжения :).
Присоединяюсь! Nilard, скоро планируется вторая часть?
Добро пожаловать! :)
Шикарно. Но так ведь вообще можно обленится.
Еще раз подчеркиваю, что статья шикарная. А вторая часть на тему «лень-двигатель прогресса». Для быстрого, я бы сказал конвейерного создания тем для заказчиков отличный инструмент.
Не сказал бы, что облениться :) Но сосредоточиться на всяких дополнительных фишках и функционале, вместо пиления очередного велосипеда из page.tpl.php
Все настройки созданной подтемы хранятся в БД или экспортируются в info-файл?
В БД. Теоретически их можно экспортировать в Features и потом собирать платформу Drupal при помощи drush make, но хотел бы я посмотреть на человека, который в действительности построил на этом свой development workflow.
Прошу прощения, Omega Tools позволяет экспортировать конфигурацию темы в .info-файл.
Большое спасибо за замечательную, прекрасно иллюстрированную статью.
Пробовал Omega, но идея группировать CSS-код по media queries, а не по структуре, мне не понравилась. Поэтому я отказался от Omega в пользу минималистичной базовой темы Boron и собственного starter kit'а.
Bootstrap и подобные «CSS-фреймворки» не использую принципиально из-за того, что они идут вопреки семантике. Вместо того, чтобы присваивать определенным блокам нужные свойства, CSS-фреймворк декларирует все возможные сочетания свойств под несемантическими классами. Эти классы нужно вставить в HTML блоков, чтобы свойства применились к ним… Ужасно!
Нет, это, конечно, позволяет по-быстренькому склепать тему оформления, но для серьезной работы не годится (мое личное мнение).
Гораздо более грамотный подход предлагает, например, SASS-фреймворк Susy.
Чтобы блок занял, скажем, четыре колонки, пишем:
Чисто, семантично, аккуратно.
Susy позволяет задавать разное количество колонок в зависимости от ширины окна браузера. Я использую следующие диапазоны:
1) 0—400px — мобильники в портретном режиме;
2) 400—600 — мобильники в ландшафтном режиме;
3) 600—800 — планшеты в портретном режиме;
4) 800—1000 — планшеты в ландшафтном режиме;
5) 1000—1200 — нетбуки;
6) 1200—1400 — десктопы.
Напоминаю, что мобильные устройства имеют виртуальное разрешение, отличающееся от физического. Так, на типовом мобильнике с экраном 800×480 пикселов браузер считает, что размер экрана составляет 533×320 пикселов.
По дефолту количество колонок для каждого диапазона соответствует номеру диапазона (например, пять колонок на экране нетбука), но можно использовать и любое другое количество (причем, индивидуального для каждого контейнера и каждого диапазона!). Например:
HTML-код при этом трогать вообще не нужно.
У метода есть несущественный недостаток: в итоговом CSS будут встречаться повторяющиеся участки кода. Из положения можно было бы выйти при помощи @extend, но большого смысла в этом нет, поскольку:
1) повторные куски прекрасно жмутся gzip'ом;
2) на читаемость кода это не влияет, ведь верстальщик работает с SASS, а там повторяются только вызовы mixin'ов, что не нарушает принцип DRY.
Пробовал Omega, но идея группировать CSS-код по media queries, а не по структуре, мне не понравилась. Поэтому я отказался от Omega в пользу минималистичной базовой темы Boron и собственного starter kit'а.
Bootstrap и подобные «CSS-фреймворки» не использую принципиально из-за того, что они идут вопреки семантике. Вместо того, чтобы присваивать определенным блокам нужные свойства, CSS-фреймворк декларирует все возможные сочетания свойств под несемантическими классами. Эти классы нужно вставить в HTML блоков, чтобы свойства применились к ним… Ужасно!
Нет, это, конечно, позволяет по-быстренькому склепать тему оформления, но для серьезной работы не годится (мое личное мнение).
Гораздо более грамотный подход предлагает, например, SASS-фреймворк Susy.
Чтобы блок занял, скажем, четыре колонки, пишем:
---- // Файл: partials/blocks/.block-foo.sass #block-foo +span-columns(2) ----
Чисто, семантично, аккуратно.
Susy позволяет задавать разное количество колонок в зависимости от ширины окна браузера. Я использую следующие диапазоны:
1) 0—400px — мобильники в портретном режиме;
2) 400—600 — мобильники в ландшафтном режиме;
3) 600—800 — планшеты в портретном режиме;
4) 800—1000 — планшеты в ландшафтном режиме;
5) 1000—1200 — нетбуки;
6) 1200—1400 — десктопы.
Напоминаю, что мобильные устройства имеют виртуальное разрешение, отличающееся от физического. Так, на типовом мобильнике с экраном 800×480 пикселов браузер считает, что размер экрана составляет 533×320 пикселов.
По дефолту количество колонок для каждого диапазона соответствует номеру диапазона (например, пять колонок на экране нетбука), но можно использовать и любое другое количество (причем, индивидуального для каждого контейнера и каждого диапазона!). Например:
----
// Файл: partials/blocks/.main-menu.sass
#main-menu
// Изначально блок занимает всю ширину контейнера,
// так что задавать значение для первого диапазона не нужно.
// +at-bp(1)
// Во втором диапазоне пускай тоже будет во всю ширину.
+ap-bp(2)
+span-columns(2)
// Начиная с третьего диапазона и дальше список должен выстраиваться в строку.
+from-bp(3)
ul
+horizontal-list
// В четвертом диапазоне у контейнера данного блока должно быть три колонки,
// из них одну занимает лого, а две других — главное меню.
+at-bp(4,3)
+span-columns(2 omega)
// И так далее
// ...
----HTML-код при этом трогать вообще не нужно.
У метода есть несущественный недостаток: в итоговом CSS будут встречаться повторяющиеся участки кода. Из положения можно было бы выйти при помощи @extend, но большого смысла в этом нет, поскольку:
1) повторные куски прекрасно жмутся gzip'ом;
2) на читаемость кода это не влияет, ведь верстальщик работает с SASS, а там повторяются только вызовы mixin'ов, что не нарушает принцип DRY.
Пробовал Omega, но идея группировать CSS-код по media queries, а не по структуре, мне не понравилась. Поэтому я отказался от Omega в пользу минималистичной базовой темы Boron и собственного starter kit'а.
Можно не использовать отдельные файлы, предложенные омегой, а все писать в global.css, добавить туда media-queries самостоятельно.
Bootstrap и подобные «CSS-фреймворки» не использую принципиально из-за того, что они идут вопреки семантике. Вместо того, чтобы присваивать определенным блокам нужные свойства, CSS-фреймворк декларирует все возможные сочетания свойств под несемантическими классами. Эти классы нужно вставить в HTML блоков, чтобы свойства применились к ним… Ужасно!
Мне тоже поначалу претил такой подход. Но скорость разработки и простота дальнейшего обслуживания все перевесила. Drupal сам добавляет кучу классов ко всем компонентам, так что парочка дополнительных не помешает. Тем более, классы можно добавлять через админку Drupal, например, в выводе модуля Views задавать нужное количество колонок, которое занимает тот или иной компонент, не засоряя CSS. Сам CSS получается очень компактным, описывающим абстрактные классы. А верстальщик/редактор/админ сайта просто добавляет нужные классы нужным компонентам через админку, в любой момент может их менять, не прибегая к правке CSS.
Спасибо за статью, интересный подход к темизации
Nilard, а Foundation не пробовали? Они как раз быстрым прототипированием хвалятся.
Для Drupal есть базовая тема на Foundation в разработке, обещают скоро зарелизить.
Для Drupal есть базовая тема на Foundation в разработке, обещают скоро зарелизить.
В этой части статьи я рассказал о преимуществах и возможностях, которые дает Omega. Во второй части собираюсь рассказать о том, как прикрутить к ней Bootstrap. Таким же способом можно будет прикрутить и любой другой фреймворк. В принципе, ничего нового я не изобретаю, просто рассказываю, как можно воспользоваться уже имеющимся в Drupal и Omega функционалом. Bootstrap мне кажется самым зрелым, качественным и функциональным фреймворком, который оттачивается наиболее массивной аудиторией.
Вы не ответили на вопрос. :)
Прототипы собрать везде ± одинаково по скорости. Хотя поддержка в SCSS радует.
Мне больше www.profoundgrid.com нравится. Но тут на вкус и цвет… :)
foundation вроде как в лицензионнном не разрешается логотип убирать (или я путаю с кем то).
Мне больше www.profoundgrid.com нравится. Но тут на вкус и цвет… :)
foundation вроде как в лицензионнном не разрешается логотип убирать (или я путаю с кем то).
а также можно вставлять любой код без каких-либо ограничений
Удобно очень как, особено потом код искать везде где только можно. В допустимых значениях какого нить филда пхп код найти весело.
Суть — запросы в шаблоне — ХАРАМ!
Удобно очень как, особено потом код искать везде где только можно. В допустимых значениях какого нить филда пхп код найти весело.
Суть — запросы в шаблоне — ХАРАМ!
Сам использую Adaptivetheme для своих проектов, в ней больше гибких настроек, чем в Омеге, есть поддержка panels и Gpanels, и тоже можно гибко настраивать ширину блоков в различных регионов в зависимости от грида. + очень удобная настройка поведения блоков для различных разрешений.
Плюсую за Adaptivetheme.
Никак не могу понять в чем прелесть Омеги, версия 3 плохо документирована в коде, возможностей не так много, 4ая только сегодня в бетту вышла.
Adaptivetheme прекрасно документирована в коде, имеет намного больше настроек в админке, предоставляет большую адаптацию к HTML5 (чего стоит только поддержка figcaption для поля с изображением) + не нарадуюсь css в сабтеме — оставлены все возможные виды классов и айди, генерируемые Друпалом!
Никак не могу понять в чем прелесть Омеги, версия 3 плохо документирована в коде, возможностей не так много, 4ая только сегодня в бетту вышла.
Adaptivetheme прекрасно документирована в коде, имеет намного больше настроек в админке, предоставляет большую адаптацию к HTML5 (чего стоит только поддержка figcaption для поля с изображением) + не нарадуюсь css в сабтеме — оставлены все возможные виды классов и айди, генерируемые Друпалом!
Sign up to leave a comment.
Drupal + Omega + Bootstrap: быстрое создание полностью кастомных тем оформления без верстки (Часть 1. Omega)