Здесь существует две крайности:
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
Здесь существует две крайности:
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
Это объясняет существование большого количества фреймоворков. Для каждого проекта подбирается свое оптимальное решение. Но у всех у них есть общие концепции. В нашем случае это разделение файлов по логическим блокам, сборка и сжатие при публикации.
Главное подходить к делу с творчеством, не допускать мусора в стилях и беспорядка.
Нет, не должно быть никаких памяток, структура должна быть простой и понятной.
Предлагаемый мною пример схемы возможно может показаться сложным Вам, поскольку, создавая пример схемы, я отталкивался от проекта, над которым мы работаем в компании. Не видя самого сайта, возможно сложно понять структуру стилей. Я пытался абстрагироваться от самого проекта, привязываясь лишь к типу, сфере сайта.
С клиентской стороны невозможно увидеть реальную структуру css, т.к. приходит уже собранный и сжатый файл. Мы же не видим бизнес-логику сайта, а видим уже сгенеренный html.
Ещё раз повторюсь, запросов должно быть по минимуму, на главный файл сборщик + возмножно ещё один специфичный файл по мере необходимости в зависимости от ситуации.
От простого знания правил CSS до умения хорошо верстать большая дорога. Так же и с верстальщиками.
Есть те, кто действительно хорошо верстает и видит в этом нечто большее, постоянно развиваясь и придумывая новое.
А есть и такие, кто знает правила CSS, и думает, что это просто, расставляя налево и направо костыли.
Это зависит от требуемых стилей, если это новая типичная страница, то необходимые стили уже есть, достаточно добавить в разметку нужные классы.
Если это новый функционал, новые элементы, то крайне нежелательно их просто дописывать в конец главного файла.
Совершенно правильный и самый оптимальный на мой взгляд подход.
Очень удобно когда данный процесс автоматизирован.
Возможно в нем нет смысла для небольших проектов, но для крупных довольно оправданно.
склеивание происходит при публикации сайта. dotLess можно настроить так, чтобы при Publish'е asp.net web проекта в папку складывались уже собранные css-файлы.
На dev'е при разработке наоборот, удобнее когда файлы грузятся отдельно, чтобы отслеживать номера строк селекторов.
Подключение css-файлов на странице желательно свести к одному линку на файл-сборщик, это не мелочь :). front-end оптимизация оч важна, потому как позволяет ускорить загрузку сайта чуть ли не в половину. А уменьшение линков это основное правило front-end оптимизации.
Разработчик должен выполнять только творческую работу, т.е он не должен задумываться о такой механической работе как склеивание файлов и сжатие. Ему для работы необходим удобный формат синтаксиса, быстрое нахождение необходимых селекторов.
На мой взгляд сортировать селекторы по алфавиту не оч удобно, не всегда известно как начинается селектор. Намного удобнее разделять стили по группам. А чтобы не бегать в начало-конец файла, проще иметь несколько файлов и ассоциировать их названия с этими группами.
Так же стоит группировать сами свойства в селекторе для более удобочитаемости, свойства позиционирования вместе, строчка отступа, цветовая гамма отдельно и т.п…
Разработчик пишет код в легко-читаемой и удобной ему форме:
selector
{
property: value;
another-property: value;
}
а handler уже преобразует его в подобный вид:
selector{property:value;another-property:value;}
оптимизированный под минимальный объем
Сборка и сжатие css файлов потому и необходимы, что для поддержки и разработки удобнее иметь несколько файлов в удобном формате синтаксиса, а для клиента оптимальнее один сжатый файл.
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
Главное подходить к делу с творчеством, не допускать мусора в стилях и беспорядка.
На страницу линкуется один main.css, который собирает все основные стили.
Предлагаемый мною пример схемы возможно может показаться сложным Вам, поскольку, создавая пример схемы, я отталкивался от проекта, над которым мы работаем в компании. Не видя самого сайта, возможно сложно понять структуру стилей. Я пытался абстрагироваться от самого проекта, привязываясь лишь к типу, сфере сайта.
Вот например, по какому принципу Вы структурируете файлы http://habrahabr.ru/blogs/css/114497/#comment_3703369?
Я думаю не каждый сходу сориентируется.
Ещё раз повторюсь, запросов должно быть по минимуму, на главный файл сборщик + возмножно ещё один специфичный файл по мере необходимости в зависимости от ситуации.
Есть те, кто действительно хорошо верстает и видит в этом нечто большее, постоянно развиваясь и придумывая новое.
А есть и такие, кто знает правила CSS, и думает, что это просто, расставляя налево и направо костыли.
Если это новый функционал, новые элементы, то крайне нежелательно их просто дописывать в конец главного файла.
Верстальщики вроде не жалуются :)
Конечно же от них желательно понимание oocss www.slideshare.net/stubbornella/object-oriented-css.
Одно другому не мешает и даже не пересекается. Для достижения максимально быстрой загрузки желательно использовать все возможные методы оптимизации.
Очень удобно когда данный процесс автоматизирован.
Возможно в нем нет смысла для небольших проектов, но для крупных довольно оправданно.
На dev'е при разработке наоборот, удобнее когда файлы грузятся отдельно, чтобы отслеживать номера строк селекторов.
Разработчик должен выполнять только творческую работу, т.е он не должен задумываться о такой механической работе как склеивание файлов и сжатие. Ему для работы необходим удобный формат синтаксиса, быстрое нахождение необходимых селекторов.
На мой взгляд сортировать селекторы по алфавиту не оч удобно, не всегда известно как начинается селектор. Намного удобнее разделять стили по группам. А чтобы не бегать в начало-конец файла, проще иметь несколько файлов и ассоциировать их названия с этими группами.
Так же стоит группировать сами свойства в селекторе для более удобочитаемости, свойства позиционирования вместе, строчка отступа, цветовая гамма отдельно и т.п…
Разработчик пишет код в легко-читаемой и удобной ему форме:
selector
{
property: value;
another-property: value;
}
а handler уже преобразует его в подобный вид:
selector{property:value;another-property:value;}
оптимизированный под минимальный объем
Сборка и сжатие css файлов потому и необходимы, что для поддержки и разработки удобнее иметь несколько файлов в удобном формате синтаксиса, а для клиента оптимальнее один сжатый файл.