Насколько далеко следует разбивать таблицы стилей?

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

Пикледегг,

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

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

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

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

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

base.css

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

page.css

• Выполняет любые изменения, относящиеся к конкретной странице.

microsite_skin.css

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

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

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

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

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

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

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

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

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

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

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

Я разбиваю свой почти точно так же:

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

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

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

ОБНОВЛЕНИЕ: я немного изменил свою систему в последних нескольких проектах, которые я сделал.

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

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

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

Я помещаю все стили, включая стили, специфичные для 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-запросы. Используйте спрайты изображений, одну таблицу стилей, один javascript "application.js" и т. д.

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

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

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

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

Дополнительные сведения см. В репозитории Git blueprint-css.

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

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

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

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

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

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