Руководство по форматированию CSS

[@morr]

Форматируется аналогично всему остальному коду. В первую очередь учитывая принцип DRY, а посему CSS отправляется на помойку, и работа ведётся с SASS+compass с максимальным использованием их возможностей.
В каком порядке css свойства будут писаться — это уже имхо фанатизм, хотя лично я делаю всегда алфавитный, т.к. вим это умеет нажатием пары кнопок.

[@nick4fake]

Да, я никогда не понимал подобных руководств. Как открыл для себя LESS/SASS(SCSS) — больше об этом можно не задумываться, он все делает за тебя.

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

[@vermilion1]

Ну открыли вы для себя LESS/SASS и можете писать как вам хочется? Должны быть какие-то стандарты, если вы работаете в команде. И даже если вы рабатоете один, это тоже не помешает.

[@nick4fake]

Открыл для себя = работаем с ним. Я имею ввиду прозрение. :) У нас он используется во всех проектах. Стандарты — да, но многие из перечисленных выше просто несостоятельны, когда используется что-то вроде sass/

[@nick4fake]

Хотя та, там дальше есть пункты, которые скорее общие подходы описывают. Я имел ввиду советы, вроде:
«Улучшение читаемости кода с помощью руководства по форматированию CSS» от Vitaly Friedman →
Вообще не актуально для sass.

[@sdevalex]

Использую SASS, но если нужно написать чистый CSS, то пишу все правила для одного селектора в одну линию… никогда не понимал, зачем писать каждое правило на новой строке?

[@DenisZ]

Как по мне, запись в одну строку неудобна для чтения.

[@sdevalex]

Часто вы правила читаете? Я куда чаще их ищу… а искать их в перебое с правилами куда сложнее.

[@alisey]

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

[@dshster]

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

[@zTrue]

И удобнее закомментировать правило, если оно на одной строке.

[@theRavel]

Привет, сложности навигации по ченджлогу!

[@maxsite]

Для LESS я как-то делал руководство: wiki.max-3000.com/pmwiki.php?n=Main.Rules-codes-less

[@rakot]

 .box { margin-top: 37px }

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

[@dshster]

Если дизайнер так ратует за пиксели, то можно воспользоваться Pixel Perfect и подгонять отступы и размеры по картинке — по-большей части отпадает работа с числами.

[@zTrue]

Настройте свою IDE на отображение «скрытых символов». Это позволит вам устранить пробелы в конце строк, устранить непреднамеренный пробел в пустой строке, тем самым вы избавитесь от мусора в ваших коммитах.

Куда лучше настроить IDE на удаление лишних пробелов (например, Netbeans это умеет, думаю, многие другие тоже), тогда и цель та же достигается, и глаза эти визуализированные пробелы не мозолят.

[@Delka]

Советы ни о чём.

Нормальные советы:

• использовать БЭМ/SMACSS
• сортировать свойства согласно ZenCoding (т.е. по их смыслу)
• использовать CSSDoc для комментариев
• использовать пробелы вместо табов

[@Kaaboeld]

«использовать пробелы вместо табов»
Возвращение, старого холивара..., но всё же почему вы так считаете?

[@morr]

Да вы шутите? А потом начинается плач о том, какое наши соотечественники быдло, что в ответ на вопросы посылают в гугл.
А табы я люблю. До слёз i.minus.com/i8vQho0FX30a0.png

[@Kaaboeld]

Да, да, да я именно о тех хабра-топиках, не очень хочется к ним возвращаться, к табам, тоже не ровно дышу :), но всё же заявление комментатора, для меня, прозвучало несколько категорично вот и захотел узнать — «почему».

[@Delka]

Картинка по ссылке — наглядно показывает к чему приводят табы.

[@Kaaboeld]

Да для случаев префиксов это конечно гуд, но правда less/sass нивелирует этот «способ применения».

[@Kaaboeld]

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

[@morr]

хелперы для кроссбраузерности css3 свойств это лишь малая часть, основные плюшки в sass или less идут от вложенных блоков стилей, миксинов и переменных

[@morr]

Зачем расширять язык, созданный почти двадцать лет назад, когда почти все веб сайты были простыми, а все их стили умещались в один маленький файл?
Ну, наверное потому, что он в нынешнем виде изжил себя — убог донельзя и не представляет никаких абстракций для избежания дублирования кода. По-моему очевидно.

[@morr]

