Как стать автором
Обновить

Комментарии 70

Вы используете исключительно ванильный CSS, без LESS, SASS, etc.?
Судя вот по таким штукам в документации, не только.
Конкретно на нашем проекте пока ванильный css, да. но CSSComb.js вполне умеет работать и c SASS/LESS
НЛО прилетело и опубликовало эту надпись здесь
Насколько я знаю в планах это есть: github.com/csscomb/csscomb.js/issues/159
Про сроки к сожалению ничего сказать не могу :(
Попробовал на less в своем проекте — очень красиво все сделало.
Что интересно, форматирует даже закомментированные свойства.
С SASS работает прекрасно.
С недавних версий вполне отлично дружит с Compass.
А у меня загнулось.
На переменных вначале файла где у меня цвета забиты ругается дальше не идет.
Убрал их, всю структуру стерло и отформатировало как обычный CSS.
Чего то не хватает.
А CSS отформатировало прекрасно, хотя вещается на комментариях начинающиеся с //
Абсолютно та же ситуация была. Проверьте, что ставите последний csscomb – ранние версии глючили с Compass. С версией 3.0.0-5 полет нормальный.
хм переключился на третью ветку, стало получше.
но на переменных все одно падает, пока не все тянет.
Ок, сейчас попробую локализовать проблемные места и закину.
Простая декларация переменных в SCSS, все остальное вроде работает на ура…

github.com/csscomb/csscomb.js/issues/275
`// comment` = невалидный комментарий для css, поэтому появляется ошибка парсинга.
Да, но блин часто используемый. Сейчас занимаюсь системой на JBoss, тут вебмастеров отродясь похоже не было, столько соплей и не валидной разметки я с прошлого века не видел.
Вот будут потихонечку все это переписывать и приводить к кошерному виду, пока все под Section 508 привожу.
Копаться в css — както неблагородно в наши дни.
Особенно, когда проект размером с самолет.

Для систематизации и оптимизации отлично подойдут функции, миксины и прочие крутые штуки, которые предалагает, например, LESS.
Использование препроцессоров не отменяет вопрос группировки и сортировки свойств. Опять-таки, нужно будет определить, где необходимо инклюдить те же миксины.
Имеется ли у вас общедоступный стайлгайд по стилям, который включает порядок свойств, вендорных префиксов, необходимые отступы?
Есть ли возможность обойти хук? В редких случаях такое нужно.
Можно было бы сделать через комментарий в начале файла вида /* @CSSComb ignore */
Если ты мегаотвественный и понимаешь что делаешь то ты можешь сделать.
git commit ololo --no-verify
Но вся отвественность за такое будет полностью на тебе.
по моему важно, чтобы этот коммит потом получил отлуп и на pre-receive хуке на сервере…
Часто бывает, что инструменты некорректно воспринимают код и ругаются, даже если он правильный. В этом случае у разработчика должна быть возможность сознательно обойти автоматическую защиту и закоммитить код.
Мы верим, что люди умнее программ :)
Почему AST имеет форму массива (а не объекта, как это сделано в Mozilla Parser API)?.
мб потому что простого списка достаточно?
Но ведь эта достаточность подчас стесняет.

Если есть объект, то доступ к свойствам его происходит по именам их, причём некоторые свойства могут быть не заданы. Если есть массив, то приходится помнить номер вместо имени и задавать все элементы, да ещё и в строгом порядке их.

Кроме того, в массивах хуже поддерживается обратная совместимость. Получается, что на будущее нельзя отказаться ни от одного из элементов массива без того, чтобы не принудить пользователей ставить на его место всегда «null» (или что-то другое в этом же дýхе) «по историческим соображениям».
это не просто массив, а синтаксическое дерево… вроде лиспа…
Повторяю первоначальный вопрос: почему AST (это сокращение означает «abstract syntax tree», так что я знал с сáмого начала, что это синтаксическое дерево) имеет форму массива, а не объекта?
Это больше вопрос к автору парсера: github.com/tonyganch/gonzales-pe.
Достоверно, почему сделанно именно так, я ответить не могу. Но всегда можно создать issue и спросить там.
Массивы — компактные и на порядок производительнее. У нас также есть один парсер, и там мы боримся с каждой мс. Сейчас у нас дерево через обьекты представлено, a вот однажды пытались на массивы перейти. И всё было очень здорово — с индексами было удобно работать через константы:
// INode [type:int, tag:string, attributes:object, nodes:array]
var tagName = node[pos_TAG];
var children   =  node[pos_NODES];

В конечном разультате код стал быстрее и после минификации стал меньше. Но пришлось отказаться — хотелось давать конечным пользивателям непосредственный доступ к дереву. А вот там ему уже эти индексы нужно помнить, ведь `pos_*` скрыты внутри библиотеки, а выносить как свойства наружу — усложнит простую работу с деревом.

