Как далеко вы должны разбить стили?

Я создаю новый сайт для своей компании, и я нахожусь на этапе, когда я создал html-макет первой страницы. Я собираюсь использовать это как основу для остальной части сайта. Я подумываю об упорядочивании стилей лучше, теперь у меня есть дизайн, похожий на кросс-браузер, но мне интересно, как далеко уйти, когда я его сломаю.

Одна идея состоит в следующем:

  • reset.css
  • typography.css
  • layout.css
  • colors.css

но где я рисую линию? теоретически я мог бы продолжить и разбить их на классы, идентификаторы и т.д., но я думаю, что это происходит за бортом.

Это кажется разумным методом?

ОТВЕТЫ

Ответ 1

Кстати, A List Apart имел article, охватывающий это сегодня. Они рекомендуют разделять на несколько основных категорий, в том числе перечисляемые вами (тип, макет, цвет), но продолжая включать различные трюки, чтобы поддерживать более счастливые браузеры.

С другой стороны, хранение всего содержимого в одном файле css позволяет сохранить запросы между браузером и сервером. Компромисс может заключаться в том, чтобы держать вещи раздельными для разработки и слияния для производства (как часть вашего процесса сборки, естественно: p).

Ответ 2

Я не склонен разбивать типографию на отдельную таблицу стилей, хотя это кажется хорошей идеей. Однако я бы сохранил цвета с типографикой. Мой типичный способ состоит в следующем:

base.css

  • Глобальный стиль, используемый на всем сайте
  • Цели быть расширяемыми, например, чтобы их можно было обновить (но использовать существующий макет) для микросайта.
  • Реализует/импортирует reset.css

page.css

  • Реализует любые изменения, связанные с конкретными страницами.

microsite_skin.css

  • См. пункт base.css 2

Ответ 3

Pickledegg,

Нет ничего плохого в том, чтобы разбить таблицы стилей. На самом деле, мне очень полезно организовать правила css в разные файлы на основе их типа или каких частей сайта они применяются. Если вы объединяете правила в один большой файл, он может быстро стать беспорядком и становится очень трудным для управления.

Я бы посоветовал придумать вашу собственную схему для разделения ваших правил на файлы и придерживаться ее для всех ваших проектов.

Ответ 4

Я бы разбил макет на 2+ части, Базовый макет, IE Hacks, Menus (по одному для каждой области меню. Это может быть что-то вроде верхнего меню и бокового меню) Если сайт, где можно изменить цвет в зависимости от области, я бы добавил один для каждой цветовой области. Вы также можете использовать Yaml или аналогичную базовую структуру для вашего макета. Я бы сохранил разные таблицы стилей отдельно, создавая только объединение их в 2-4 в зависимости от сайта незадолго до загрузки/выпуска. всегда сохраняя хаки отдельно.

Ответ 5

Отделите их на основе того, что вы оцениваете, ваши потребности будут позже. Если вы считаете, что типография, макет или цвета (в глобальном масштабе) будут меняться, то, вероятно, разумно, по крайней мере, очертить стили таким образом, чтобы было легче заменить одну таблицу стилей на другую позже.

