Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1862 сообщений
Cообщения с меткой

html5 - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Дайджест свежих материалов из мира фронтенда за последние две недели №220 (11 — 24 июля 2016)

Воскресенье, 24 Июля 2016 г. 21:43 (ссылка)

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы и интересные материалы из области фронтенда























Веб-разработка
CSS
Javascript
Браузеры
Новости и занимательное


Веб-разработка





CSS





JavaScript





Браузеры





Новости и занимательное





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



Дайджест за прошлую неделю.

Материал подготовили dersmoll и alekskorovin.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306306/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Уведомления в браузере и пример того, как их можно использовать с пользой

Четверг, 21 Июля 2016 г. 15:39 (ссылка)





Вероятно, вы все уже слышали про технологию «Веб-push» в составе Push API и Notifications API. Я уверен, что среди вас есть те, кто возлагает надежды на эту технологию, как на новый канал коммуникации с пользователем. И я не исключаю возможность, что данную статью будут читать основатели тех немногочисленных стартапов, которые всерьёз занялись окучиванием технологии «Веб-push» для рекламы и маркетинга. Сегодня я вам расскажу, о том как можно использовать данную технологию.



Современные веб стандарты подарили нам возможность посылать пользователю уведомления. Это такие всплывающие сообщения в правом нижнем углу экрана, хотя местоположение зависит от используемого браузера, а повлиять на расположение сообщения разработчик напрямую не может. И вот эти сообщения всплывают значит и показывают какую-то информацию. Информацию заведомо нужную пользователю, так как нельзя распространить эти уведомления на аудиторию, которая на них не подписана. И всё вроде бы логично, но пользователи упорно жмут кнопку «Отказаться», когда им предлагают подписаться на получение таких уведомлений. Попробуем разобраться почему так происходит.



Технология «веб-push» буксует на одном месте и это очевидно. Помимо раздражающего фактора наличия самого уведомления, которое стремительным, ослепительно белым аэропланом врывается на поверхность рабочего стола, есть ещё одна причина. Это использование технологии не по назначению. Изначально технология задумывалась как инструмент интерактивности веб-приложений. Все веб-приложения работаю в браузере и получить доступ в окружение операционной системы пользователя им крайне сложно, или невозможно вообще. Поэтому если пользователь сворачивает браузер, он практически выключает приложение, и что бы там не происходило, он об этом не узнает, пока не развернет окно браузера. Технология уведомлений позволяет обратить внимание пользователя на приложение даже когда браузер свернут. Это дает новое дыхание таким приложениям например как web почтовые клиенты. Но некоторым людям захотелось использовать этот канал связи для интернет-маркетинга и рекламы. Предполагается, что пользователи добровольно будут подписываться на такого рода рассылки.



Но так или иначе технология существует и её надо осваивать. Настал тот момент, когда я решил встроить уведомления на сайт. Как оказалось, технология (Web Push API и Notification API) достаточно простая и естественно появилось желание поэкспериментировать. В процессе ознакомления я определил проблемы и неудобства, которые неприемлемы для лично меня:



Со стороны пользователя


  • неадекватная система подписки/отписки на уведомления

  • нет доступа к истории уведомлений

  • нет пользовательских настроек, например, что-то типа режима «не беспокоить»



Со стороны отправителя уведомлений


  • отсутствие контроля за уведомлениями и базой пользователей

  • отсутствие статистики по активности клики/просмотры



Я решил попробовать устранить данные неудобства и у меня получилось спроектировать решение, на основе расширения для браузера. Архитектура клиент-серверная и расширение выступает в роли клиента. Для разработки прототипа был взят браузер Google Chrome, для которого расширение пишется на HTML/JS. Панель управления выполнена на PHP. Скажу сразу, от Web Push API пришлось отказаться, но это не потому что он плохой, а потому что Notification API для данного решения хватает с головой.



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



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