Хотя заметили, что в csscomb другая структура используется: [KEY, VALUE] и такой подход немного перемешивает массивы с обьектами; как по мне — довольно не корректно.
Массив упорядоченный, а объект, вроде как, не обязательно?
Да.

Но является ли упорядоченность массива достоинством или недостатком?

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

Если свойство объекта выйдет из употребления, то достаточно перестать употреблять его — а если элемент массива выйдет из употребления, то всех пользователей новых версий придётся приучить на его место в массиве ставить «null» (или что-то другое в этом же роде) «по историческим соображениям», что и выглядит похуже, и время растрачивает.
В описанном случае достаточно ввести новый тип узла.
Есть ли какая-нибудь возможность задать такой формат?
.block {
    position: absolute;
}

Всё, что у меня получается, — это либо открывающая скобка на новой строке, либо закрывающая с отступом.
Попробуйте в конфигурации опцию space-before-opening-brace установить в " "
Уже пробовал. Никак не реагирует.
Извиняюсь, всё заработало. Нужно было указать "space-before-closing-brace": "\n", почему не срабатывало раньше — не понимаю.
Скажите, а зачем вы сами пишите вендорные префиксы, если есть такие прекрасные проекты, как autoprefixer?
Очень пристально на него смотрим и планируем использовать :)
Редко, но бывает, что какие-нибудь хитрые случаи приходится костылять явно.
Но в целом, конечно, Автопрефиксер прекрасен :)
По идее есть api для своих префиксов
«мог бы, к примеру, написать position: relative в начале блока свойств, незаметив что где-нибудь внизу между color и box-shadow, уже есть position: absolute, и долго гадать, почему у него ничего не работает» — было недавно
Вы в блокноте что ли стили пишете? Найдите редактор получше, который такое дело сразу видит и дает вам знать.
верните нумерацию выдачи в поиске
да, это понятно, $variable — переменные, $include — миксины…
но как обозначаются вложенные правила (селекторы)?
Вложенные правила сейчас никак не сортируются. Есть вот такая похожая задача: github.com/csscomb/csscomb.js/issues/210
Но если color входит в список sort-order, пустая строка должна была добавиться. Заведите таск, пожалуйста, я посмотрю: github.com/csscomb/csscomb.js/issues/new
Раньше на страничке проекта был плагин для Coda 2, сейчас вместо всего сайта просто заглушка. Скажите, где можно скачать плагин и планируется ли его поддержка в будущем?
На первую часть вопроса нашел ответ
Поддержка плагина для Coda 2 не планируется.
Вот вы описали случай, когда в одном блоке указаны 2 свойства position. В одном месте absolute, в другом — relative. Что сделает с этими свойствами CSSComb?
НЛО прилетело и опубликовало эту надпись здесь
А выведет ошибку или нет? Да ладно, что это я, сейчас просто сам возьму да и попробую.
Нет, это же не ошибка, а вполне себе валидный CSS-код.
Пишут ведь костыли вида "display: inline-block; display: inline;" для старых браузеров.
Код-стайл – это, конечо, важно, но что делать, если проблемы более глобальны?
Вот мне сейчас достался проект, где куча мертвого кода, костылей, переопределяющих всё и вся и прочей ереси. Я к нему подступиться боюсь.
Я незнаю инструмента который мог бы помочь в этой ситуации кроме кофе )
Много кофе и переверстать. :)
И сразу привить нормальный стиль.
Вобще, у меня есть ощущение, что если не следить за стилем, то CSS в помойку превращается раньше других частей и необратимее.
Очень спасает модульность. Когда кода много, он должен быть разбит на отдельные понятные куски. Например, по принципам БЭМ.
И чем модульность поможет от мертвых стилей?
По принципу сборки икеевской мебели: всё, что осталось лишним после сборки, можно выкинуть.
Если перетряхнуть старый код и разгрести на кучки, останутся лишние куски, которые с высокой вероятностью и окажутся лишними.
А как вы узнаете что лишнее? Вдруг у вас есть какая-то страничка, про которую все благополучно забыли, а эти стили там используются. Ну или какой-нибудь элемент на странице при определенных условиях принимает определенный стиль.
Ну я даже не знаю… Протестировать? :)
Для этого есть unit-тесты на скрипты и вёрстку, есть регрессионные авто-тесты.
В самом простом случае можно погрепать проект и поискать там упоминание оставшихся стилей.

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

Ну или можно пойти другим путем: сказать себе, что навести порядок невозможно, и уволиться ;)
Это когда она есть. А когда её нет, то не спасает… :)
Чтобы модульность спасла, её нужно внедрить. См. выше :)
Вот спасибо! Посмотрим.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий