Структурирование файлов CSS (SASS, LESS) по элементам, по функциям и по медиа-запросам: структура 3D-кода?

Ноль-D

Все начинают использовать CSS с одним файлом, который содержит все стили.

style.css

1D

Вскоре он становится громоздким, и каждый решает объединить CSS в несколько файлов по элементам страницы:

html_elements.css
header.css
main-area.css
footer.css

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

typography.css
layout.css
sticky-footer.css (содержит объявления для многих элементов, а не только для нижнего колонтитула)

2D

Если в проекте много CSS, для его одновременного использования может потребоваться использование обеих групп. Структура файлов CSS становится двумерной:

layout/

grid-system.css
header.css
sidebars.css

look/

typography/
- main.css
- headers.css
- lists.css
backgrounds/
- html_elements.css
- header.css
- main-area.css
- footer.css

Хорошо, пример сфабрикован, но вы точно понимаете, что я имею в виду.

До этого момента все нормально.

Введите медиа-запрос

Здесь моя структура CSS получает funked вверх.

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

Некоторые из моих стилей универсальны (применяются повсюду)
Некоторые применяются только к определенному размеру экрана:
- мал;
- средний;
- большое;
- очень большой.
Некоторые из них применяются к определенным группам экранов:
- все, кроме небольших (немобильные стили);
- малый и средний (где боковые панели не находятся сбоку)
- large и xlarge (где у вас есть боковые панели)

Я попытался преодолеть эту проблему, рассеяв медиа-запросы стилей среди существующих файлов CSS. breakpoint Расширение Compass помогает много, но таблицы стилей становятся слишком грязными. Поиск определенного стиля, когда он не изображается в файловых структурах, вызывает большую боль.

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

Итак, я получаю 2D-структуру с медиа-запросами на одной оси и уродливое сочетание элементов и функций на другой оси.

Я абсолютно не удовлетворен этим, но я просто не придумал изящное решение. Пожалуйста, предложите один.

Ответ 1

CSS уже является структурированным языком. К лучшему или худшему, порядок вашего кода меняет его значение. Из-за этого важно, чтобы любая схема организации CSS была продиктована главным образом каскадом. Другим структурным аспектом CSS является семантика. Используйте его в своих интересах. Озабоченность организации держит вещи значимыми и поддерживаемыми. Лучшее, что вы можете сделать, чтобы сохранить смысл, это показать отношения. Отношения уже выражены семантикой.

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

base/
  - Sass imports and settings - no CSS output.
  - e.g _grid, _colors, _rhythm, etc.
general/
  - Initial CSS baseline with resets, defaults, font imports, and classes to extend.
  - e.g. _reset, _root, _fonts, _icons, _defaults, etc.
layout/
  - The rough outline of the site structure.
  - Not "layout" as a set of properties excluding type, "layout" as the overall site template which might well include typography. 
  - e.g. _banner, _nav, _main, _contentinfo, etc.
modules/
  - All the details. First by effect (classes/general), then by widget (ids/specifics).
  - e.g. _users, _admin, _product-lists etc.

Медиа-запросы должны оставаться как можно ближе к коду, на который они влияют. По возможности, они идут напрямую в линию (с барботированием Sass media). Если это становится громоздким, они перемещаются за пределы блока, но не за пределами частичного. MQ переопределяются. Когда вы переопределяете код, особенно важно, чтобы вы могли точно видеть, что переопределено.

На некоторых сайтах вы можете использовать эту структуру дальше. Я иногда добавлял две папки в конце: plugins/ для управления сторонним кодом и overrides/ для обработки неотвратимых (старайтесь избегать их!) Переопределений для конкретного местоположения для виджета. Я также углубился, добавив папку fonts/ с частичными для каждого семейства шрифтов или папку users/ с частичными для добавления, редактирования, просмотра и т.д. Специфичность гибкая, но основная организация остается той же:

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

Ответ 2

почему бы не попробовать что-то вроде этого:

/root
  /modules
    /header
      /html
        header.html
      /css
        module_styles.css /*Configure which style sheets are included with @media rule in this file*/
        /at-media
          small.css
          medium.css
          large.css
      /js
        fancy-nav.js
  /site
    includes.css /*use @import to include each modules stylesheet in a file here and let each module control its own media issues*/

Ответ 3

То, что я делаю, - это ваше 2D-решение (хотя у меня есть еще несколько гнезд) и использование Breakpoint для записи медиа-запросов в строке, когда это необходимо. Одна из вещей, с которой нам нужно иметь дело, - это наш вывод CSS не будет выглядеть так же, как наш ручной код, это реальность использования препроцессора CSS и, в частности, абстрагирования. Вскоре Инструменты Google Chrome dev будут поставляться со встроенной частичной поддержкой Sass, и есть FireSass для Firefox, чтобы помочь вам понять, откуда взялись стили.

Надеюсь, что эта помощь!

Ответ 4

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

То, что я делаю, это "2D" организация, как вы говорите, с большим количеством файлов (скажем, мы говорим css с меньшим препроцессором)

Мне было проще использовать медиа-запросы в том же "меньшем" файле элемента, который я ставил.

Так, например, у меня есть header.less и в том же файле, его медиа-запросы.

#header {
    ...
}

//Header media queries
-----------------------

@media screen and (min-width:480px) { ... }
@media screen and (min-width:768px) { ... }

Теперь, почему я решил сделать так? - > Потому что (для меня) это огромная боль в... нужно искать в другом файле (скажем, responsive.less например), искать в нем медиа-запросы для заголовка, делать мои изменения и т.д. Вместо этого, с этим методом я всегда знаю, где мои медиа-запросы, и их легко достичь/изменить для каждого элемента, и это не добавляет еще много строк в код.

Единственная проблема заключается в том, что при генерации css мы получаем медиа-запросы для отдельных элементов, распространяемых по всему CSS-коду. Не очень красиво! (в это время less/winless не группирует автоматически медиа-запросы.)

Я закончил создание небольшого приложения для групповых медиа-запросов: http://nokturnalapp.com/mqhelper/ Я использую его для создания файлов css для производства. (он еще не закончен, мне нужно добавить код, удаленный из версии медиа-запросов, но посмотрите на него.)

Надеюсь, это поможет вам каким-то образом.