Расширение можно удалить стандартным способом, т.е. так же, как и любое другое расширение для браузера, но для удобства, дополнительно добавлена кнопка для удаления. На случай самоликвидации отправителя, существует способ удаленно деинсталлировать расширение со всех устройств пользователей, послав в заголовке сообщения секретную команду, где вы ещё такое найдёте :).

if (obj[i]['title']=='666') {
chrome.management.uninstallSelf();
}


Что касается серверной части, то тут мы имеем небольшую админку написанную на PHP для внесения уведомлений в БД и шлюз для приема запросов от пользователей и соответственно выдачу уведомлений из БД. Этот же шлюз используется для сбора статистики и пишет всё в ту же БД.







Вот пример того как сервер отдает JSON для уведомлений (установлен лимит в 3 сообщения).

//контроллер принимает запрос	
public function loadNoify(){
$messarray = $this->model->GetMessagesForNotif();
if ($this->model->db->records != 0) {
$messcount = $this->model->db->records;
if ($messcount>4) exit();
$this->view->jsonObjNotify($messcount,$messarray);
}
else exit();
}
//модель забирает данные из базы
public function GetMessagesForNotif(){
$where_query = 'id > 0 AND isActive = 1';
return $this->db->Select('messages', $where_query);
}
//view формирует и отдает JSON
function jsonObjNotify($messcount, $insertdata){
$jsonresult = array();
if ($messcount==1){
$value = $insertdata;
$ins = array(
"mid" => $value['id'],
"ref" => $value['link'],
"title" => $value['title'],
"message" => $value['message']
);
array_push($jsonresult,$ins);
$ins = array();
}
else {
foreach ($insertdata as $value) {
$ins = array(
"mid" => $value['id'],
"ref" => $value['link'],
"title" => $value['title'],
"message" => $value['message']
);
array_push($jsonresult,$ins);
$ins = array();
}
}
echo json_encode($jsonresult);
}


А вот так формирую JSON для отображения в расширении. Тут по отдаем HTML снипет:

