Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

PourOver

Библиотека для реально быстрой фильтрации и сортировки огромных коллекций, где речь идет о сотне тысяч элементов. PourOver построен на идеально простых запросах, которые могут произвольно формироваться друг с другом. Вы сможете объединять, скрещивать и разделять запросы. PourOver будет помнить как были построены ваши запросы и по-умному обновлять их, если появятся новые элементы или будут изменены старые. Работает на IE7+, Firefox 4+, Safari 5+, Opera 9+, Chrome 1+.

Стоит также заметить, что это проект от New York Times, на корпоративном Гитхабе которого есть еще популярный backbone.stickit плагин для датабиндинга и Tamper — serialization protocol for categorical data. В последнее время гики из западных СМИ прямо раскочегарились — вот недавно я писал про классные проекты от The Guardian и Financial Times.

Отличная подборка, как нарисовать различные геометрические фигуры одним элементом HTML.

Квадрат

#square {
	width: 100px;
	height: 100px;
	background: red;
}

Недавно Крис Койер отвечал на вопросы читателей Smashing Magazine. Один из вопросов был о том, как распознать код CSS с «душком»:

Как можно определить, что ваш CSS пованивает? Какие признаки указывают на то, что код неоптимален или что разработчик писал его спустя рукава? На что вы смотрите в первую очередь, чтобы определить, плох или хорош код?

Я подумал, что могу расширить и дополнить ответ Криса исходя из собственного опыта.

Я работаю в BSkyB. Я делаю большие сайты — над последним из них я тружусь уже больше года. Плохой код CSS доставляет мне очень много проблем. Когда занимаешься одним сайтом месяцами, ты просто не можешь себе позволить плохой код, и его обязательно надо исправлять.

Я хочу поделиться несколькими вещами, на которые я обращаю внимание прежде всего, чтобы составить впечатление о качестве, сопровождаемости и чистоте кода CSS.

Несмотря на то, что история космонавтики насчитывает чуть менее 60 лет, чтобы рассказать обо всех мало-мальски не рутинных событиях произошедших в космосе и на Земле не хватит и сотни толстых книг. И сегодня я хотел бы рассказать об одном из таких происшествий, которое на сегодняшний день незаслуженно забыто. И большая доля вины за это лежит на идиотской практике советских секретчиков закрывать и выхолащивать все, что связано с космосом. Во время этого полета ТАСС сообщало, что все идеально. Космонавтов во время режимов телесвязи шедших в эфир просили врать прямо в камеру, о том, что все в порядке, а уже через год, на волне перестройки об этой истории написали в крупном журнале «Наука в СССР». (UPD. Мой косяк, впервые об этом было написано 4 августа 1985 года, в газете «Правда», в статье конструктора и летчика-космонавта Константина Феоктистова «Мужество „Памиров“»).

Орбитальная станция Салют-7, которая была предшественником легендарной станции «Мир» была запущена 19 апреля 1982 года. 11 февраля 1985 года станция, уже несколько месяцев, находившаяся в автономном полете перестала выходить на связь с Землей. После долгих споров было решено предпринять попытку спасти станцию.

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

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Введение

Уважаемый читатель, данная статья является по сути своей продолжением статьи «Как сверстать веб-страницу. Часть 2 — Bootstrap» и здесь мы отойдём от собственно вёрстки, занявшись интеграцией HTML шаблона в CMS 1С-Битрикс.

В предыдущей части Хабраюзер Mirantus сверстал шаблон Corporate Blue от студии Pcklaboratory с помощью Bootstrap 3.

Введение

Я работаю веб-дизайнером. Какое-то время назад я подрабатывала фрилансером, сейчас работаю в небольшой студии. У нас нет менеджера проектов, поэтому, зачастую, я сама выступаю этим самым менеджером, по совместительству. Опыт общения с самыми разными заказчиками у меня достаточно большой. Статья «Краткая инструкция по работе с web-дизайнером (для менеджера проекта)» вызвала у меня шквал эмоций и бурю негодования, потому что именно таких заказчиков я всегда старалась избегать. В этой статье я попробую описать, как в идеале должна проходить работа заказчика и дизайнера.

С удовольствием приму критику и выслушаю мнения «другой стороны».

У меня достаточно неплохой опыт в верстке — несколько лет.
За это время было многое — и табличная верстка, и собственные фреймворки, и IE6, и адаптивный дизайн, да что угодно — я всегда старался быть рядом с bleeding edge, как говорится.
Больше CSS-фреймворков (привет, бутстрап) и Emmet-а мне нравятся препроцессоры и я расскажу, почему. Возможно, покажется, что моя статья несколько устарела и сейчас все используют препроцессоры как само собой разумеющееся, но, увы, это не так. Недавно я встретил человека, который говорил о том, что ему быстрее писать CSS-код, нежели использовать препроцессоры. Мы долго спорили, на самом деле, ну очень долго, в итоге я решил выложить свои мысли здесь, в одном месте.

Less или Sass?

Ну, на самом деле, это дело каждого. Мне не нравился Sass из-за его медлительности — Less побыстрее выполнялся всегда, в итоге в один момент я решил перейти на Less, но через некоторое время оказалось, что мне не хватает его мощности! Увы, я так и не нашел, как реализовать банальный миксин уровня вот этого.
Но и медлительность Sass не устраивала, но именно в тот момент, когда я хотел обратно вернуться на Sass, но терзался сомнениями, мне посоветовали libsass, а т.к. я использую Grunt — мне было достаточно подключить только grunt-sass (и ничего больше, например, установка Ruby и гемов). Для меня выбор был ясен и с тех пор — только libsass. Мощность самого Sass и с скорость C — что еще нужно?
Stylus я пока не пробовал, как-нибудь потом.

Почему все-таки препроцессоры?

Я не скажу ничего нового, скорее всего, но я хочу показать, почему стоит использовать препроцессоры.