Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 92
Очень полезная статья. Надеюсь, хотя бы десятку говноверстальщиков она раскроет глаза.
В той статье говорились совершенно правильные вещи — не стоит без крайней необходимости грузить на страницу несколько css-файлов вместо одного, это замедляет скорость загрузки странички с точки зрения пользователя.
Но в данной статье предлагается другой подход:
1) css-файлов с точки зрения разработчика много, их удобно бить на блоки, логические части и т.п.
2) Перед выкладкой на сервер, с помощью lesscss эти файлы-блоки сливаются в один итоговый css-файл, который уже и грузится пользователем.
Таким образом, и волки сыты, и овцы целы, или, другими словами, и разработчику удобно, и у пользователя все грузится быстро.
Но в данной статье предлагается другой подход:
1) css-файлов с точки зрения разработчика много, их удобно бить на блоки, логические части и т.п.
2) Перед выкладкой на сервер, с помощью lesscss эти файлы-блоки сливаются в один итоговый css-файл, который уже и грузится пользователем.
Таким образом, и волки сыты, и овцы целы, или, другими словами, и разработчику удобно, и у пользователя все грузится быстро.
Но в итоге все равно грузятся все стили?
Под стилями Вы имеете ввиду все css файлы или все css правила?
На страницу линкуется один main.css, который собирает все основные стили.
На страницу линкуется один main.css, который собирает все основные стили.
Я про файлы.
А какая разница, файлы или все правила?
А какая разница, файлы или все правила?
грузится один файл, правила все
А ну вот, видите.
А вы писали про 10%, все равно ж все загрузится.
Я вот сам использую всегда один основной файл стилей (и для ИЕ отдельно).
Но при этом делаю аккуратную структуру, в которой думаю, не запутаешься.
А вы писали про 10%, все равно ж все загрузится.
Я вот сам использую всегда один основной файл стилей (и для ИЕ отдельно).
Но при этом делаю аккуратную структуру, в которой думаю, не запутаешься.
Здесь существует две крайности:
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
Подключение css-файлов на странице желательно свести к одному линку на файл-сборщик, это не мелочь :). front-end оптимизация оч важна, потому как позволяет ускорить загрузку сайта чуть ли не в половину. А уменьшение линков это основное правило front-end оптимизации.
Разработчик должен выполнять только творческую работу, т.е он не должен задумываться о такой механической работе как склеивание файлов и сжатие. Ему для работы необходим удобный формат синтаксиса, быстрое нахождение необходимых селекторов.
На мой взгляд сортировать селекторы по алфавиту не оч удобно, не всегда известно как начинается селектор. Намного удобнее разделять стили по группам. А чтобы не бегать в начало-конец файла, проще иметь несколько файлов и ассоциировать их названия с этими группами.
Так же стоит группировать сами свойства в селекторе для более удобочитаемости, свойства позиционирования вместе, строчка отступа, цветовая гамма отдельно и т.п…
Разработчик пишет код в легко-читаемой и удобной ему форме:
selector
{
property: value;
another-property: value;
}
а handler уже преобразует его в подобный вид:
selector{property:value;another-property:value;}
оптимизированный под минимальный объем
Сборка и сжатие css файлов потому и необходимы, что для поддержки и разработки удобнее иметь несколько файлов в удобном формате синтаксиса, а для клиента оптимальнее один сжатый файл.
Разработчик должен выполнять только творческую работу, т.е он не должен задумываться о такой механической работе как склеивание файлов и сжатие. Ему для работы необходим удобный формат синтаксиса, быстрое нахождение необходимых селекторов.
На мой взгляд сортировать селекторы по алфавиту не оч удобно, не всегда известно как начинается селектор. Намного удобнее разделять стили по группам. А чтобы не бегать в начало-конец файла, проще иметь несколько файлов и ассоциировать их названия с этими группами.
Так же стоит группировать сами свойства в селекторе для более удобочитаемости, свойства позиционирования вместе, строчка отступа, цветовая гамма отдельно и т.п…
Разработчик пишет код в легко-читаемой и удобной ему форме:
selector
{
property: value;
another-property: value;
}
а handler уже преобразует его в подобный вид:
selector{property:value;another-property:value;}
оптимизированный под минимальный объем
Сборка и сжатие css файлов потому и необходимы, что для поддержки и разработки удобнее иметь несколько файлов в удобном формате синтаксиса, а для клиента оптимальнее один сжатый файл.
locals.css — глобальные переменные
только у меня трещит от этого шаблон? :)
Для уменьшения запросов на сервер необходима сборка файлов. Файлы должны склеиваться по специальной конструкции
если «склейкой» файлов занимается сервер при каждом запросе, то экономия какая-то сомнительная. Уменьшив количество запросов вы таким образом увеличите нагрузку на сервер, который будет постоянно склеивать и склеивать одно и то же.
Не правильнее ли будет в высоконагруженных сайтах как можно больше нагрузки переложить на клиентский браузер?
>>Правильнее склеить всё один раз.
вот-вот, и я о том же
кстати, а браузеры кешируют CSS?( я просто не в курсе)
Если так, то идея складывания все в один файл самая правильная. Но, разумеется, файл не должен быть избыточен
вот-вот, и я о том же
кстати, а браузеры кешируют CSS?( я просто не в курсе)
Если так, то идея складывания все в один файл самая правильная. Но, разумеется, файл не должен быть избыточен
пусть клеит сервер и кеширует, клеить каждый раз, когда меняешь стили — довольно сомнительное удовольствие
склеивание происходит при публикации сайта. dotLess можно настроить так, чтобы при Publish'е asp.net web проекта в папку складывались уже собранные css-файлы.
На dev'е при разработке наоборот, удобнее когда файлы грузятся отдельно, чтобы отслеживать номера строк селекторов.
На dev'е при разработке наоборот, удобнее когда файлы грузятся отдельно, чтобы отслеживать номера строк селекторов.
Структура имеет право жить, но в реальности такое расслоение по файлам будет очень неоптимально.
В крайнем случае нужно делать сборку ccs-файлов в один при деплойте проекта. Что, в общем случае, тоже нетривиальная задача для CSS — стили могут перекрываться.
Поэтому я за один файл и периодический рефакторинг.
В крайнем случае нужно делать сборку ccs-файлов в один при деплойте проекта. Что, в общем случае, тоже нетривиальная задача для CSS — стили могут перекрываться.
Поэтому я за один файл и периодический рефакторинг.
Поддерживаю. Ну, максимум, еще файл для IE (хотя последний раз использовал «особые» стили для него года 2 назад). Не помню случая, чтобы у меня файл разрастался более 1000 строк. Да и бегать по вкладкам в редакторе не быстрее, чем перейти на 421 строку файла.
> Не помню случая, чтобы у меня файл разрастался более 1000 строк.
1000 строк это довольно небольшой проект. Сборщик main.css в проекте, к которому я применил данную структуру, содержит около 8000 строк. Конечно, т.к. проект существует почти 10 лет, и за это время сменились все разработчики, в нем возможно наличие похожих стилей, которые после рефакторинга можно объеденить. Но все же согласитесь, что в таком файле сложно находить секции, да и само соблюдение секций вряд ли будет соблюдаться, т.к. каждый намеревается добавить свои стили в конец.
Разделение на файлы решает эту проблему. Допустим разработчику нужно заверстать новый элемент на странице просмотра профайла пользователя. Отсутствие главного файла со стилями заставляет его задуматься и писать стили уже в соответствующий файл, в какой-нибудь user-profile.css. Конечно же очень важно правильно называть css файлы, этим вы упрощаете работу коллегам. Я вообще строго отношусь к названиям айдишников, классов и т.п… Название должно отражать непосредственную суть объекта.
1000 строк это довольно небольшой проект. Сборщик main.css в проекте, к которому я применил данную структуру, содержит около 8000 строк. Конечно, т.к. проект существует почти 10 лет, и за это время сменились все разработчики, в нем возможно наличие похожих стилей, которые после рефакторинга можно объеденить. Но все же согласитесь, что в таком файле сложно находить секции, да и само соблюдение секций вряд ли будет соблюдаться, т.к. каждый намеревается добавить свои стили в конец.
Разделение на файлы решает эту проблему. Допустим разработчику нужно заверстать новый элемент на странице просмотра профайла пользователя. Отсутствие главного файла со стилями заставляет его задуматься и писать стили уже в соответствующий файл, в какой-нибудь user-profile.css. Конечно же очень важно правильно называть css файлы, этим вы упрощаете работу коллегам. Я вообще строго отношусь к названиям айдишников, классов и т.п… Название должно отражать непосредственную суть объекта.
Точно. Правильно именованная сущность как правило используется по назначению. Все мы люди, и имеем ассоциативное мышление. Чем более размытые рамки у ключа поиска — тем больше разброс для результата и возможность ошибиться.
Возможно в Вашем случае такой подход оправдан. Все же каждый работает так, как ему удобно (ну и команде). Но лично мне кажется, что такое дерево папок слишком усложняет понимание.
В предложенном случае, я бы просто добавил в нужное место в один файл со стилями.
А вот за кашу в js файлах я бы, наверное, убил :)
В предложенном случае, я бы просто добавил в нужное место в один файл со стилями.
А вот за кашу в js файлах я бы, наверное, убил :)
Помнить номера строк сложнее, чем помнить говорящие названия файлов.
Да и работать с маленькими файлами приятнее, что не говори.
А про перекрытие стилей… необходимо писать таким образом, чтобы базовые стили перекрывались специфическими, и никогда в другую сторону.
При этом я склоняюсь к подходу main.css + специфичный для раздела .css с соблюдением правила .css может перекрывать main.css, наоборот — никогда.
Да и работать с маленькими файлами приятнее, что не говори.
А про перекрытие стилей… необходимо писать таким образом, чтобы базовые стили перекрывались специфическими, и никогда в другую сторону.
При этом я склоняюсь к подходу main.css + специфичный для раздела .css с соблюдением правила .css может перекрывать main.css, наоборот — никогда.
А я и не запоминаю номера строк — все равно, сперва стили в фаербаге правишь. А в таком дереве первую неделю будешь по полчаса искать нужный файл :)
Хотя нет, все же когда я делаю проект и использую плагины, допустим, к JQuery — могут появиться еще пару css, которые в итоге объединяются в один.
Про перекрытие стилей согласен полностью. Только вот у меня обычно разделено все по блокам в файле стилей, а в начале файла более-менее подробное описание. Ну это если я проект не один и не для себя делаю.
Хотя нет, все же когда я делаю проект и использую плагины, допустим, к JQuery — могут появиться еще пару css, которые в итоге объединяются в один.
Про перекрытие стилей согласен полностью. Только вот у меня обычно разделено все по блокам в файле стилей, а в начале файла более-менее подробное описание. Ну это если я проект не один и не для себя делаю.
У нас на работе есть продакшн версия и девелоп версия проекта. Как раз для разработки, скрипты и стили разбиты по файлам на группы, чтобы обеспечить удобство редактирования многими людьми. Соответственно продакшн версия собирается запуском самописного скрипта, который все стили склеивает воедино, скрипты тоже, пропускает всё через минифаеры и по итогу строится релиз версия, сжатая и не читабельная из кода, загрузка делает минимум обращений к серверу, зато разработка удобная. Все довольны. Советую и вам такой подход попробывать.
Здесь существует две крайности:
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
1) Один файл сборщик — main.css, который собирает абсолютно все файлы. Этот вариант наиболее предпочтителен всеми. Плюсы в том, что main.css на каждой странице одинаковый и в следствии кеширования на следующей странице уже не грузится.
2) Много файлов сборщиков, которые собирают только необходимые блоки для текущей страницы. В итоге файлы весят гораздо меньше, но осуществляется запрос на каждой странице.
Я предлагаю держаться середины — main.css, который содержит основные блоки и кешируется, + специфичный css файл для данного раздела.
Да, проблема понятна. Во-первых, разбитые css-файлы должны быть правильно именованы, что упрощает поиск необходимой секции. Во-вторых, я думаю, не нужно ориентироваться на то, что только вышедший новый сотрудник должен сразу же понять что где лежит. Всегда в первый день человек знакомится с продуктом, что где лежит, как работает и т.д., это касается не только css.
В крайнем случае — да, можно всегда возпользоваться глобальным способом. Здесь удобство зависит от редактора. В VS например глобальный поиск идет сразу по папке открытого проекта, во многих других (Dreamweaver, Notepad++) нужно сначала указать директорию в которой делать поиск.
В крайнем случае — да, можно всегда возпользоваться глобальным способом. Здесь удобство зависит от редактора. В VS например глобальный поиск идет сразу по папке открытого проекта, во многих других (Dreamweaver, Notepad++) нужно сначала указать директорию в которой делать поиск.
Если уж CSS разросся, а надо что-то срочно придумать с оптимизацией сайта, можно использовать CDN для раздачи статики. Ускоряет раза в 2 скорость загрузки страниц.
Если бы мне пришлось дописывать подобный проект, то я бы не полез в эти дебри а просто добавил правила в конец main.css
Если Вам в этой свалке ориентироваться привычно, то для пришедшего после Вас это будет настоящий кошмар.
Если Вам в этой свалке ориентироваться привычно, то для пришедшего после Вас это будет настоящий кошмар.
Это зависит от требуемых стилей, если это новая типичная страница, то необходимые стили уже есть, достаточно добавить в разметку нужные классы.
Если это новый функционал, новые элементы, то крайне нежелательно их просто дописывать в конец главного файла.
Верстальщики вроде не жалуются :)
Конечно же от них желательно понимание oocss www.slideshare.net/stubbornella/object-oriented-css.
Если это новый функционал, новые элементы, то крайне нежелательно их просто дописывать в конец главного файла.
Верстальщики вроде не жалуются :)
Конечно же от них желательно понимание oocss www.slideshare.net/stubbornella/object-oriented-css.
Казалось бы, что может быть проще? Однако вам удалось сделать CSS сложным!
От простого знания правил CSS до умения хорошо верстать большая дорога. Так же и с верстальщиками.
Есть те, кто действительно хорошо верстает и видит в этом нечто большее, постоянно развиваясь и придумывая новое.
А есть и такие, кто знает правила CSS, и думает, что это просто, расставляя налево и направо костыли.
Есть те, кто действительно хорошо верстает и видит в этом нечто большее, постоянно развиваясь и придумывая новое.
А есть и такие, кто знает правила CSS, и думает, что это просто, расставляя налево и направо костыли.
Структурирование — один из инструментов снижения сложности.
А для допиливания под физические ограничения (сливание в один CSS-файл) как правило используются соответствующие инструменты, которые делают это автоматически при сборке.
А про сложность отладки… Firebug всегда покажет место в CSS, далее ищем строчку соответствующего правила — и находим нужное место. В два шага, чуть сложнее чем в один.
Зато за счет снижения сложности ошибок будет гораздо меньше, и расширять такую систему проще.
А для допиливания под физические ограничения (сливание в один CSS-файл) как правило используются соответствующие инструменты, которые делают это автоматически при сборке.
А про сложность отладки… Firebug всегда покажет место в CSS, далее ищем строчку соответствующего правила — и находим нужное место. В два шага, чуть сложнее чем в один.
Зато за счет снижения сложности ошибок будет гораздо меньше, и расширять такую систему проще.
Вообще интересу ради пробежал по крупным известным сайтам (включая тот на котором пишу сейчас этот коммент) в поисках подобной структуры что автор предложил… не обнаружено ничего подобного. Большинство использует заминифайзеные в один файл стили, что конечно логично. Для разработки это тоже беребор такое деление. В продакшене однозначно страх божий в виде предложенного дерева использовать не стоит. Дайте хоть один пример кто это использует, посмотреть на это хочется и сделать пару замеров. И мне реально страшно представить тот сервер который будет для одного юзера обрабатывать столько запросов. Наверно половина запросов в заголовке будет содержать больше информации чем тело ответа.
С клиентской стороны невозможно увидеть реальную структуру css, т.к. приходит уже собранный и сжатый файл. Мы же не видим бизнес-логику сайта, а видим уже сгенеренный html.
Ещё раз повторюсь, запросов должно быть по минимуму, на главный файл сборщик + возмножно ещё один специфичный файл по мере необходимости в зависимости от ситуации.
Ещё раз повторюсь, запросов должно быть по минимуму, на главный файл сборщик + возмножно ещё один специфичный файл по мере необходимости в зависимости от ситуации.
Окей, я просто не правильно понял суть топика, пришлось перечитать. Стало быть вы преследуете цель сделать разработку удобной, раз конечная версия будет собрана из этих запчастей. Но как уже многие высказались, а в чём профит-то? Придётся целую памятку держать перед собой и думать каждый раз, какой же файл из этой кучи открыть чтобы добавить нужный мне стиль. По итогу как сказал Loki3000 просто забъёшь на всё ибо нет времени думать столько еще и над css
Нет, не должно быть никаких памяток, структура должна быть простой и понятной.
Предлагаемый мною пример схемы возможно может показаться сложным Вам, поскольку, создавая пример схемы, я отталкивался от проекта, над которым мы работаем в компании. Не видя самого сайта, возможно сложно понять структуру стилей. Я пытался абстрагироваться от самого проекта, привязываясь лишь к типу, сфере сайта.
Вот например, по какому принципу Вы структурируете файлы http://habrahabr.ru/blogs/css/114497/#comment_3703369?
Я думаю не каждый сходу сориентируется.
Предлагаемый мною пример схемы возможно может показаться сложным Вам, поскольку, создавая пример схемы, я отталкивался от проекта, над которым мы работаем в компании. Не видя самого сайта, возможно сложно понять структуру стилей. Я пытался абстрагироваться от самого проекта, привязываясь лишь к типу, сфере сайта.
Вот например, по какому принципу Вы структурируете файлы http://habrahabr.ru/blogs/css/114497/#comment_3703369?
Я думаю не каждый сходу сориентируется.
Я сторонник разделения на файлы по логике, нежели по половому признаку тега. У нас структурка разделения предельно скромная, но понятная
— ui.css (только нужные стили которые реально используются с jqueryui элементами)
— main.css (стандартное барахло аля тело, заголовки h[1-6] и т.д.)
— input.css (описана кучка разных дизайнов для кнопок и других элементов ввода, нам так нужно)
— osc.css (есть осцилоскоп на canvas, он тоже при себе имеет разный стилевой тюнинг)
— od.css (тоже большая часть в проекте где таблица с кучей всякого, стили для неё держим в отдельном файле)
в итоге вот даёшь задание, сотворить что-либо с осцилографом, человек открывает скриптовый файл ну и стилевой, не мешая другим делает там всё что надо, добавляет и меняет стили которые используются на данной странице. main.css не трогается впринципе, ибо один раз был сделан и ладно. Отвечает лишь за внешний вид в целом.
Не обессудьте уж, на мой взгляд — это «нормальная форма», дальше делить нет смысла.
— ui.css (только нужные стили которые реально используются с jqueryui элементами)
— main.css (стандартное барахло аля тело, заголовки h[1-6] и т.д.)
— input.css (описана кучка разных дизайнов для кнопок и других элементов ввода, нам так нужно)
— osc.css (есть осцилоскоп на canvas, он тоже при себе имеет разный стилевой тюнинг)
— od.css (тоже большая часть в проекте где таблица с кучей всякого, стили для неё держим в отдельном файле)
в итоге вот даёшь задание, сотворить что-либо с осцилографом, человек открывает скриптовый файл ну и стилевой, не мешая другим делает там всё что надо, добавляет и меняет стили которые используются на данной странице. main.css не трогается впринципе, ибо один раз был сделан и ладно. Отвечает лишь за внешний вид в целом.
Не обессудьте уж, на мой взгляд — это «нормальная форма», дальше делить нет смысла.
Это объясняет существование большого количества фреймоворков. Для каждого проекта подбирается свое оптимальное решение. Но у всех у них есть общие концепции. В нашем случае это разделение файлов по логическим блокам, сборка и сжатие при публикации.
Главное подходить к делу с творчеством, не допускать мусора в стилях и беспорядка.
Главное подходить к делу с творчеством, не допускать мусора в стилях и беспорядка.
Если бы файлы делились на div.css, img.css и т.д., то тогда речь шла о половом признаке тега :)
Я же предлагаю делить файлы по сущностям.
Я же предлагаю делить файлы по сущностям.
Похоже на изобретение велосипеда. Но не забывайте, у каждого получается свой велосипед. Так что если в код полезет посторонний человек, ему эта структура может наоборот мешать.
У меня другой взгляд на данную ситуацию, я не рассматриваю это как изобретение велосипеда, а ищу способы упростить разработку и поддержку проекта. В случае с проектом, над которым работаю, эта оптимизация структурирования стилей увеличила качество верстки и уменьшила количество front-end дефектов.
А сотрудник IT-департамента это не посторонний человек, он должен быть ознакомлен с регламентами, должен собирать встречи и обсуждать свои идеи и нововведения с коллегами и рукодовством и держать их в курсе, так же необходимо вести документацию.
А сотрудник IT-департамента это не посторонний человек, он должен быть ознакомлен с регламентами, должен собирать встречи и обсуждать свои идеи и нововведения с коллегами и рукодовством и держать их в курсе, так же необходимо вести документацию.
Нечего посторонним делать в коде. Особенно в CSS.
Могу привести в пример stackoverflow, на котором во главу угла поставлено «And fast. Very, very fast», а также который является кладезем всевозможным оформительских решений. Все css — в одном файле.
На мой взгляд, древовидная структура полезна при групповой разработке, если разработчик один, то получается структуризация ради самой структуризации.
На мой взгляд, древовидная структура полезна при групповой разработке, если разработчик один, то получается структуризация ради самой структуризации.
Опять же, если вы видете один css на клиенте, это вовсе не значит, что он один на dev стенде.
На stackoverflow он сжат и размещен отдельно на статическом сервере, как правильно и следует делать. В сжатом файле даже комментарии удаляются, по нему невозможно судить о локальной структуре стилей.
Структурировать или нет — это зависит не от количества разработчиков, а от следующих обстоятельств:
Если у вас небольшой сайт, и вы его обновляете сами по ftp, то конечно возможно структуризация здесь будет лишней.
Если в css файле не более 1000 строк, то вам и не на что его делить :).
Напротив, если в системе контроля версий у вас параллельно идет разработка в 10 ветках, то разделение на файлы существенно облегчает слияние и избежание при этом конфликтов.
На stackoverflow он сжат и размещен отдельно на статическом сервере, как правильно и следует делать. В сжатом файле даже комментарии удаляются, по нему невозможно судить о локальной структуре стилей.
Структурировать или нет — это зависит не от количества разработчиков, а от следующих обстоятельств:
Если у вас небольшой сайт, и вы его обновляете сами по ftp, то конечно возможно структуризация здесь будет лишней.
Если в css файле не более 1000 строк, то вам и не на что его делить :).
Напротив, если в системе контроля версий у вас параллельно идет разработка в 10 ветках, то разделение на файлы существенно облегчает слияние и избежание при этом конфликтов.
Как только увидел список css-ок, то сначала выругался) Буквально на днях занимался переверсткой интернет-магазина на webasyst… Млять, я больше никогда не буду связываться с этим движком! Там за каким-то хером разделили стили на несколько файлов и так вставили в head. Никакого сжатия или чего-то подобного там не использовалось. В общем выкинул их все и сделал один.
По оптимизации — можно внутри css-ки делать комментами ремарки о принадлежности группы правил к одному смысловому блоку. Ну тут наверное дело вкуса, хз.
По оптимизации — можно внутри css-ки делать комментами ремарки о принадлежности группы правил к одному смысловому блоку. Ну тут наверное дело вкуса, хз.
Проект с которым Вы работаете скорее всего небольшой, и Вы работаете над ним один, поэтому не рассматриваете масштабирование. Но что если владельцы проекта готовы вкладывать в него большие ресурсы, и над проектом работает не меньше десятка разработчиков, каждый из которых разрабатывает свой функционал? Для статистики у нас около 30 разработчиков (front-end, back-end, dba) и, если быть точным, на данный момент 63 ветки (фичи, билды, хотфиксы) без учета опубликованных.
Это далеко не самая важная причина по которой стоит разделять стили, но даже здесь это упрощает ситуацию.
Это далеко не самая важная причина по которой стоит разделять стили, но даже здесь это упрощает ситуацию.
Отталкиваться нужно не от количества страниц, а от количества объектов на сайте.
Если Вы работаете над проектом один, легко ориентируетесь в написанных стилях, и главный css файл Вам не кажется перегруженным, то возможно, учитывая трудозатраты на сборку файлов при выкладке очередных изменений, подобная оптимизация не окупит себя.
Но я бы стал разделять стили и выявлять некую структуру даже на раннем этапе проекта.
Дело Ваше, всегда нужно все взвешивать и выбирать оптимальное для данной ситуации решение.
Если Вы работаете над проектом один, легко ориентируетесь в написанных стилях, и главный css файл Вам не кажется перегруженным, то возможно, учитывая трудозатраты на сборку файлов при выкладке очередных изменений, подобная оптимизация не окупит себя.
Но я бы стал разделять стили и выявлять некую структуру даже на раннем этапе проекта.
Дело Ваше, всегда нужно все взвешивать и выбирать оптимальное для данной ситуации решение.
Перед тем как писать стили для новой страницы сайта следует проанализировать уже существующие css-файлы проекта, возможно там уже есть необходимые стили. Css файл не должен увеличиваться без необходимости.
Ваша главная и самая принципиальная проблема. Если не брать во внимание инлайн-хаки для IE.
Поясните пожалуйста в чем именно проблема и что вы имеете ввиду.
Проблема в том, что вы действительно верите в то, что ваша сложная и местами не очень очевидная архитектура поможет сохранить проект в чистоте и порядке. Клинический идиот всё равно отыщет файл со знакомым названием — base.css, например — и допишет свои стили в конец.
Системы такой структурной организации должны быть либо сугубо авторскими (когда вы контролируете все вносимые изменения), либо сугубо авторитарными, когда существует чёткий свод правил — что-то вроде БЭМа. Кстати, про БЭМ на РИТе планируется часовой доклад от автора.
Системы такой структурной организации должны быть либо сугубо авторскими (когда вы контролируете все вносимые изменения), либо сугубо авторитарными, когда существует чёткий свод правил — что-то вроде БЭМа. Кстати, про БЭМ на РИТе планируется часовой доклад от автора.
Да, несмотря на то, что рефакторинг проводится регулярно, есть проблемные места, мусор, костыли. Но иначе ситуация была бы гораздо хуже — никакого порядка, костыли среди одного мусора.
Мы разрабатываем и храним документацию, которой стараемся придерживаться. Так же я провожу review, но практика показывает, в этом почти нет необходимости потому как до реализации ТЗ организуется встреча с разработчиками и обсуждается техническое решение.
Что касается БЭМ'а, очень интересный подход к верстке, концепция, мы же ушли ещё не так далеко в этом направлении.
Мы разрабатываем и храним документацию, которой стараемся придерживаться. Так же я провожу review, но практика показывает, в этом почти нет необходимости потому как до реализации ТЗ организуется встреча с разработчиками и обсуждается техническое решение.
Что касается БЭМ'а, очень интересный подход к верстке, концепция, мы же ушли ещё не так далеко в этом направлении.
Мой опыт подсказывает, что пятью тысячами строк в CSS можно описать любой внешний вид сайта.
Если для работы требуется больше, следует провести рефракторинг либо CSS-кода, либо внешнего вида проекта с целью приведения страниц к единому виду.
В любом случае, избыточность CSS-кода должна настораживать.
Если для работы требуется больше, следует провести рефракторинг либо CSS-кода, либо внешнего вида проекта с целью приведения страниц к единому виду.
В любом случае, избыточность CSS-кода должна настораживать.
Да, я абсолютно с этим согласен, моя цель — сократить css на проекте вдвое, привети к 4 тыс. строк, и я уверен что это можно сделать наверняка, т.к. накопилось много дублирующих стилей.
Элементы, имеющие очень похожий вид, должны иметь один стиль, один класс.
Но это не имеет отношения к разделению стилей на файлы. Я б даже сказал так, что первый шаг рефакторинга — это структуризация стилей по файлам.
Элементы, имеющие очень похожий вид, должны иметь один стиль, один класс.
Но это не имеет отношения к разделению стилей на файлы. Я б даже сказал так, что первый шаг рефакторинга — это структуризация стилей по файлам.
Чтобы не плодить велосипеды в файле functions.css, для SASS есть мета-фреймворк под названием Compass. В нём есть и бордер-радиус, и бокс-шэдоу, и многое другое.
Я рассказывал про организацию файлов в проектах Яндекса на Субботниках: company.yandex.ru/public/subbotnik/
Искать «Харисов», смотреть снизу вверх.
Частично это описано в клубе «БЭМ», описание устарело.
Текущее состояние будет рассказано на РИТ, а потом опубликовано в клубе.
Искать «Харисов», смотреть снизу вверх.
Частично это описано в клубе «БЭМ», описание устарело.
Текущее состояние будет рассказано на РИТ, а потом опубликовано в клубе.
Как вы относитесь к такой табуляции внутри css файла?
Положительно.
Во-первых, в самом Less желательно присутствие табуляции:
Так же лично я добавляю табуляцию в секциях:
Конечно все оформляют css так, как им удобно. Но я считаю наиболее удобо- и быстро-читабельный формат, когда каждый селектор на новой строчке, каждое css-свойство на новой строчке, перед значением свойства — пробел.
Такой код так же легче поддается слиянию изменений в системах контроля версий.
Ну а после сборки файл сожмется в одну строку.
Я вообще считаю табуляции нужно везде придерживаться, и в CSS, и в HTML, и в том же C#, т.к. упрощает визуальное восприятие, становится легче и быстрее ориентироваться.
Во-первых, в самом Less желательно присутствие табуляции:
#top-menu
{
property: value;
property: value;
.item
{
property: value;
property: value;
}
}
Так же лично я добавляю табуляцию в секциях:
/* Top Menu */
#top-menu
{
property: value;
property: value;
}
#top-menu .item
{
property: value;
property: value;
}
/* end */
Конечно все оформляют css так, как им удобно. Но я считаю наиболее удобо- и быстро-читабельный формат, когда каждый селектор на новой строчке, каждое css-свойство на новой строчке, перед значением свойства — пробел.
Такой код так же легче поддается слиянию изменений в системах контроля версий.
Ну а после сборки файл сожмется в одну строку.
Я вообще считаю табуляции нужно везде придерживаться, и в CSS, и в HTML, и в том же C#, т.к. упрощает визуальное восприятие, становится легче и быстрее ориентироваться.
Спасибо за развёрнутый ответ. Я посмотрел что есть less. Очень соблазнительно, но как я понимаю при отключенном js оформление страница не подгрузит css. И возникает вопрос: есть ли средства позволяющие пользоваться удобствами синтаксиса less за счёт сервера, а не за счёт клиента?
Вы имеете ввиду javascript-реализацию less (http://lesscss.org/), в данном случае конечно не нужно забывать о graceful degradation.
Но лучше использовать less на серверной стороне, для .net например — http://www.dotlesscss.org/, sass для Rails — http://compass-style.org/, less для php — http://leafo.net/lessphp/, less для Rails — http://lesscss.org/#-server-side-usage и т.д.
Но лучше использовать less на серверной стороне, для .net например — http://www.dotlesscss.org/, sass для Rails — http://compass-style.org/, less для php — http://leafo.net/lessphp/, less для Rails — http://lesscss.org/#-server-side-usage и т.д.
Спасибо. Я нашёл php реализацию для моего любимого друпала. Испытаю её на следующем сайте, который буду делать.
Сколько людей столько и мнений. Интересный подход к размещению файлов, но мне кажется что разбиение на мельчайшие функциональные кирпичики — возможно, не самый правильный подход. Потому что на небольшом корпоративном сайте большинства этих файлов не будет, а останется несколько файлов по несколько строк, а в таком случае, разбиение на много мелких файлов уже не несет такого большого смысла, как на крупных проектах.
Или, наоборот, на каком-нибудь интернет-магазине может быть достаточно много типов, например, баннеров на странице и файл, например, banners.css будет просто огромен, скажем 1000 строк. Тогда придется, например, разбивать его еще на миллион мелких файлов и так далее.
А еще, чтобы подключить все необходимые файлы к странице, мне нужно будет просмотреть огромную гору файлов и сообразить, какие именно модули я использую тут, и что из этого мне нужно подключать, а что не нужно. Для большого проекта этот процесс станет просто мучительным.
Может быть вместо размазывания очень тонким слоем всех стилей есть смысл сделать определенный ограниченный набор глобальных стилей, не менее ограниченный набор частных стилей (скажем красивые кнопки), а остальные писать для каждой страницы индивидуально?
Впрочем, стиль формирования структуры файлов — дело сугубо индивидуальное и зависит он, конечно не только от разработчика, но и от архитектуры сайта и от задач проекта и от многих других факторов.
Или, наоборот, на каком-нибудь интернет-магазине может быть достаточно много типов, например, баннеров на странице и файл, например, banners.css будет просто огромен, скажем 1000 строк. Тогда придется, например, разбивать его еще на миллион мелких файлов и так далее.
А еще, чтобы подключить все необходимые файлы к странице, мне нужно будет просмотреть огромную гору файлов и сообразить, какие именно модули я использую тут, и что из этого мне нужно подключать, а что не нужно. Для большого проекта этот процесс станет просто мучительным.
Может быть вместо размазывания очень тонким слоем всех стилей есть смысл сделать определенный ограниченный набор глобальных стилей, не менее ограниченный набор частных стилей (скажем красивые кнопки), а остальные писать для каждой страницы индивидуально?
Впрочем, стиль формирования структуры файлов — дело сугубо индивидуальное и зависит он, конечно не только от разработчика, но и от архитектуры сайта и от задач проекта и от многих других факторов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация и оптимизация стилей