Как далеко вы должны разбить таблицы стилей? - PullRequest
15 голосов
/ 21 октября 2008

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

Одной из идей является следующее:

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

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

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

Ответы [ 12 ]

9 голосов
/ 21 октября 2008

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

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

5 голосов
/ 21 октября 2008

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

base.css

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

page.css

  • Внедряет любые специфичные для страницы изменения.

microsite_skin.css

  • См. Base.css point 2
2 голосов
/ 21 октября 2008

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

<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" и т. Д.

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

2 голосов
/ 21 октября 2008

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

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

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

2 голосов
/ 21 октября 2008

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

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

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

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

2 голосов
/ 21 октября 2008

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

2 голосов
/ 21 октября 2008

Pickledegg,

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

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

1 голос
/ 10 августа 2009

Каждый рекомендует разбить. Я буду защитником дьявола.

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

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

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

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

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

1 голос
/ 27 октября 2008

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

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

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

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

1 голос
/ 21 октября 2008

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

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

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...