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

Ответ 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 для производства. (он еще не закончен, мне нужно добавить код, удаленный из версии медиа-запросов, но посмотрите на него.)

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