Лично я хочу себе собственный Advantage с чистыми клавишами
Кнопки в кинезисе разной формы и высоты, поэтому их неудобно менять местами. Лично я решил эту проблему купив плоские колпачки для cherry mx, которые используются обычно на кассовых аппаратах.
Получилось так:
Во-первых, в самом 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#, т.к. упрощает визуальное восприятие, становится легче и быстрее ориентироваться.
Если в проекте используется SASS, то Compass — оптимальный вариант.
Но насколько я знаю, например, для asp.net нет сборки SASS, только LESS в виде dotLess'а.
Да, я абсолютно с этим согласен, моя цель — сократить css на проекте вдвое, привети к 4 тыс. строк, и я уверен что это можно сделать наверняка, т.к. накопилось много дублирующих стилей.
Элементы, имеющие очень похожий вид, должны иметь один стиль, один класс.
Но это не имеет отношения к разделению стилей на файлы. Я б даже сказал так, что первый шаг рефакторинга — это структуризация стилей по файлам.
Да, несмотря на то, что рефакторинг проводится регулярно, есть проблемные места, мусор, костыли. Но иначе ситуация была бы гораздо хуже — никакого порядка, костыли среди одного мусора.
Мы разрабатываем и храним документацию, которой стараемся придерживаться. Так же я провожу review, но практика показывает, в этом почти нет необходимости потому как до реализации ТЗ организуется встреча с разработчиками и обсуждается техническое решение.
Что касается БЭМ'а, очень интересный подход к верстке, концепция, мы же ушли ещё не так далеко в этом направлении.
Отталкиваться нужно не от количества страниц, а от количества объектов на сайте.
Если Вы работаете над проектом один, легко ориентируетесь в написанных стилях, и главный css файл Вам не кажется перегруженным, то возможно, учитывая трудозатраты на сборку файлов при выкладке очередных изменений, подобная оптимизация не окупит себя.
Но я бы стал разделять стили и выявлять некую структуру даже на раннем этапе проекта.
Дело Ваше, всегда нужно все взвешивать и выбирать оптимальное для данной ситуации решение.
Проект с которым Вы работаете скорее всего небольшой, и Вы работаете над ним один, поэтому не рассматриваете масштабирование. Но что если владельцы проекта готовы вкладывать в него большие ресурсы, и над проектом работает не меньше десятка разработчиков, каждый из которых разрабатывает свой функционал? Для статистики у нас около 30 разработчиков (front-end, back-end, dba) и, если быть точным, на данный момент 63 ветки (фичи, билды, хотфиксы) без учета опубликованных.
Это далеко не самая важная причина по которой стоит разделять стили, но даже здесь это упрощает ситуацию.
У меня другой взгляд на данную ситуацию, я не рассматриваю это как изобретение велосипеда, а ищу способы упростить разработку и поддержку проекта. В случае с проектом, над которым работаю, эта оптимизация структурирования стилей увеличила качество верстки и уменьшила количество front-end дефектов.
А сотрудник IT-департамента это не посторонний человек, он должен быть ознакомлен с регламентами, должен собирать встречи и обсуждать свои идеи и нововведения с коллегами и рукодовством и держать их в курсе, так же необходимо вести документацию.
Да, проблема понятна. Во-первых, разбитые css-файлы должны быть правильно именованы, что упрощает поиск необходимой секции. Во-вторых, я думаю, не нужно ориентироваться на то, что только вышедший новый сотрудник должен сразу же понять что где лежит. Всегда в первый день человек знакомится с продуктом, что где лежит, как работает и т.д., это касается не только css.
В крайнем случае — да, можно всегда возпользоваться глобальным способом. Здесь удобство зависит от редактора. В VS например глобальный поиск идет сразу по папке открытого проекта, во многих других (Dreamweaver, Notepad++) нужно сначала указать директорию в которой делать поиск.
Опять же, если вы видете один css на клиенте, это вовсе не значит, что он один на dev стенде.
На stackoverflow он сжат и размещен отдельно на статическом сервере, как правильно и следует делать. В сжатом файле даже комментарии удаляются, по нему невозможно судить о локальной структуре стилей.
Структурировать или нет — это зависит не от количества разработчиков, а от следующих обстоятельств:
Если у вас небольшой сайт, и вы его обновляете сами по ftp, то конечно возможно структуризация здесь будет лишней.
Если в css файле не более 1000 строк, то вам и не на что его делить :).
Напротив, если в системе контроля версий у вас параллельно идет разработка в 10 ветках, то разделение на файлы существенно облегчает слияние и избежание при этом конфликтов.
> Не помню случая, чтобы у меня файл разрастался более 1000 строк.
1000 строк это довольно небольшой проект. Сборщик main.css в проекте, к которому я применил данную структуру, содержит около 8000 строк. Конечно, т.к. проект существует почти 10 лет, и за это время сменились все разработчики, в нем возможно наличие похожих стилей, которые после рефакторинга можно объеденить. Но все же согласитесь, что в таком файле сложно находить секции, да и само соблюдение секций вряд ли будет соблюдаться, т.к. каждый намеревается добавить свои стили в конец.
Разделение на файлы решает эту проблему. Допустим разработчику нужно заверстать новый элемент на странице просмотра профайла пользователя. Отсутствие главного файла со стилями заставляет его задуматься и писать стили уже в соответствующий файл, в какой-нибудь user-profile.css. Конечно же очень важно правильно называть css файлы, этим вы упрощаете работу коллегам. Я вообще строго отношусь к названиям айдишников, классов и т.п… Название должно отражать непосредственную суть объекта.
Кнопки в кинезисе разной формы и высоты, поэтому их неудобно менять местами. Лично я решил эту проблему купив плоские колпачки для cherry mx, которые используются обычно на кассовых аппаратах.
Получилось так:
Но все же modernizr довольно удобный и полезный инструмент.
Я же предлагаю делить файлы по сущностям.
Но лучше использовать 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 желательно присутствие табуляции:
Так же лично я добавляю табуляцию в секциях:
Конечно все оформляют css так, как им удобно. Но я считаю наиболее удобо- и быстро-читабельный формат, когда каждый селектор на новой строчке, каждое css-свойство на новой строчке, перед значением свойства — пробел.
Такой код так же легче поддается слиянию изменений в системах контроля версий.
Ну а после сборки файл сожмется в одну строку.
Я вообще считаю табуляции нужно везде придерживаться, и в CSS, и в HTML, и в том же C#, т.к. упрощает визуальное восприятие, становится легче и быстрее ориентироваться.
Но насколько я знаю, например, для asp.net нет сборки SASS, только LESS в виде dotLess'а.
Элементы, имеющие очень похожий вид, должны иметь один стиль, один класс.
Но это не имеет отношения к разделению стилей на файлы. Я б даже сказал так, что первый шаг рефакторинга — это структуризация стилей по файлам.
Мы разрабатываем и храним документацию, которой стараемся придерживаться. Так же я провожу review, но практика показывает, в этом почти нет необходимости потому как до реализации ТЗ организуется встреча с разработчиками и обсуждается техническое решение.
Что касается БЭМ'а, очень интересный подход к верстке, концепция, мы же ушли ещё не так далеко в этом направлении.
Но советую использовать хотя бы сжатие файла
Если Вы работаете над проектом один, легко ориентируетесь в написанных стилях, и главный css файл Вам не кажется перегруженным, то возможно, учитывая трудозатраты на сборку файлов при выкладке очередных изменений, подобная оптимизация не окупит себя.
Но я бы стал разделять стили и выявлять некую структуру даже на раннем этапе проекта.
Дело Ваше, всегда нужно все взвешивать и выбирать оптимальное для данной ситуации решение.
Это далеко не самая важная причина по которой стоит разделять стили, но даже здесь это упрощает ситуацию.
А сотрудник IT-департамента это не посторонний человек, он должен быть ознакомлен с регламентами, должен собирать встречи и обсуждать свои идеи и нововведения с коллегами и рукодовством и держать их в курсе, так же необходимо вести документацию.
В крайнем случае — да, можно всегда возпользоваться глобальным способом. Здесь удобство зависит от редактора. В VS например глобальный поиск идет сразу по папке открытого проекта, во многих других (Dreamweaver, Notepad++) нужно сначала указать директорию в которой делать поиск.
На stackoverflow он сжат и размещен отдельно на статическом сервере, как правильно и следует делать. В сжатом файле даже комментарии удаляются, по нему невозможно судить о локальной структуре стилей.
Структурировать или нет — это зависит не от количества разработчиков, а от следующих обстоятельств:
Если у вас небольшой сайт, и вы его обновляете сами по ftp, то конечно возможно структуризация здесь будет лишней.
Если в css файле не более 1000 строк, то вам и не на что его делить :).
Напротив, если в системе контроля версий у вас параллельно идет разработка в 10 ветках, то разделение на файлы существенно облегчает слияние и избежание при этом конфликтов.
1000 строк это довольно небольшой проект. Сборщик main.css в проекте, к которому я применил данную структуру, содержит около 8000 строк. Конечно, т.к. проект существует почти 10 лет, и за это время сменились все разработчики, в нем возможно наличие похожих стилей, которые после рефакторинга можно объеденить. Но все же согласитесь, что в таком файле сложно находить секции, да и само соблюдение секций вряд ли будет соблюдаться, т.к. каждый намеревается добавить свои стили в конец.
Разделение на файлы решает эту проблему. Допустим разработчику нужно заверстать новый элемент на странице просмотра профайла пользователя. Отсутствие главного файла со стилями заставляет его задуматься и писать стили уже в соответствующий файл, в какой-нибудь user-profile.css. Конечно же очень важно правильно называть css файлы, этим вы упрощаете работу коллегам. Я вообще строго отношусь к названиям айдишников, классов и т.п… Название должно отражать непосредственную суть объекта.