Во время работы над последним проектом накопилось несколько интересных CSS-трюков, о которых хочу рассказать. Хотя, возможно, это уже придумано до нас и все об этом уже знают. В примерах используется LESS, а не чистый CSS.

Событие автоподстановки в инпут поля

Проблема: узнать, что пользователь воспользовался функцией автоподстановки. Задача была в том, чтобы подсвечивать кнопку Login, если в полях e-mail и password введено что-либо. Проблема в том, что если эти поля заполняются автоподстановкой из ключницы браузера, то событие change на инпутах не выстреливает.

Решение: использовать псевдокласс :valid. Он срабатывает у инпута, если в нем есть контент, который удовлетворяет типу инпута (text, e-mail) и если у этого инпута стоит атрибут required. Правда решение не работает в IE, но нам не требуется поддержка этого браузера.

<input required="required" class="email-input" type="email" />
<input required="required" class="password-input" type="password"/>
<div class="go">Login</div>

.email-input:valid ~  .password-input:valid ~ .go {
	//стили для активной кнопки Login
}

DerbyJs — реактивный фулстек javascript-фреймворк. О нем неоднократно писали на хабре — материалы по Derby. Буквально пару дней назад в репозитории Derby произошла смена основной ветки. Теперь версия 0.5 отошла на задний план, 0.6 — основная.

Не в традициях команды разработчиков заниматься пиаром — изменения произошли тихо и незаметно. А что же поменялось?

Если вам когда-нибудь приходилось разрабатывать форму регистрации или оформления заказа, то вы знаете, что для получения из формы качественных данных нужно прикрутить множество проверок для ФИО, почтовых адресов, e-mail, телефонов. При этом так уж исторически сложилось, что разработчики пишут код валидации информации каждый раз заново. Ну а потом эти проверки приходится еще и поддерживать, а на поддержку, как известно, приходится 80% усилий.

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

Так не должно быть.

При работе с информацией часто возникают задачи парсинга веб-страниц. Одной из проблем в этом деле является определение похожих страниц. Хороший пример такого алгоритма — «Алгоритм шинглов для веб-документов».

Часть проекта по парсингу реализована на Node.JS, поэтому и алгоритм нужно было реализовать на нем. Реализаций на javascript или npm-пакетов я не нашел — пришлось писать свою.

Всем привет, и ещё раз всех с прошедшими праздниками. Трудовые будни набирают обороты и вместе с ними растёт информационный голод мучающий нас. Мир разработки переднего конца не дремлет и готовит нам много сюрпризов в наступившем году, и уж поверьте мне, скучно не будет ни кому. Одна из новых особенностей которые нам готовят разработчики браузеров совместно с группами разработчиков пишущих спецификации — JavaScript Promises(далее в переводе — Обещания, прошу сильно не бить) — полюбившийся многим шаблон написания асинхронного кода обзаводится нативной поддержкой. Что же такое обещания и с чем их едят можно прочесть в нижеследующем переводе(слегка вольном) замечательной статьи Джейка Арчибальда.

Всем привет! Сегодня задача у нас следующая: необходимо создать интерфейс для загрузки картинок, который бы генерировал перед загрузкой превьюшки небольшого формата. На данный момент HTML5 вовсю шествует по планете, и, казалось бы, как это реализовать должно быть предельно ясно. Есть несколько русскоязычных статей на эту тему (вот, например). Но тут есть одно но. В рассматриваемом там подходе не уделено никакого внимания расходу памяти браузером. А расход может доходить до гигантских размеров. Разумеется, если загружать одновременно не более 5-10 картинок небольшого формата, то все остается в пределах нормы; но наш интерфейс должен позволять загружать сразу много изображений формата не меньше, чем у современных фотоаппаратов-мыльниц. И вот тогда-то свободная память начинает таять на глазах.

Вьювер файлов — приложение, представляющее данные файла в дружественной для пользователя форме. Вьюверы используются для просмотра документов без использования тяжеловесных программ-редакторов. В этой статье мы рассмотрим  вьюверы в рамках ЕСМ систем.

