Comments 88
Все правильно, и даже то что ничего нового :)
Тут упомянули про рефакторинг стилей. Хотелось бы увидеть кто чем пользуется.
И для тестирования тоже ( что в общем часть процесса рефакторинга обычно ).
Тут упомянули про рефакторинг стилей. Хотелось бы увидеть кто чем пользуется.
И для тестирования тоже ( что в общем часть процесса рефакторинга обычно ).
я недавно делал рефакторинг на самом моем большом проекте. пользовался тем же, чем и при разработке — Aptada + Zen conding, Firefox + Firebug
боже ж ты мой, что творится с речью, когда всю ночь правишь текст.
Aptana и Zen coding, конечно же
Aptana и Zen coding, конечно же
aptana и zen coding?
И что аптана умеет рефакторить стили?
например переименовывать селектор глобально по файлу или проекту или сливать/разделять классы?
автоматом проверять результирующие стили по DOM страницы?
И что аптана умеет рефакторить стили?
например переименовывать селектор глобально по файлу или проекту или сливать/разделять классы?
автоматом проверять результирующие стили по DOM страницы?
ну для меня рефакторинг это не столько простое переименование, сколько изменение внутренней структуры без изменения внешнего поведения, поэтому я переделывал все довольно основательно — с нуля, удалив много наркоманского лишнего кода, и уменьшив размер стилей втрое
Aptana на данный момент единственный IDE, который поддерживает максимум функционала Zen Coding. Остальные редакторы — лишь частично.
А что там кроме шорткатов и темплейтов?
Имхо это умеют все приличные IDE
Имхо это умеют все приличные IDE
Не во всех IDE есть встроенные темплейты для всех CSS3 свойств — fz -> font-size:, bd+ -> border: 1px solid # и т.д.
Привыкнув, уже невозможно писать иначе.
Не видел чтобы IDE умели разворачивать ul.class>li*2>a в
или оборачивать обычный текст
например
текст
меню
из макета
через ul.class>li*>a в
А в остальном Вы правы — ничего такого Zen coding и не умеет. Вещь в общем-то бесполезная.
Привыкнув, уже невозможно писать иначе.
Не видел чтобы IDE умели разворачивать ul.class>li*2>a в
или оборачивать обычный текст
например
текст
меню
из макета
через ul.class>li*>a в
- например
- текст
- меню
- из макета
А в остальном Вы правы — ничего такого Zen coding и не умеет. Вещь в общем-то бесполезная.
если честно нифига не понятно.
оборачивать в теги выделенный текст может даже tiny на WP :)
оборачивать в теги выделенный текст может даже tiny на WP :)
Espresso?
Notepad++ с ZenCoding plugin :)
Автор, что у вас за редактор на скриншотах?
notepad++?
Notepad++
в оригнале код подсвечен github-овским скриптом, у меня же возможность вставлять JS не было, а Source Code Highlighter пока не умеет показывать CSS.
пришлось выкрутиться таким вот образом
в оригнале код подсвечен github-овским скриптом, у меня же возможность вставлять JS не было, а Source Code Highlighter пока не умеет показывать CSS.
пришлось выкрутиться таким вот образом
s-c.me умеет CSS подсвечивать, хотя ваш вариант, тоже очень хорошо смотрится.
наверняка scintill'овский движок )
использую Scite-ru, кстати, замечательный редактор, при должной настройке
использую Scite-ru, кстати, замечательный редактор, при должной настройке
По-моему выводы из 3-го урока немного противоречат выводам из 1-го урока. Но в целом я с автором согласен, хотя и не строго следую правилам из последних 2-х уроков.
нет, противоречивого там нет. «сначала обобщенные, потом конкретные» не в плане появления в коде, а в порядке создания. тот же стиль для тега <p> может быть создан где угодно, но если написать для него класс, который перезапишет какие-то его свойства, то неважно где он будет указан — вес селектора по классу больше, чем вес селектора по тегу
У нас в проектах, после нарезки шаблона, всегда делаю как реккомендует урок 1…
А когда отдаю программистам на внедрение, они путаются, ругаются и всячески хотят, чтобы я делал «как не надо в уроке 1»…
Странно это всё… ))
А когда отдаю программистам на внедрение, они путаются, ругаются и всячески хотят, чтобы я делал «как не надо в уроке 1»…
Странно это всё… ))
Такой момент. Вечно пишут, что комментарии — это забота о том, кто будет разгребать код после вас (ну и о том, чтобы этот кто-то вас потом не отвлекал за советом). Мне кажется, более мотивирующим тут будет, что комментируемый код — забота о себе самом: когда вы взглянете на ваш код через месяцок-другой (особенно, если активно обращаться к нему в этот период не приходилось)…
Здорово, когда помнишь все нюансы стандартов наизусть, но если в редакторах других языков есть всяческие подсказки-помощники, то как обстоят дела с css? Помнится, пользовался TopStyle. Может кто-то юзает бесплатные (или менее дорогие) и не менее удобные аналоги?
UFO just landed and posted this here
Есть хорошая вещь, JetBrains WebStorm — www.jetbrains.com/webstorm
Что называется, «От создателей IntelliJ Idea!» :)
Перелез на неё с Aptana, лучше пока ничего не попадалась. Оно пока beta (но более чем юзабельно), поэтому бесплатно.
Что называется, «От создателей IntelliJ Idea!» :)
Перелез на неё с Aptana, лучше пока ничего не попадалась. Оно пока beta (но более чем юзабельно), поэтому бесплатно.
И Эклипс хорош, и, уверен, джетбрейнс, но хотелось что-нибудь попроще. Пишу по большей части в Notepadd++. Ставить ради «подцветки» и хинтов css перечисленных выше монстров… как-то страшно :-).
UFO just landed and posted this here
Попроще это только если нужно поправить что-то в уже существующем коде или если для вас это скорее хобби, а не работа.
Такие «монстры» в комплекте предоставляют огромное количество незаменимых утилит, которые позволяют автоматизовать рутинные процессы и очень сильно сэкономить время и силы при каждодневном использовании.
Такие «монстры» в комплекте предоставляют огромное количество незаменимых утилит, которые позволяют автоматизовать рутинные процессы и очень сильно сэкономить время и силы при каждодневном использовании.
За что человека минусуют — за то что высказал свое мнение?
В вебшторме куча мелочей, на первый взгляд очевидных, но отстутствующих в Аптане — переход к css-объявлениям при клике на имя css-класса, css-рефакторинг, можно забыть про ctrl+s — сохранение при потере фокуса и т.д. и т.п. Заружается заметно быстрее.
Сам сидел на Аптане из-за Zen coding, но потом появилась нативная поддержка Zen coding в вебшторме и с каждым EAP все более и более полная.
В вебшторме куча мелочей, на первый взгляд очевидных, но отстутствующих в Аптане — переход к css-объявлениям при клике на имя css-класса, css-рефакторинг, можно забыть про ctrl+s — сохранение при потере фокуса и т.д. и т.п. Заружается заметно быстрее.
Сам сидел на Аптане из-за Zen coding, но потом появилась нативная поддержка Zen coding в вебшторме и с каждым EAP все более и более полная.
UFO just landed and posted this here
Ушел с NetBeans на Eclipse из-за отсутствия поддержки ZendDebugger. Хотя со временем пришлось отказаться и от ZendDebuggera, из-за отсутствия его под FreeBSD, все равно остаюсь на Eclipse, по причине наличия большого количества полезных расширений, нежеле в NetBeans'e.
Извините, а можно примеры полезных расширений?
Просто использую NetBEans и наверное чего-то не знаю. Вдруг тоже на Эклипс полезу…
Просто использую NetBEans и наверное чего-то не знаю. Вдруг тоже на Эклипс полезу…
UFO just landed and posted this here
Ну у меня стоит:
Epic — редактирования Perl в Eclipse. Для NetBeans ничего для перл, кроме «подсветки синтаксиса» я и не нашел.
MyLyn — для связи с JIRA. Да, в NetBeans оно работает по умолчанию.
Subversive SVN Connector — Как видно для работы с SVN репозитарием. Для NetBeans есть расширение для SVN, но я с ним тогда еще не сталкивался, так как в те времена еще не познал всех прелестей SVN.
Пара расширений для Preview HTML и CSS.
Кстати очень важный аспект — при использовании в NetBeans CSS редакторе IE хака "//" весь CSS становится невалидным и нельзя сделать предпросмотр стиля. Это в свое время очень напрягало.
Ну и в Eclipse мне очень нравится Outline для навигации по любым структурам. Не знаю был/есть ли такой в NetBeans.
Если кто-то решит корить меня по поводу использования IE хака, то могу сказать, что это пройденный этап, и я решил генерировать индивидуальные стили для каждого из браузеров. Потому что зачастую для WebKit Chrome/Safari приходится так же прописывать что-то индивидуальное. Хотя может просто еще руки кривые.
Epic — редактирования Perl в Eclipse. Для NetBeans ничего для перл, кроме «подсветки синтаксиса» я и не нашел.
MyLyn — для связи с JIRA. Да, в NetBeans оно работает по умолчанию.
Subversive SVN Connector — Как видно для работы с SVN репозитарием. Для NetBeans есть расширение для SVN, но я с ним тогда еще не сталкивался, так как в те времена еще не познал всех прелестей SVN.
Пара расширений для Preview HTML и CSS.
Кстати очень важный аспект — при использовании в NetBeans CSS редакторе IE хака "//" весь CSS становится невалидным и нельзя сделать предпросмотр стиля. Это в свое время очень напрягало.
Ну и в Eclipse мне очень нравится Outline для навигации по любым структурам. Не знаю был/есть ли такой в NetBeans.
Если кто-то решит корить меня по поводу использования IE хака, то могу сказать, что это пройденный этап, и я решил генерировать индивидуальные стили для каждого из браузеров. Потому что зачастую для WebKit Chrome/Safari приходится так же прописывать что-то индивидуальное. Хотя может просто еще руки кривые.
Мне тоже из всего (специально переберал, пробовал) тоже более всего NetBeans по душе пришёлся. Может на навороты для PHP-разработок он бедноват, но EclipsePDT/Zend по сравнению с ним какими-то неуклюжеватыми показались. О WebStorm сейчас впервые узнал, попробую. NotePad++ через Total Commander по F4 исполюзую для быстрого подравления и каких-то манипуляций.
Интересно, а какие советы можно получить по поводу оптимизации CSS стоит ли для продакшена, убирать все коменты, записывать все свойства в одну строку, тем самым снижая размер CSS файла?
webo.in/articles/habrahabr/14-minifing-css/ исчерпывающая статья
UFO just landed and posted this here
UFO just landed and posted this here
Юрий Ткаченко писал в блоге Яндекса про абсолютно независимые блоки и подход с сокращением наименований классов. Утверждают, что добились прироста в скорости отрисовки страницы до 100% в ие6-7.
Как же коробит от стилей с отступами и каждым свойством на новой строке. Это наглядно и удобно лишь в документации и в небольших стилях. Но когда правил десятки, то читать файл невозможно. При чтении файла ищется конкретный селектор, а не свойства, поэтому гораздо удобнее, когда эти селекторы отсортированы по смыслу и идут друг под другом — сразу все видно. А уж конкретные свойства посмотреть — можно и горизонтальным скроллом воспользоваться, ничего в этом страшного. Тем более далеко не всегда свойств у селектора много.
не могу согласиться. Хотя бы потому, что при одной опечатке парсер пропустить всю строку, и будете ездить по все простыне горизонтальным скроллом. Выделение так не удобно делать — если курсор слетает на другую строку, которая закончилась раньше, то скролл может сдвинуться, ну и т.п.
Это все ерунда, по сравнению с тем, что файл просто становится не читабельным. В случае с нормальной IDE это не актуально, но далеко не во всех случаях удобно ее использовать.
Вы считаете, что на втором скрине в статье верхняя половина кода более читабельна чем нижняя?
Во второй половине, независимо от количество правил, свойства всегда будут на одном и том же уровне. Если же вытянуть правило в одну строку — свойства будут начинатся неизвестно где.
Тоже самое с именами правил — последнее правило в строке будет найти не так уже легко.
.class, .other-class > ul, .another-class ol li{… }
Во второй половине, независимо от количество правил, свойства всегда будут на одном и том же уровне. Если же вытянуть правило в одну строку — свойства будут начинатся неизвестно где.
Тоже самое с именами правил — последнее правило в строке будет найти не так уже легко.
.class, .other-class > ul, .another-class ol li{… }
Да, верхняя половина более читабельна.
Да по барабану, где будут начинаться свойства. 90% времени при чтении файла уходит на поиск и анализ объявленных селекторов, а не их свойств. Если я определился, какой селектор мне нужен, то большая часть работы уже сделана. Дальше я уж как-нибудь в этой строке найду, где там отступы задаются или шрифт. И заданные свойства мне интересны только в контексте выбранного селектора, мне незачем их сравнивать с со свойствами других селекторов (за редким исключением при оптимизации).
Да по барабану, где будут начинаться свойства. 90% времени при чтении файла уходит на поиск и анализ объявленных селекторов, а не их свойств. Если я определился, какой селектор мне нужен, то большая часть работы уже сделана. Дальше я уж как-нибудь в этой строке найду, где там отступы задаются или шрифт. И заданные свойства мне интересны только в контексте выбранного селектора, мне незачем их сравнивать с со свойствами других селекторов (за редким исключением при оптимизации).
вам нужно сделать рефакторинг и не страдать больше хернёй 90% времени
Рефакторинг чего? Чужого кода? Речь вроде шла не о конкретном проекте, а вообще о стиле написания. Или вы мне предлагаете сразу начать делать рефакторинг всех моих проектов — прошлых и будущих? Спасибо, добрый человек.
Знаете, задачи разные бывают. Не всегда проекты делаются с нуля. Бывает, что заказчик обращается за доработками с кодом, который ему делали другие. Мне ему сразу предлагать сдеать рефакторинг за n*10 часов, при том, что сама задача может занять только n часов?
В общем для многих это дело привычки, доказывать что-то бессмысленно.
Знаете, задачи разные бывают. Не всегда проекты делаются с нуля. Бывает, что заказчик обращается за доработками с кодом, который ему делали другие. Мне ему сразу предлагать сдеать рефакторинг за n*10 часов, при том, что сама задача может занять только n часов?
В общем для многих это дело привычки, доказывать что-то бессмысленно.
конечно, лучше умножать говнокод ;-)
Причем тут говнокод? Только из-за того, что стиль написания другого человека не совпадает с вашим, вы готовы его оскобрить и обвинить в написании говнокода?
если 90% ремени тратится на поиск правила — значит это говнокод
90% при чтении файла (т.е. не когда вы код пишете, а когда вам нужно что-то исправить, как правило в чужом коде или в старом проекте, к которому вы давно не возвращалиь). И потом проценты — это величина относительная. В абсолютных величинах при работе с однострочными селекторами у меня 90% составляют, допустим, 1 минуту, а с красиво отформатированными «не говнокодерскими» — 3 минуты, при этом кто-то скажет, что это составило всего лишь 10% времени от чтения файла (непонятно, только, на что ушли остальные 90% — на любование красотой и изяществом?)
уф, а не проще нажать Ctrl+F?
Далеко не всегда. Ctlr-F не даст представления о том, какие селекторы объявлены и куда лучше дописать правило.
Форматированный файл обычно на 10 экранов бывает. В то время как однострочные селекторы вполне могут уместиться на одном экране, что дает целостную картину о стилях.
Форматированный файл обычно на 10 экранов бывает. В то время как однострочные селекторы вполне могут уместиться на одном экране, что дает целостную картину о стилях.
статья о том, как лучше оформлять свой код. если вам попался чужой код, да еще и говняный, то не надо ругать автора, который проповедует просто другую идеологию. по которой, кстати, наплевать, где находится селектор. что дает возможность вбить его в Ctrl+F и получить максимум пару совпадений.
фолдинг спасёт отца русской демократии
по поводу комментов.
в третьем примере многострочный русскоязычный коммент.
разве это не приводит к проблемам во всеми любимом браузере?
в третьем примере многострочный русскоязычный коммент.
разве это не приводит к проблемам во всеми любимом браузере?
никак не могу понять прикол записи правил по алфавиту, почему бы не задать сначала шрифтовое описание, затем отступы и позицирование, бекграунды и тд?
иначе получается для того, чтобы задать width и height и position нужно первую строку писать где-то вверху, следующую в конце и позицию в середине столбика параметров. Также и редактирование, добавил педдинга, убрал ширины, снова скачешь по всему столбику.
имхо куда приятнее:
.stylename{
font-style: italic;
font-weigt: bold;
width: 50px; height: 100px;
position: absolute;
top: 0; left: 20px;
}
нежели:
.stylename{
font-style: italic;
font-weigt: bold;
height: 100px;
left: 20px;
position: absolute;
top: 0;
width: 50px;
}
имхо, это все равно, что читать описание мобильного телефона на сайте и видеть его ширину вверху страницы, толщину — по середине, а высоту- внизу.
иначе получается для того, чтобы задать width и height и position нужно первую строку писать где-то вверху, следующую в конце и позицию в середине столбика параметров. Также и редактирование, добавил педдинга, убрал ширины, снова скачешь по всему столбику.
имхо куда приятнее:
.stylename{
font-style: italic;
font-weigt: bold;
width: 50px; height: 100px;
position: absolute;
top: 0; left: 20px;
}
нежели:
.stylename{
font-style: italic;
font-weigt: bold;
height: 100px;
left: 20px;
position: absolute;
top: 0;
width: 50px;
}
имхо, это все равно, что читать описание мобильного телефона на сайте и видеть его ширину вверху страницы, толщину — по середине, а высоту- внизу.
каскад — зло. его лучше стараться минимизировать
первое правило — требует уточнения!
Автор видимо пытается донести идею о том что нужно устанавливать в базовых стилях тот внешний вид, что идёт по всему сайту,
но выбрал плохой пример для этого.
За стили типа p {font-size: 0.75em} — надо руки отрывать, я лично отрываю)
Самый простой пример почему: будет у вас на сайте, на страничке редактируемой из визига, такой код:
Всё, приплыли, размер шрифта у текста внутри абзаца и просто в блоке будет разный!
Автор видимо пытается донести идею о том что нужно устанавливать в базовых стилях тот внешний вид, что идёт по всему сайту,
но выбрал плохой пример для этого.
За стили типа p {font-size: 0.75em} — надо руки отрывать, я лично отрываю)
Самый простой пример почему: будет у вас на сайте, на страничке редактируемой из визига, такой код:
<div class="some-block-from-wysiwyg"> <p>Lorem ipsum...</p> Lorem ipsum </div>
Всё, приплыли, размер шрифта у текста внутри абзаца и просто в блоке будет разный!
UFO just landed and posted this here
это не поможет,
вот пример того, о чём я говорю.
да и писать костыли на многих страницах ни к чему, лучше не создавать проблем изначально.
вот пример того, о чём я говорю.
да и писать костыли на многих страницах ни к чему, лучше не создавать проблем изначально.
UFO just landed and posted this here
речь о том что юзер через визиг может вставить текст и без абзацев, копипастом например.
да и не в визиге дело, вместо текста вне абзаца может быть текст внутри списка, текст внутри span, им получается чтож теперь тоже размер задавать? :)
но главный факап — изменение размера шрифта абзаца при помещении его в блок, которому задан какой-то font-size. Всё внутри этого блока будет с одним font-size, а абзацы — с другим.
да и не в визиге дело, вместо текста вне абзаца может быть текст внутри списка, текст внутри span, им получается чтож теперь тоже размер задавать? :)
но главный факап — изменение размера шрифта абзаца при помещении его в блок, которому задан какой-то font-size. Всё внутри этого блока будет с одним font-size, а абзацы — с другим.
Можно поинтересоваться, а что это за редактор кода?
Я бы обязательно упомянул про технику верстки абсолютно-независимыми блоками. Когда проект реально большой и верстают много людей, то без этого ОЧЕНЬ трудно.
Кстати комментарии в цсс желательно писать на английском, т.к лично в своём опыте встречал проблемы в вёрстке из- за этого. Соответственно дзен заключатеся не только в красивом и грамотном оформлении и написании цсс стилей, но и в постоянном развитии и совершенствовании, в том числе и в английском.
Sign up to leave a comment.
Искусство и дзен написания CSS