Структурирование файлов 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 (содержит объявления для многих элементов, а не только нижний колонтитул)

2Д

когда проект имеет много 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

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

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

Введите Media Query

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

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

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

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

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

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

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

16
coding-style css less sass

4 ответов

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.

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

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

  • общий старт.
  • двигайтесь к конкретике как можно медленнее.
  • никогда разделить на основе каких-либо внешних понятий (тип/макета, экран-размеры и т. д.).
19

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

/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*/
1

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

надеюсь, что это поможет!

1

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

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

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

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

#header {
    ...
}

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

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

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

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

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

надеюсь, это поможет ты в каком-то смысле.

1