Я собрал статистику по частоте использования свойств вебмастерами, font-size — 1.72% вхождений, font-style — 0.06%.
А как эти данные должны мне помочь получить желаемый результат? :)
Для bdr стоит статическое исключение, по алгоритму оно раскрывается в border-radius (из-за частоты 0.77 против 0.29 у border-right).
Но почему тогда bdr сейчас раскрывается в border-right: 1px solid;?
«Угадай что появится» есть первые 10 минут работы.
Не соглашусь. За первые 10 минут можно спокойно изучить основной набор статических аббревиатур, а всё остальное писать с помощью стандартного автокомплита. Нечёткий поиск отлично работает для случаев, когда аббревиатуре соответствует ровно один результат. В остальных случаях это довольно длительный процесс проб, ошибок и в конечном итоге запоминания аббревиатур (зачастую неуклюжих), которые дают нужный результат.
Не понял про встроенный fuzzy search в ST2. Вам не хватает выпадающего списка?
Да, чтобы я мог сразу видеть, что получится в итоге.
Ну, раз уж на то пошло, то у Hayaku тоже есть проблемы.
Например, я хочу получить свойство font-style, пишу аббревиатуру fs, однако получаю font-size. Или хочу получить border-radius: пишу bdr, а получаю border-right.
В итоге фича «пиши что хочешь» превращается в игру «угадай, что сейчас появится». И в этом плане статические аббревиатуры гораздо лучше, потому что их всегда можно увидеть и они всегда дают однозначный результат.
К тому же, в ST2 уже есть fuzzy search по вводимым CSS-свойствам (который Hayaku зачем-то удаляет) с визульным фидбэком, чтобы пользователь всегда видел, что сейчас появится.
Сам ST2 можно легко настроить таким образом, чтобы после ввода символа { после селектора автоматически добавлять закрывающий } с нужным форматированием и позицией курсора:
Ничего не мешает. Лично я считаю, что для вёрстки статического макета, из которого потом будут сделаны шаблоны, поднимать целое окружение с препроцессорами и тестовыми данными как-то уж слишком избыточно.
Тут вы уже путаете шаблонизацию и написание кода. Zen Coding никогда не был и не будет шаблонизатором, его цель — предоставить удобные инструменты для работы с кодом, а не оформление вывода данных.
Проблема в низкой инф. плотности HTML — нужно просто сменить синтаксис и все проблемы решаться сами.
А можно просто пользоваться правильными инструментами и IDE :)
Лично для меня проблема препроцессоров заключается в сложности дебага конечного результата, особенно это касается всяких LESS/SASS
В Zen Coding есть куча функций для модификации кода, в том числе правильное удаление тэга (удаляется пара открывающий/закрывающий тэг и меняется отступ кода)
Тут каждый сам выбирает, что ему удобнее использовать :) Мне, например, удобнее разворачивать по табу. А в новой версии ZC разворачивание аббревиатур (вернее, само действие Expand Abbreviation) будет дополняться всякими контекстными плюшками, вроде преобразования короткой записи CSS-градиентов в полноценный кросс-браузерный набор правил.
С плагином для ST2 так было всегда. Есть два режима ввода аббревиатур: просто вводом аббревиатуры в редакторе и разворачивание по клавише Tab, либо вводом в специальной панели. Последнее является своего рода «killer feature», которая позволяет видеть результат сразу во время набора, а не разворачивать и смотреть, соответствует результат ожиданиям.
С N++ проблема не в самом Zen Coding, а в плагине, через который он работает: NppScripting. Поэтому всем пользователям N++ я рекомендую использовать Python-версию плагина, где таких проблем быть не должно: sourceforge.net/projects/npppythonscript/files/
bdra(border-radius) вместоbdrs(border-right-style)trnsform(transform) вместоtrf(transition-timing-function)bsha(box-shadow) вместоbsh(border-style:hidden;)con(content) вместоcn(cursor:none;)anam(animation-name) вместоan(animation:none)piev(pointer-events) вместоpoi(position)и т.д.
А как эти данные должны мне помочь получить желаемый результат? :)
Но почему тогда
bdrсейчас раскрывается вborder-right: 1px solid;?Не соглашусь. За первые 10 минут можно спокойно изучить основной набор статических аббревиатур, а всё остальное писать с помощью стандартного автокомплита. Нечёткий поиск отлично работает для случаев, когда аббревиатуре соответствует ровно один результат. В остальных случаях это довольно длительный процесс проб, ошибок и в конечном итоге запоминания аббревиатур (зачастую неуклюжих), которые дают нужный результат.
Да, чтобы я мог сразу видеть, что получится в итоге.
Например, я хочу получить свойство
font-style, пишу аббревиатуруfs, однако получаюfont-size. Или хочу получитьborder-radius: пишуbdr, а получаюborder-right.В итоге фича «пиши что хочешь» превращается в игру «угадай, что сейчас появится». И в этом плане статические аббревиатуры гораздо лучше, потому что их всегда можно увидеть и они всегда дают однозначный результат.
К тому же, в ST2 уже есть fuzzy search по вводимым CSS-свойствам (который Hayaku зачем-то удаляет) с визульным фидбэком, чтобы пользователь всегда видел, что сейчас появится.
{после селектора автоматически добавлять закрывающий}с нужным форматированием и позицией курсора:github.com/sergeche/emmet-sublime/issues/78#issuecomment-9738519
Я завёл у себя тикет под эту задачу: github.com/sergeche/zen-coding/issues/93
В основной релиз Emmet это не войдёт, возможно, в следующее обновление.
А можно просто пользоваться правильными инструментами и IDE :)
Лично для меня проблема препроцессоров заключается в сложности дебага конечного результата, особенно это касается всяких LESS/SASS
code.google.com/p/zen-coding/wiki/Actions
code.google.com/p/zen-coding/wiki/Filters
github.com/sergeche/zen-coding/wiki/Release-Notes
github.com/sergeche/zen-coding/wiki/New-features-of-Emmet