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

   <div id="block_outer">
      <div id="block_inner"></div>
   </div>

А теперь представьте, что к блоку #block_outer привязано событие onClickOuter, а к блоку #block_inner, соответственно, событие onClickInner. И ответьте на вопрос, как сделать так, чтобы при клике на блок #block_inner, событие onClickOuter не вызывалось? И будет ли оно вообще вызвано? И если будет, то в каком порядке события будут вызываться? И знаете ли вы, как работает метод jQuery.live или подобные в других библиотеках (events delegation в ExtJS, например)?

Для проверки текстовых полей на валидность обычно используют регулярные выражения. Существует несколько наиболе распространенных видов таких даных, как например номер кредитки, дата в определенном формате и т. д. На сайте html5pattern.com собирается коллекция регулярных выражений для таких данных (там это позиционируется, как возможное содержимое html5-атрибута pattern у inpit-элементов, но эти регулярные выражения можно использовать и для привычной валидации с помощью javascript). Актуальные для российской аудитории примеры, вместе с соответствующими регулярными выражениями вы можете посмотреть под катом.

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

Ведь если сверстано на таблицах, с пустыми gif'ами для отступов — результат «монолитный», но не дай бог такое редактировать контент-менеджеру. Моментально всё поедет, да и не умеют нормально визивиги работать с таким ужасом.

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

Данная статья является вольным переводом. Оригинал тут.

Введение

Думаю, ни для кого не секрет, что клиентские приложения в современных веб-сервисах становится все сложнее и количество JS кода в них растет. До недавнего времени архитектура клиентской части, как правило, разрабатывалась с нуля и была специфична для каждого проекта. Не удивительно что приходилось снова и снова сталкиваться с типичными задачами.
К MVC-фреймворкам на серверной стороне все уже привыкли, но JS код на клиенте часто бывает плохо структурирован.

Предлагаю ознакомиться с решением на базе backbone.js, underscore.js и jQuery, которое поможет решить эту проблему.

Постановка задачи

Каким бы мы хотели видеть наше приложение? Вот основные моменты, которые мне кажутся важными:

1. Должен быть удобный способ описать модели нашей предметной области.
2. Любые изменения в модели должны немедленно отражаться в пользовательском интерфейсе, если модель в нем представлена каким-либо образом.
3. Понятная и легко-поддерживаемая структуризация кода в стиле MVC.

Попробуем решить эти задачи на примере простого приложения «Каталог фильмов».

Введение

Предлагаю Вашему вниманию обзор посвященный оптимизации изображений формата PNG и JPEG без потери качества. Под «без потери качества» подразумевается, что визуально оригинальные и оптимизированные изображения ни чем не будут отличаться. Я читал на Хабре довольно много статьей посвященных данному вопросу, но скажу, большая часть — полная чушь, в них констатируются факты, а не причины. Данный обзор посвящен людям, которые имеют базовые знания об оптимизации изображений.

Backbone.js это каркас для создания RIA JavaScript приложений, его автором является Jeremy Ashkenas, создатель CoffeeScript, Backbone является частью компании Document Cloud ей же «принадлежит» Underscrore.js. Backbone — очень легкая библиотека, помогающая вам создавать интерфейсы. Она может работать с любыми библиотеками, к которым вы привыкли.

Backbone это набор классов, размером менее 4Кб, которые формируют структуру вашего кода и помогают создавать качественные MVC веб-приложения.

Backbone формирует структуру тяжелых JavaScript приложений, внесением моделей с key-value подобным хранилищем и своими событиями, коллекций с богатыми API, видов (ориг. views) с декларативной обработкой событий и соединяет все это в в одно приложение, поддерживающее RESTful JSON интерфейс.

Backbone не может работать без Underscore.js. Для поддержки REST API и работы с DOM элементами в Backbone.View настоятельно рекомендуется подключить json2.js и jQuery-подобную библиотеку: jQuery или Zepto

В статье будет рассмотрена структура Backbone.js, будет поэтапно создано простое Todo приложение.

Совсем недавно (3 мая) был зарелизен jQuery 1.6 и вот что нового появилось в этой js-библиотеке давайте и посмотрим.

Самое «веселое» то, что в новом релизе есть важные изменения, которые несовместимы с предыдущими версиями jQuery. И в результате при переходе на новую версию, вполне возможно, что придётся просматривать и изменять уже существующий код.

С каждым днем новые стандарты css3 и html5 всё более глубоко входят в жизнь верстальщиков и web-разработчиков, а браузеры с каждым днем становятся все более совместимыми с этими стандартами.



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

CSSO (CSS Optimizer) является минимизатором CSS, выполняющим как минимизацию без изменения структуры, так и структурную минимизацию с целью получить как можно меньший текст.
CSSO написан на Javascript, выполняется как в браузере, так и в командной строке (с помощью NodeJS).
Распространяется под лицензией MIT.

Практически все Javascript-программисты пользуются консолью в браузерах. Консоль встроена в Хром, Оперу, IE и устанавливается с Firebug в Фоксе.
Но у неё есть пару неудобств, которые можно очень легко исправить. Это:

• Ошибки, когда консоль не определена
• Невозможность использовать вне контекста
• Невозможность отключить во время production
• некроссбраузерность

Исправим эти проблемы легко и быстро!

PhantomJS это все плюшки WebKit из консоли с управлением на JS и поддержкой различных стандартов и технологий: DOM, CSS, JSON, Canvas и SVG.

Внутри несколько примеров использования

Фреймворк Cappuccino – уникальная технология, позволяющая создавать веб-приложения десктопного качества. Он абстрагирует DOM и вместо него предоставляет Cocoa-подобный API. Вместо того, чтобы возиться с CSS-версткой и кроссбраузерными проблемами, вы используете интерфейсы, специально созданные для разработки приложений, а не статических страниц, интерфейсы, взятые с платформ Mac OS X и iOS.

Я заметил, что на русском языке почти нет обучающих материалов о Cappuccino, и решил восполнить пробел. Этот очерк рассчитан на то, чтобы прочитав его, можно было сразу приступать к разработке своего первого Cappuccino приложения. Я познакомился с фреймворком, когда искал средство для реализации онлайновой среды разработки для своего проекта Akshell. Мне нужно было сделать полнофункциональную IDE, работающую в окне браузера, и Cappuccino отлично справился с поставленной задачей.

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

Большинство примеров кода не привязаны к какому-либо конкретному языку программирования, но для наглядности я буду использовать PHP.

Итак, поехали.

Метод console.log() — отличный способ вывести отладочную информацию, не мешая пользователю. Но знаете ли Вы, что объект console имеет еще уйму других не менее полезных методов? Очень редко разработчики используют этот функционал, ограничиваясь неблокирующим alert'ом. Что-ж, давайте исправим это положение.

Вы 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 на сайте.

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

Каганов, под псевдонимом LLeo, также давным-давно действует в Фидонете (где был модератором эхоконференции «OBEC.PACTET», например) и в Интернете (где является автором собственного блога на собственном же движке, код которого он открыл в декабре 2009 года).

В апреле 2010 года я бегло упоминал на Хабрахабре, что LLeo объявил о своём намерении сочинить такую собственную WebBBS, которая работала бы поверх PHP-эхопроцессора PhFiTo, сочинённого Алексом Кочариным. Поэтому считаю возможным сегодня вернуться к этой теме и рассказать, что к началу января нынешнего года LLeo исполнил своё намерение (а для Кочарина это стало толчком к некоторому дальнейшему развитию PhFiTo, если судить по его CVS). Новая WebBBS, работающая на основе AJAX, выложена по адресу http://lleo.aha.ru/fido и продолжает неспешно дорабатываться.

Отличительной особенностью этой WebBBS является автоматическая обработка сырых URLов «http://», попадающихся в тексте отображаемой фидопочты. Адреса, заканчивающиеся расширениями файлов изображений, заменяются теми картинками, на которые они ссылаются. Адреса, ведущие на видеохостинги (например, YouTube), приводят к появлению видеопроигрывателей, а адреса MP3-файлов — к появлению звукопроигрывателей. И так далее.

И снова здравствуйте!

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

Прежде всего хотелось бы заострить внимание на одном из персонажей, который часто употребляется в топике — это «различные веб-интерфейсы и почтовые клиенты». Немного нудно каждый раз повторять эту конструкцию слов, и мне кажется, что будет проще дать этому одно обобщающее слово. И так читая дальше воспринимайте слово «Демоны»(по другому их трудно назвать), как «различные веб-интерфейсы и почтовые клиенты». Ну что ж, начнем!

Здравствуйте, этим постом я хотел бы попытаться приблизить светлое будущее, в котором все используют «кошерную» кодировку UTF-8. В частности это касается наиболее близкой мне среды – веба и языка программирования – PHP, а в конце серии мы подойдём к практической части и разработаем ещё одну велосипедную библиотеку.

Под катом — описание восьми сервисов, которые могут заметно облегчить жизнь веб-разработчика, верстальщика или дизайнера.

Введение

Плагин jQuery Templates – это «движок шаблонов», работающий на стороне клиента как расширение jQuery.

Этот плагин помогает показать в браузере данные, которые находятся в объектах и массивах JavaScript, избавляя вас от рутинных операций по созданию HTML-кода, экранированию специальных символов и т.п. Кроме того, он обладает очень интересными возможностями – например, позволяет обновлять созданный с его помощью HTML-код при изменении исходных данных.

Разумеется, jQuery Templates – не единственный и не первый «движок шаблонов», но у него есть большое преимущество перед альтернативными вариантами – поддержка со стороны jQuery Team. Это позволяет нам не бояться того, что этот плагин окажется заброшенным, и различные проблемы, возникающие при выходе новых версий браузеров, придется решать своими силами.

В этой статье я расскажу об основных возможностях jQuery Templates и продемонстрирую его работу в различных сценариях, а в последующих статьях я расскажу о функциях, не вошедших в основной код плагина (jQuery Templates Plus) и о расширении языка шаблонов.