ECM (Управление корпоративным информационным контентом) — управление, хранение, обработка и доставка контента в масштабах предприятия. В соответствии с требованиями стандарта MoReq, электронные документы одинаково успешно должны открываться как в родном приложениях так и во встроенном вьювере. Однако для многих пользователей ЕСМ-систем именно вьювер является основным интерфейсом работы с документами. На данный момент существует множество форматов, с которыми работают ЕСМ системы, но по сей день удобного и универсального встроенного вьювера в данных системах нет. Почему?

Попробуем ответить на этот вопрос и предложить свои варианты решений

Медийный контент окупается по двум моделям – прямая плата за него пользователями и реклама. Ни к тому, ни к другому особой любви пользователи, понятно, не испытывают. Не случайно картинка с отзывами российских пользователей Google Play на музыкальное приложение Гугла стала мемом:



Что-то похожее пережили и мы на Sports.ru.

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

.hover .element:hover {
  box-shadow: 1px 1px 1px #000;
}

В каждой избушке — свои игрушки

До некоторого момента front-end разработчик при написании javascript кода, рассчитанного на взаимодействие с пользователем, ориентировался лишь на «мышиные» события. Затем появились различные устройства, которые использовали другие формы взаимодействия пользователя с приложением — сенсоры или перо. Типы событий для каждого устройства были предложены индивидуальные. Так, кроме mousedown, mousemove итд., появились touchstart, touchmove и другие события.

Такой подход требует наличия альтернативных функций для поддержки нового типа устройства. Это часто порождает проблемы несовместимости, если изначально приложение было расчитано на одно устройство. К тому же, текущие платформы, которые используют сенсорные события, так же реагируют и на некоторые «мышиные» события (например, mousedown) в целях обратной совместимости. Это делает неоднозначным использование таких мышиных событий, нет возможности определить с каким конкретно устройством работает пользователь. Кроме того, есть ряд серьезных отличий в работе мышиных событий на сенсорных устройствах:

• События мыши возникают только после сенсорных;
• Наведение мышью (mouseover) и другие аналогичные события не сработают без прикосновения к устройству. Обработчики таких событий должны быть запущены по умолчанию или их нужно заменить на событие 'click' по элементу;
• События по щелчку не будут запущены при изменении DOM дерева документа;
• События по щелчку срабатывают не сразу, а, приблизительно, через 300 мс;
• Touch и mouse события, в некоторых случаях, конфликтуют между собой.

В результате, front-end разработчику при написании приложения приходится обрабатывать несколько видов событий, события мыши на десктопных ПК и touch события для сенсорных устройств. Код становится громоздким, процесс разработки — трудоемким…

Асинхронность… Услышав это слово, у программистов начинают блестеть глаза, дыхание становится поверхностным, руки начинают трястись, голос — заикаться, мозг начинает рисовать многочисленные уровни абстракции… У менеджеров округляются глаза, звуки становятся нечленораздельными, руки сжимаются в кулаки, а голос переходит на обертона… Единственное, что их объединяет — это учащенный пульс. Только причины этого различны: программисты рвутся в бой, а менеджеры пытаются заглянуть в хрустальный шар и осознать риски, начинают судорожно придумывать причины увеличения сроков в разы… И уже потом, когда большая часть кода написана, программисты начинают осознавать и познавать всю горечь асинхронности, проводя бесконечные ночи в дебаггере, отчаянно пытаясь понять, что же все-таки происходит…

Именно такую картину рисует мое воспаленное воображение при слове “асинхронность”. Конечно, все это слишком эмоционально и не всегда правда. Ведь так?.. Возможны варианты. Некоторые скажут, что “при правильном подходе все будет работать хорошо”. Однако это можно сказать всегда и везде при всяком удобном и не удобном случае. Но лучше от этого не становится, баги не исправляются, а бессонница не проходит.

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

Привет Хабр! Примерно год назад я представил вашему вниманию первую версию open-source библиотеки FileAPI, предназначенную для работы с файлами на клиенте и последующей загрузки на сервер.

За это время был пройден долгий путь. Библиотека заработала 670+ звезд и 90+ форков. С помощью github-сообщества удалось исправить множество «детских» проблем и внести ряд улучшений. Было закрыто более 100 тасков, и благодаря Илье Лебедеву сделана загрузка файлов по частям. Сегодня я с гордостью хочу представить вам FileAPI 2.0.