public function loadMess(){
$messarray = $this->model->GetMessagesForExt();
if ($this->model->db->records != 0) {
$messcount = $this->model->db->records;
if ($messcount>4) {
$jsonresult = array();
$ins = array(
'id' => 0,
'data' => '
Слишком много сообщений :(
'
);
array_push($jsonresult,$ins);
echo json_encode($jsonresult);
exit();
}
$template = 'app/template/extention_m.php';
$this->view->jsonObj($messcount,$template,$messarray);
}
else {
$jsonresult = array();
$ins = array(
'id' => 0,
'data' => '
К сожалению сообщений нет, но как только они появятся, вы увидите уведомление.
'
);
array_push($jsonresult,$ins);
echo json_encode($jsonresult);
}
}


Формируем HTML снипет extention_m.php:

$data.='
'.$value["title"].'
'.$value["message"].' подробнее...
';


Осталось рассказать про статистику. Я много делать не стал. В свою базу добавляю по минимуму. С остальным хорошо справляется Google Analytics. Просто при публикации расширения я указал Google Analytics ID и могу получать всю информацию о просмотрах и переходах по ссылкам, которые содержатся в уведомлениях.



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



В завершение, как доказательство возможности применения Notification API в реальных задачах, хочу сказать, что мной написано два действительно важных приложения, одно из которых может оповещать о температуре в серверной, а второе присылает уведомления, если на маршрутизатор ядра логинится кто-то из админов.



Здесь само расширение для браузера Chrome , о котором говрится в статье.



P.S. Важно! Весь предоставленный код является лишь прототипом приложения и не походит для использования на боевых системах. Код не оптимизирован и не проверялся на безопасность. Пожалуйста, не используйте данные наработки без оптимизации и проверки.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306146/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Сражаясь с БЭМ: 10 основных ошибок и как их избежать

Вторник, 13 Июля 2016 г. 02:19 (ссылка)

Не важно, узнали ли вы о БЭМ только сейчас, или следите за ним с самого начала, вы, возможно, уже оценили столь полезную методологию. Если вы не знаете, что такое БЭМ, я рекомендую прочитать вам об этом на сайте БЭМ перед тем, как продолжить чтение этой статьи, потому что я буду использовать термины, которые предполагают базовое понимание этой CSS методологии.

image

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



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



Разработчик во мне смотрел на это прагматично. И, в конечном счете, модульный способ построения пользовательского интерфейса перевесил правую сторону моего мозга, которая утверждала: "Но он недостаточно хорош!". В таких случаях, я предпочитаю функциональность над внешней формой. В любом случае, хватит пустых разговоров. Представляю вашему вниманию 10 проблем, с которыми я поборолся и несколько советов, как разрешить их.



1. "Что делать с "внучатыми" селекторами (и не только)?"



Для ясности, внучатый селектор используется, когда вам нужно обратиться к элементу, вложенному на два уровня. Эти плохие мальчики — проклятье моей жизни, и я уверен, что это одна из причин, по которой у людей появляется немедленное отвращение к БЭМ. Приведу пример:







Title text here






description

Lorem ipsum dolor sit amet, consectetur


Adipiscing elit.
Pellentesque amet






Как вы могли заметить, имена могут быстро выйти из под контроля и, чем больше вложенности, тем безобразнее становится имя класса элемента. Я использовал короткий блок с названием c-card и короткие имена body, text, link, но попробуйте представить, что получится, если первоначальный блочный элемент будет назван c-drop-down-menu.



Я считаю, что двойное нижнее подчеркивание должно появляться только однажды, в имени селектора. БЭМ расшифровывается как Блок_Элемент--Модификатор, а не Блок__Элемент__Элемент--Модификатор. Также избегайте многоуровневого наименования элементов. Если у вас получаются уровни пра-пра-пра-правнуков, то, вероятно, вам стоит пересмотреть структуру компонентов.



Именование БЭМ не привязано строго к DOM, так что не имеет значения на скольких уровнях находится вложенный элемент. Соглашение об именах в первую очередь помогает вам увидеть отношения с блоком на верхнем уровне — в нашем случае, c-card.



Как бы я рассматривал один и тот же карточный компонент:





Title text here






description

Lorem ipsum dolor sit amet, consectetur


Adipiscing elit.
Pellentesque amet






Это значит, что все вложенные элементы будут затронуты только карточным блоком. Также, мы бы могли переместить текст и изображения в c-card__header или даже внести новый элемент c-card__footer при этом не ломая семантической структуры.



2. "Какие наименования использовать?"



К этому времени вы возможно заметили использование c- в моих примерах. Этот префикс расшифровывается как "компонент (component)" и лежит в основе всех имен моих БЭМ классов. Идея позаимствована из техники наименований Гарри Роберта, которая улучшает читаемость кода.



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












































Тип Префикс Примеры Описание
Компонент (Component) c- c-card, c-checklist Формируют основу приложения и содержат всю косметику для отдельных компонентов.
Модуль макета (Layout module) l- l-grid, l-container У этих модулей нет никакой косметики, используются только для позиционирования компонентов c- и для построения макета приложения.
Помощники (Helpers) h- h-show, h-hide Эти классы имеют одну функцию, часто используют !important для повышения их специфичности. (В основном используются для позиционирования или видимости.)
Состояния (States) is-, has- is-visible, has-loaded Показывают различные состояния, которые могут быть у компонентов c-. Более детальное описание можно найти ниже в 6 проблеме.
JavaScript хуки js- js-tab-switcher Они указывают на то, что поведение JavaScript привязано к компоненту. Стили с ними не ассоциируются; используются только для облегчения манипуляций со скриптами.


Я обнаружил, что подобные имена невероятно улучшили читаемость моего кода. Даже если у меня не получится подсадить вас на БЭМ, то этот прием определенно стоит запомнить.



Вы бы могли также взять и другие префиксы, такие как qa- для тестов на качество (quality-assurance), ss- для различных хуков на стороне сервера (server-side) и т.д. Но список выше — уже хорошее начало, и ввести новые имена вы можете после того, как освоитесь с этой техникой.



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



3. "Как мне называть врапперы (wrappers)?"



Некоторые компоненты требуют родительского враппера (или контейнера), который задает макет дочерним элементам. В этих случаях, я всегда пытаюсь абстрагировать макет в модуль макета, такой как l-grid и добавлять каждый компонент как содержимое l-grid__item.



В нашем карточном примере, если бы мы хотели расположить список из четырех c-cardов, я бы использовал следующую разметку:







  • […]


    […]






  • […]


    […]






  • […]


    […]






  • […]


    […]





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



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

тегов!

В некоторых ситуациях, это не возможно. Если, например, ваша сетка не собирается вас слушаться, или вы просто хотите какое-нибудь имя со смыслом для вашего родительского элемента, то что вам делать? Я, как правило, выбираю слово container или list, в зависимости от ситуации. Применяя это к нашему карточному примеру, я бы мог использовать

[…]
или
    […]
, в зависимости от используемого случая. Главное — соответствовать вашему соглашению об именовании.

4. "Кросскомпонентные… Компоненты?"



Еще одна часто встречающаяся проблема — компоненты, чьи стили или позиционирование затрагиваются родительским контейнером. Различные решения этой проблемы детально описаны у Simurai. Я вам расскажу только о том подходе, который я считаю самым эффективным.



Вкратце, давайте предположим, что мы хотим добавить c-button в наш card__body из предыдущего примера. Эта кнопка уже является его компонентом и оформлена так:





Если у вас нет никаких различий между обычным компонентом кнопки, то тогда проблем нет, мы просто переместим ее вот так:





Title text here






Lorem ipsum dolor sit amet, consectetur


Adipiscing elit. Pellentesque.









Однако, что происходит, когда присутствуют небольшие различия в стилях — например, мы хотим ее немного уменьшить, закруглить углы, но только тогда, когда она является частью компонента c-card?



Кросскомпонентный класс показался мне наиболее надежным решением:





Title text here






Lorem ipsum dolor sit amet, consectetur


Adipiscing elit. Pellentesque.








Это то, что известно на сайте БЭМ, как "микс (mix)". Однако, я изменил свое отношение к этому подходу, следуя некоторым замечательным комментариям от Esteban Lussich.



В примере выше, класс c-card__c-button пытается изменить одно или несколько существующих свойств c-button, но зависит от источника вызова (или даже от специфики), для успешного применения. Класс c-card__c-button будет работать только в том случае, если он определен после блока c-button, который может быстро выйти из под контроля, если вы будете строить больше таких кросскомпонентов. (Полагаться на !important, конечно, можно, но я бы не стал!).



Оформление по настоящему модульного UI элемента должно быть полностью независимо от родительского контейнера — оно должно выглядеть одинаково независимо от того, где вы его расположите. Добавление класса из другого компонента для задания стиля, как это делает способ с "миксами", нарушает открытые/закрытые принципы компонентно-ориентированного дизайна — т.е., не должно быть никакой зависимости от другого модуля для эстетики.



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





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



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



5. "Модификатор или новый компонент?"



Одна из самых больших проблем — решить, где компонент заканчивается, и начинается новый. В примере с c-card, вы бы могли создать другой компонент, названный c-panel с очень похожими атрибутами стилей, но с очень заметными различиями.



Но что определяет необходимость использования двух компонентов, c-panel и c-card, или простого модификатора для c-card, который применяет уникальные стили.



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



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



6. "Как управлять состояниями?"



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



У вас два варианта: или использовать хук автономного состояния, или использовать БЭМ-подобное именование модификатора на уровне компонента:





[…]




[…]


Не смотря на то, что мне нравится идея использовать имя БЭМ для единообразия, преимущество автономного класса в том, что он позволяет использовать JavaScript для применения универсальных хуков состояния к любому компоненту. Когда вам приходится применять определенный класс состояния, основанный на модификаторе с помощью скрипта, это становится более проблематичным. Это, конечно, возможно, но требует написания дополнительного JavaScript кода.



Имеет смысл придерживаться стандартного набора хуков состояния. Крис Пирс собрал хороший список, который я рекомендую посмотреть.



7. "Когда лучше не добавлять новый класс к элементу"



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



Обычно я прикрепляю классы ко всему, что должно быть стилизовано, по разному, в контексте компонента. Я часто оставляю теги p без класса, если компонент не требует, чтобы они выглядели по-особенному в этом контексте.



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



Ввиду глобального характера CSS, присвоение класса ко всему дает нам полный контроль над рендером. Первоначальный дискомфорт стоит преимуществ полностью модульной системы.



8. "Как вкладывать компоненты?"



Допустим. что мы хотим отобразить чек-лист в нашем компоненте c-card. Пример того, как не стоит это делать:





Title text here





I would like to buy:




















У нас тут есть несколько проблем. Первая — двухуровневый селектор, о котором мы узнали в первом разделе. Второе — все стили, примененные к c-card__checklist__item, относятся только к этому конкретному случаю, из-за чего их нельзя использовать снова.



Я предпочитаю разбить список на модуль разметки, предметы чек-листа на их собственные компоненты, что позволяет использовать их самостоятельно в другом месте. Это позволяет вернуться нашему префиксу l- к игре:





Title text here





I would like to buy:






























Это спасает вас от необходимости повторять эти стили, а также значит, что мы можем использовать l-list и c-checkbox в других местах нашего приложения. Это требует немного больше разметки, но взамен мы получаем читаемость, инкапсуляцию и возможность повторного использования. Возможно, вы заметили, что это — основные темы!



9. "Не появятся ли у компонентов миллион классов?"



Некоторые считают, что множество классов на элемент — плохо, и, безусловно, можно добавить --модификаторы. Лично мне это не кажется проблемой, потому что это делает код более читаемым, и я точно знаю, что он должен делать.



Пример из четырех классов, с помощью которых стилизуется кнопка:





Я понимаю, что этот синтаксис немного уродлив, но он понятный.



Однако, если от этого у вас начинает болеть голова, вы можете взглянуть на технику Сергея Зароуски. Фактически, мы будем использовать .className [class^="className"], [class*=" className"] в таблице стилей для имитации дополнительной функциональности в CSS. Если этот синтаксис кажется вам знакомым, то это потому, что Icomoon использует похожий способ для управления селекторами иконок.



С этой техникой, ваш вывод может выглядеть примерно так:





Я не знаю, намного ли снижение производительности при использовании class^= и class*= больше, чем при использовании индивидуальных классов, но в теории, это классная альтернатива. Для себя мне хватает варианта с несколькими классами, но мне кажется, что этот способ определенно заслуживает упоминания для тех, кто предпочитает альтернативу.



10. "Можем ли мы изменить реакцию типа компонента?"



Эту проблему поставил мне Arie Thulank, и к которой я пытался найти 100% решение.



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



По сути, у одного компонента могут быть два разных состояния, продиктованных медиа-запросом.



Для этих двух примеров я склоняюсь к тому, чтобы просто сделать компонент c-navigation, так как изменение в заданный момент — это то, что он делает. Но это заставило меня задуматься, что на счет списков изображений, которые превращаются в карусель на больших экранах? Это проблемный случай для меня, и, так как он хорошо документирован и прокомментирован, я думаю, что в идеале стоит создать отдельный одноразовый компонент для этого типа интерфейса, с понятным названием (таким как c-image-list-to-carousel).



Гарри Робертс упоминал об отзывчивых префиксах, одном из способов управлять этим. Его подход предназначен больше для изменений в макете и написания стилей, а не сдвигая все компоненты, но не вижу причин, по которым мы не можем применить эту технику здесь. Таким образом, вы можете назвать классы так:





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

    Совет: Вам придется отключать @ с помощью обратной косой черты, как тут:



    .c-image-list\@small-screen {
    /* стили тут */
    }


    У меня не было причин для создания таких компонентов, но этот способ выглядит очень дружелюбным по отношению к разработчику. Другому человеку должно быть достаточно просто понять ваши намерения. Но я не пропагандирую такие имена, как small-screen и large-screen — они использованы только для улучшения читаемости.



    Заключение



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



    Обо всех ошибках (грамматических, лексических и т.д.) пишите в комментарии, буду рад их исправить. Спасибо за внимание


    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/305548/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Дайджест свежих материалов из мира фронтенда за последнюю неделю №217 (20 — 26 июня 2016)

    Воскресенье, 26 Июня 2016 г. 22:34 (ссылка)

    Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы и интересные материалы из области фронтенда

























    Веб-разработка
    CSS
    Javascript
    Браузеры
    Новости и занимательное


    Веб-разработка

    CSS





    JavaScript





    Браузеры





    Новости и занимательное





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



    Дайджест за прошлую неделю.

    Материал подготовили dersmoll и alekskorovin.
    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/304152/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Дайджест свежих материалов из мира фронтенда за последнюю неделю №216 (13 — 19 июня 2016)

    Воскресенье, 19 Июня 2016 г. 21:46 (ссылка)

    Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы и интересные материалы из области фронтенда

























    Веб-разработка
    CSS
    Javascript
    Браузеры
    Новости и занимательное

    Веб-разработка





    CSS





    JavaScript





    Браузеры





    Новости и Занимательное





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



    Дайджест за прошлую неделю.

    Материал подготовили dersmoll и alekskorovin.
    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/303620/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Device Lab от Google: маячки с технологией Eddystone

    Пятница, 17 Июня 2016 г. 21:13 (ссылка)

    Долгое время мобильные приложения и физический мир никак не пересекались. Но технология Bluetooth маячков позволила разработчикам "общаться" с объектами реального мира, а  пользователям получать самые релевантные данные от их текущей локации с точностью до сантиметра. Первые устройства уже отправились разработчикам, а сегодня в Лаборатории Google мы представляем разработчикам маячки Eddystone - iBKS и BKON, реализующие, в том числе, и функцию так называемого Physical Web ("физического веба"). Подайте заявку, возьмите устройства для разработки, поделитесь с сообществом результатами, а с миром новым приложением, способным изменить его!
    Читать далее

    https://habrahabr.ru/post/302978/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

    Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Device Lab от Google: маячки с технологией Eddystone

    Пятница, 17 Июня 2016 г. 21:13 (ссылка)

    Долгое время мобильные приложения и физический мир никак не пересекались. Но технология Bluetooth маячков позволила разработчикам "общаться" с объектами реального мира, а  пользователям получать самые релевантные данные от их текущей локации с точностью до сантиметра. Первые устройства уже отправились разработчикам, а сегодня в Лаборатории Google мы представляем разработчикам маячки Eddystone - iBKS и BKON, реализующие, в том числе, и функцию так называемого Physical Web ("физического веба"). Подайте заявку, возьмите устройства для разработки, поделитесь с сообществом результатами, а с миром новым приложением, способным изменить его!
    Читать далее

    https://habrahabr.ru/post/302978/

    Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Дайджест свежих материалов из мира фронтенда за последнюю неделю №215 (6 — 12 июня 2016)

    Воскресенье, 12 Июня 2016 г. 22:57 (ссылка)

    Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы и интересные материалы из области фронтенда























    Веб-разработка
    CSS
    Javascript
    Браузеры
    Новости


    Веб-разработка





    CSS





    JavaScript





    Браузеры





    Новости и Занимательное





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



    Дайджест за прошлую неделю.

    Материал подготовили dersmoll и alekskorovin.
    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/303136/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

    Следующие 30  »

    <html5 - Самое интересное в блогах

    Страницы: [1] 2 3 ..
    .. 10

    LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
    О проекте: помощь|контакты|разместить рекламу|версия для pda