«не представляет никаких абстракций для избежания дублирования кода» по-вашему не является ответом на вопрос? Подробнее?
О том, что не круто прописывать color: #ABCDEF в двадцати файлах, а потом во всех этих файлах руками менять цвет на другой? И с цветом это лишь простейший случай.
А вриант «избежания» этой проблемы путём ввода десятков css классов на каждый чих и навешивание на элементы в шаблонах по 15 классов — это такой же, если не худший, говнокод, но вынесенный из стилей в шаблоны.
Или то, что в селекторах не рекомендуют использовать более трёх уровней вложенности, т.к. страница будет ренедериться на 1мс дольше. Только есть и другой мотив, зачастую более важный — css файлы будут просто нечитаемы при селекторах большой вложенности.

Могу ещё и про яндексовский БЭМ упомянуть, часть практик которого существуют с целью компенсировать недостатки css, и с переходом на sass/less они становятся просто бессмысленными.

[@Delka]

Потому что табы создают очень много проблем и не дают никаких преимуществ.
Это не только я так считаю, это написано во всех нормальных style-guide:

• Google C++ Style Guide
• Google HTML/CSS Style GuideSMACSS

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

[@Kaaboeld]

«Потому что табы создают очень много проблем и не дают никаких преимуществ.» Основное преимущество и об этом уже много где говорилось — возможность управлять его длиной на уровне редактора не внося изменения в листинг кода.

«Причина проста — в мире эльфов табы удобны, а в реальном мире, когда с кодом работают разные разработчики, они создают лишние проблемы, которых просто не должно быть. Проблемы которые стоят времени и денег.»
Видимо последние лет 5-6 живу в мире эльфов, ну что же никто из нашей «лесной братии» пока не жаловался, а даже совсем наоборот…

[@Delka]

Основное преимущество и об этом уже много где говорилось — возможность управлять его длиной на уровне редактора не внося изменения в листинг кода.

Измените отступ:

[@Kaaboeld]

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

[@Delka]

Т.е. тратите время впустую. Если бы использовались только пробелы этой проблемы бы не было. Что и требовалось доказать.

[@alisey]

По правде, если бы использовались только табы, этой проблемы тоже не было бы.

[@Archy]

Да, были бы немного другие проблемы, но тем не менее это проблемы: www.prog.org.ru/index.php?topic=17796.msg119377#msg119377

[@dfuse]

Код-сниффер хуком на коммите спасает, чтобы не повадно было. Автоформат спасает так же. Вообще все равно, кто как наформатировал, если есть редактор, настроенный на определенный стиль (проектный или предложенный сторонней организации типа Zend, Google и т.д.), нормальный редактор все сам сделает.

P.S. Дал бы ссылку на питоновский док, там доступно разжевано, но эта тоже хороша.

[@Kaaboeld]

Не хотелось бы начинать, а точнее продолжать начавшийся уже давно холивар, но…
Потеря времени в описанной мной схеме секунды, аналогичная той когда адепт пробелов врубал бы автоформатирование чтобы избавиться от табов или любой другой, чтобы просто привести код в очередной раз в в порядок.
Я привел довод — «возможность управления длиной» отступа. Представим ситуацию, а она надо сказать при работе с большими объемами кода встречается достаточно часто, отформатированный структурированный код с множеством уровней вложенности (должен ли быть код очень «глубоким» или нет — это совсем другой разговор, не касающийся данной темы) и есть желание не затрагивая его структуру вложенности быстро перестроить его в более компактном виде, чтобы видеть не только структуру, но и содержание блоков.
При использовании табов достаточно в редакторе выбрать оптимальный размер одного таба (1,2,3,4 и тд). Сколько займет времени и каким способом вы бы решили эту задачу пробелами?
Второй вариант есть набор строк отбитый пробелами, часть из них по два пробела некоторые по три — как выяснить без анализа кода является ли отступ в три пробела структурным (определяющим вложенность) или он сделан «чтобы было красиво»?

[@Delka]

По остальным пунктам замечаний нет? :)
Давайте без холивара про табы, а по существу code style.

В топике — не выжимка, а фигня какая-то. Лучше бы просто дали ссылки на спеки и обсудили.
Где например пожелание про использование px вместо em? А это важно для независимых блоков.

[@maddogrts]

Пишем код так: clip2net.com/s/2ekEe
Видимо это уже свой стандарт? Или был такой среди перечисленных?