На хабре уже проскакивала статья про такие замечательные вещи, как Map, WeakMap и Set, но в действительности реальные возможности этих API не были раскрыты (если я все-таки хорошо воспользовался поиском).
Эти API толком не реализованы нигде, кроме firefox (можно включить в chrome canary), но даже там до недавних пор не поддерживалось использование HTMLElement-подобных объектов в качестве ключей. Polymer, например, убрал только три недели назад

	if (navigator.userAgent.indexOf('Firefox/') > -1)

Чем же они так хороши? По сути Map/WeakMap можно воспринимать как обычные хэш-объекты, только в качестве ключей можно использовать только сложные объекты (Object, Function, Array), так как привязка идет не по содержимому, а по адресу в памяти.
Таким образом появляется возможность привязаться на фронтэнде к

• dom-элементу
• XHR-запросу
• File-элементу

Это дает нам возможность работать без id-шников элементов, делать дата-биндинг в разы быстрее, создать безумную альтернативную реализацию promises и так далее.
Мы будем говорить о WeakMap. Даже не так, мы будем говорить о существующих полифиллах для WeakMap.

Много людей знают, что такое getter'ы и setter'ы во многих языках программирования. Есть эти чудесные штуки и в JavaScript, хоть узнал я об этом совсем недавно (темень я необразованная). Речь пойдёт не только и не столько про методы getSomeProperty()/setSomeProperty(...), а про более интересную реализацию — псевдо-аттрибуты, при изменении которых будут вызываться функции-обработчики.

Вот этим навеяло habrahabr.ru/blogs/javascript/66242

Вопреки расхожему мнению ИЕ все таки умеет назначать аксессоры, правда только в VB, чего для некоторых задач вполне достаточно.

<script language="vbscript">
' Объявляем класс, экземпляр которого в последствии будем использовать из яваскрипта
Class Accessor
  Public Property Let hook(val)  ' объявляем сеттер для свойства hook класса Accessor
   MsgBox val
  End Property
End Class

Dim access ' объявление переменных в VB обязательно
Set access = New Accessor  ' создаем экземпляр класса Accessor
</script>

<script language="jscript">
// т.к. у VB и JS общее пространство имен, можно вполне использовать созданный ранее access
access.hook = 'ololo';
</script>

* This source code was highlighted with Source Code Highlighter.

Другими словами аксессоры есть в VB, VB есть во всех IE и пространство имен VB и JS общее, можно пользовать.

Проблема

Браузеры по политике безопасности разрешают открывать всплывающее окно, только, если пользователь непосредственно предпринял для этого какие-то действия. Например, этот код будет работать:

$("someElement").on("click", function(){
    window.open("http://yandex.ru")
}

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

А мы идем далее.

Безлимит

В конторе в которой я работаю появилась необходимость использования индексированной локальной базы данных на стороне клиента и выбор сразу пал на IndexedDB.

Но как всегда есть одно «НО», это самое «НО» — ограничение размера БД на машине пользователя в размере 5 МБ, что отнюдь нас не устраивало. Так как данная технология планировалась использоваться в админке нашего проекта и все юзеры использовали в качестве дефолтного браузера Google Chrome, то было принято решение поиска обхода того самого ограничение через расширение-прокси. Перелопатив много инфы мы пришли к выводу, что ограничение на размер БД можно убрать использовав специальные флаги в манифесте нашего расширения:

Быстрая и плавная загрузка изображений — это одна из немаловажных составляющих хорошего веб-интерфейса. Кроме того, появляется все больше сайтов, использующие крупные фотографии в дизайне, таким проектам особенно важно следить за корректной загрузкой графики. В этой статье описано несколько техник, которые помогут контролировать загрузку изображений.

Использование контейнера для каждого изображения

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

<div class="img_wrapper">
    <img src="comicbookguy.jpg" alt=""/>
</div>

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

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

Браузеры и стандарты. Вечная погоня. Из-за несоответствий стандартам, из-за разных способов рендеринга страниц большая часть времени веб-дизайнера уходит на то, чтобы загладить эти несоответствия (использовать хаки). В итоге, вместо эффективной работы, дизайнер вступает в противоестественные отношения с браузерами, теряя драгоценное время.