Там каким-либо преимуществом является к наличию единственного монстра .css файл, который содержит элементы стиля, которые будут использоваться почти на каждой странице?
Я думаю, что для простоты управления, хотел бы вытащить различные типы CSS в несколько файлов и включать каждый файл в мое основное <link />
это плохо?
Я думаю, что это лучше
по сравнению с.
Вы видели какие-либо глюки с выполнением его один путь по сравнению с другим?
Вы можете просто использовать один файл css для производительности, а затем закомментировать секции, как это:
/******** Header ************/
//some css here
/******* End Header *********/
/******** Footer ************/
//some css here
/******* End Footer *********/
etc
Вам нужны оба мира.
Вам нужно несколько файлов CSS, потому что ужасно тратить свое здравомыслие.
В то же время лучше иметь один большой файл.
Решение состоит в том, чтобы иметь некоторый механизм, объединяющий несколько файлов в один файл.
Примером может быть что-то вроде
<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />
Затем сценарий allcss.php выполняет объединение файлов и их доставку.
В идеале сценарий должен проверять даты модификаций для всех файлов, создавать новую композицию, если какая-либо из них изменяется, затем возвращает эту композицию, а затем проверяет заголовки If-Modified HTTP, чтобы не отправлять избыточный CSS.
Это дает вам лучшее из обоих миров. Отлично работает и с JS.
Я предпочитаю несколько файлов CSS. Таким образом, будет легче менять «скины» по своему желанию. Проблема с одним монолитным файлом заключается в том, что он может выйти из-под контроля и им сложно управлять. Что делать, если вы хотите синий фон, но не хотите, чтобы кнопки менялись? Просто измените свой файл фона. И т.д.
На этот вопрос сложно ответить. На мой взгляд, у обоих вариантов есть свои плюсы и минусы.
Лично я не люблю читать один ОГРОМНЫЙ файл CSS, и поддерживать его очень сложно. С другой стороны, его разделение вызывает дополнительные HTTP-запросы, которые потенциально могут замедлить работу.
Мое мнение было бы одним из двух.
1) Если вы знаете, что ваш CSS НИКОГДА не изменится после того, как вы его построите, я бы создал несколько файлов CSS на этапе разработки (для удобства чтения), а затем вручную объединил бы их перед запуском (чтобы уменьшить количество HTTP-запросов. )
2) Если вы знаете, что время от времени собираетесь менять свой CSS и вам нужно, чтобы он был читабельным, я бы создал отдельные файлы и использовал код (при условии, что вы используете какой-то язык программирования) объединить их во время сборки времени выполнения (минимизация / комбинация времени выполнения - это свинья ресурсов).
В любом случае я настоятельно рекомендую кэширование на стороне клиента, чтобы еще больше уменьшить количество HTTP-запросов.
РЕДАКТИРОВАТЬ:
Я нашел этот блог , в котором показано, как комбинировать CSS во время выполнения, используя только код. Стоит взглянуть (хотя сам еще не тестировал).
РЕДАКТИРОВАТЬ 2:
Я решил использовать отдельные файлы во время разработки и процесс сборки для минимизации и объединения. Таким образом, я могу иметь отдельный (управляемый) CSS во время разработки и полноценный монолитный минифицированный файл во время выполнения. И у меня все еще есть статические файлы и меньше накладных расходов на систему, потому что я не выполняю сжатие / минификацию во время выполнения.
примечание: покупателям я настоятельно рекомендую использовать Bundler как часть процесса сборки. Независимо от того, создаете ли вы в своей среде IDE или из сценария сборки, сборщик может быть запущен в Windows через включенный exe
или может быть запущен на любом компьютере, на котором уже запущен node.js.
Монолитные таблицы стилей действительно предлагают множество преимуществ (которые описаны в других ответах), однако в зависимости от общего размера документа таблицы стилей вы можете столкнуться с проблемами в IE. IE имеет ограничение на количество селекторов, которые он будет читать из одного файла . Ограничение - 4096 селекторов. Если ваша монолитная таблица стилей будет иметь больше, чем это, вы захотите разделить ее. Это ограничение только поднимает уродливую голову в IE.
Это для всех версий IE.
Преимуществом единого файла CSS является эффективность передачи данных. Каждый HTTP-запрос означает ответ с HTTP-заголовком для каждого запрашиваемого файла, а это требует пропускной способности.
Я передаю свой CSS как PHP-файл с типом мима "text/css" в HTTP-заголовке. Таким образом, я могу иметь несколько CSS-файлов на стороне сервера и использовать PHP-включения для их объединения в один файл по запросу пользователя. Каждый современный браузер получает файл .php с кодом CSS и обрабатывает его как файл .css.
Наличие только одного файла CSS лучше для времени загрузки ваших страниц, так как это означает меньше HTTP-запросов.
Наличие нескольких маленьких CSS-файлов облегчает разработку (по крайней мере, я так думаю: наличие одного CSS-файла на модуль вашего приложения облегчает работу).
Итак, в обоих случаях есть веские причины...
Решением, которое позволит вам получить лучшее из обеих идей, будет :
Есть также некоторые программы, которые делают это объединение CSS файлов во время выполнения, а не во время сборки; но делать это во время выполнения означает потреблять немного больше CPU (и, очевидно, требует некоторого механизма кэширования, чтобы не генерировать большой файл слишком часто)
Я предпочитаю несколько CSS файлов во время разработки. Так намного проще управлять и отлаживать. Тем не менее, я предлагаю использовать инструмент для минификации CSS, например YUI Compressor, который объединит ваши CSS файлы в один монолитный файл.
Обычно у меня есть несколько CSS файлов:
Я не слишком обеспокоен множественными запросами страниц к CSS файлам. У большинства людей приличная пропускная способность, и я уверен, что есть другие оптимизации, которые дадут гораздо больший эффект, чем объединение всех стилей в один монолитный CSS-файл. Компромисс между скоростью и удобством обслуживания, и я всегда склоняюсь к удобству обслуживания. YUI comperssor звучит довольно круто, возможно, мне придется это проверить.