Но если вы заходите слишком далеко, вы получите везде повторяющиеся правила (например, #content имеет правило семейства шрифтов в typography.css, правило цвета в colors.css и т.д.). Это не логичный способ разделить вещи, если вы не ожидаете, что там произойдут ключевые изменения.

Если, с другой стороны, как и большинство сайтов, графический дизайн будет оставаться довольно статичным, но в архитектуре будут сделаны некоторые изменения (например, новый тип контента), тогда вы хотите группировать свои стили на основе контекст сайта. Например, article.css, search.css и т.д.

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

Ответ 6

Основная проблема IMO - проблема дублирования свойств. Это делает файлы стилей неуправляемыми. Чтобы обойти эту проблему, используется подход разделения и завоевания. Если мы сможем обеспечить управляемые таблицы стилей с помощью неконфликтных правил, то слияние листов или их модуляция будет легким.

Во время обзоров все, что я делаю, это проверка конфликтов правил, классификаций и девитов. Используя комбинацию Firebug/CSSTidy, выделяются проблемные области. Думая в этих строках, я даже не заглядываю в типографию и разделение шрифтов.

Цель состоит в том, чтобы иметь базовый CSS файл и отдельные файлы браузера. Несколько базовых CSS файлов понадобятся, если приложение имеет разные темы.

Ответ 7

Я помещаю все стили, включая стили IE6 и-7, в один лист. Стили IE6 и 7 нацелены на использование условно-комментариев div, которые появляются только в том случае, если один из этих браузеров приходит на сайт, например:

<body>
<!--[if IE 7]><div class="IE IE7"><![endif]-->
<!--[if IE 6]><div class="IE IE6"><![endif]-->

... rest of markup ...

<!--[if IE]></div><![endif]-->
</body>

Не уверен, что люди думают об этом подходе, но дополнительная разметка ничтожна и возможность включать стили IE6/7 рядом с основными стилями без использования хаков... просто добавляет селектор с ".IE" или ".IE6" и т.д. - это большое удобство.

Как для нескольких таблиц стилей... сохраняйте ваши HTTP-запросы. Используйте спрайты изображений, одну таблицу стилей, один "application.js" javascript и т.д.

Я бы добавил отдельные листы для печатных и карманных стилей, но об этом...

Ответ 8

Не заходите слишком далеко. Если вам нужно, попробуйте найти способ слить их перед производством. Самая большая проблема заключается в том, что вы начинаете заполнять HTTP-запросы. Это не столько проблема для браузера, сколько количество запросов, которые нужно сделать для каждой страницы. Я бы сказал, что вы в хорошем смысле, более 4 будут несколько за бортом. Помните, что вы всегда можете использовать хорошие комментарии и форматирование, чтобы разбить большие файлы CSS.

Ответ 9

Всякий раз, когда я пытаюсь решить, как далеко сломать некоторые файлы (я обычно делаю это с помощью модулей кода, но я применяю те же принципы к моему css/js), я разбиваю его на самые мелкие повторно используемые файлы, которые имеют смысл вместе. Это не лучшее для потока данных по кабелю, но облегчает его обслуживание. Особенно, если у вас будет много css, плавающих вокруг.

Если вы чувствуете себя комфортно, принимая ваши colors.css и используя все это в другом месте без изменений, то вы, вероятно, хорошо.

Ответ 10

Я разрушаю почти точно так же:

  • reset.ccs - стандартный reset из MeyerWeb
  • typography.css - Шрифты, размеры, линейные высоты и т.д.
  • layout.css - все позиционирование, поплавки, выравнивания и т.д.
  • colors.css(или более подходящий skin.css) - Все цвета, фоновые изображения и т.д.

Затем за ними следуют IE-специфические файлы, включенные через условные комментарии для соответствующей версии.

Мне не пришлось отделять их дальше, хотя я организовываю каждый файл в отдельных разделах (базовые элементы, именованные элементы, классы и т.д.)

UPDATE: я немного изменил свою систему в последних нескольких проектах, которые я сделал.

  • base.css - содержит CSS из YUI reset и база YUI Файлы CSS (с атрибуцией)
  • main.css - содержит инструкции @import для следующего:
    • typography.css - Шрифты, размеры, линейные высоты и т.д.
    • layout.css - все позиционирование, поплавки, выравнивания и т.д.
    • theme.css - Все цвета, фоновые изображения и т.д.
  • print.css - переопределяет другие файлы CSS, чтобы сделать страницы доступными для печати. ​​

Затем я также использую условные комментарии для добавления любых CSS файлов, специфичных для IE, если это необходимо.

Следующим шагом в улучшении этого было бы добавить шаг сборки, чтобы объединить все файлы CSS в один файл, чтобы уменьшить HTTP-запросы на сервере.

Ответ 11

Взгляните на blueprint-css. Blueprint - это CSS-структура, которая предоставляет вам различные стили по умолчанию (например, код браузера reset).

Таблицы стилей в проекте-css организованы следующим образом:

  • screen.css - стили по умолчанию для экранов
  • print.css - стили по умолчанию для печати
  • ie.css - специальные исправления для Internet Explorer
  • application.css - содержит стили, которые вы пишете. На самом деле вы не должны изменять предыдущие три таблицы стилей вообще, потому что они генерируются blueprint-css. Вы можете перезаписать все стили blueprint-css в файле application.css.

Подробнее см. в репозитории blueprint-css Git.

Ответ 12

Все рекомендуют сломаться. Я буду адвокатом дьявола.

Как насчет того, чтобы не нарушать таблицы стилей. По крайней мере, для производственных целей лучше иметь один запрос вместо многих. Браузер может обрабатывать 2 одновременных HTTP-запроса. Это означает, что другие 2 запроса могут быть сделаны после завершения первых 2.

Комбинированные файлы - это способ уменьшить количество HTTP-запросов, объединив все сценарии в один script и аналогично объединив все CSS в одну таблицу стилей. Комбинирование файлов более сложно, когда сценарии и таблицы стилей варьируются от страницы к странице, но при этом эта часть процесса выпуска улучшает время отклика.

Yahoo и Google рекомендую это.

Google рекомендует создавать 2 файла. Один для всего, что необходимо при старте, и 1 для всего остального.

Я думаю, что даже дизайнеры должны думать об оптимизации терминов, а не только о хардкорных разработчиках.