HTML *

В блоге Печкина на Хабре мы много пишем об интересных техниках работы с email-рассылками. Ранее мы рассматривали распространенные ошибки при создании форм в почтовых письмах, а сегодня представляем вашему внимани адаптированный перевод заметки итальянского дизайнера Массимо Кассандро, который решил выяснить, стоит ли вообще применять этот инструмент в верстке email-cообщений.

Большинство fronted-разработчиков, используют ОС Windows или OS X в связи с отсутствием полноценного Photoshop. Но как быть тем, кто неравнодушен к Nix системам? Сейчас и попробуем выяснить, интересующихся прошу под кат.

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

Допустим, я создал браузерную игру, а что дальше? Если для мобильных — есть магазины Google Play, App Store, Windows Store и куча всяких альтернативных. Можно найти площадки для распространения сборок standalone — Desura, Steam, Itch.io. Но когда задумываешься о судьбе браузерки, то невольно впадаешь в ступор. И куда ее?

Думать о судьбе своего детища необходимо еще на начальном этапе разработки. Так, в случае с Dangerous Insects, я уже знал, где и как буду размещаться, хотя от игры в лучшем случае был только диздок. Вот и с HTML5 захотелось заранее прощупать почву.

В нашем блоге мы уже неоднократно рассказывали о создании email-рассылок с помощью CSS и HTML. Сегодня же речь пойдет о самом подходе к созданию верстки. Итальянский дизайнер Массимо Кассандро на сайте SitePoint описал свой процесс разработки html-писем. В нем есть несколько интересных моментов, так что мы решили сделать адаптированный перевод этой заметки.



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

По моему опыту, особенно важно это при создании HTML почтовых писем. Email требует выполнения большого количества повторяющихся задача, которые сами по себе не так уж сложны, но затрагивают огромное количество разных элементов, что может приводить к ошибкам. Вот, как я стараюсь этого избежать.

Судя по всему, разработчики этого фреймворка крайне чувствительно относятся к смене сезонов. Раньше я уже писал о новых версиях Webix. И выходили они либо в начале весны, либо в начале лета. На этот раз, судя по всему, в рамках борьбы с осенней депрессией разработчики выкатили мажорный релиз. В новом Webix 3.0, помимо уже привычных нам новых фич и багфиксов, появились два новшества, которыe вполне себе можно считать отдельными продуктами: Webix Jet и Visual Designer. Давайте разберемся, что это такое, зачем это нужно и как это выглядит.

Почти все знают о программе Punto Switcher, которая очень полезна тем, что при написании:

БвшмЮ

Автоматически преобразует это в:

<div>

Или

юигеещт

в

.button

В общем нервы остаются целыми, ибо вам не приходится в ручную всё стирать и писать по новой. Можно даже не беспокоиться о том, какая раскладка у вас стоит.

И самое интересное, что благодаря данной программе можно создать своеобразный Emmet. А точнее, готовую структуру для Emmet'a.

Заниматься чем-то, нарушающим священное волеизъявление здешних господ на контент, который и только который они хотят видеть вокруг себя — дело, конечно, неблагодарное и кармически опасное. Но гонки вооружений между блокировщиками рекламы и рекламными системами не избежать, поэтому говорить об этом нужно. Сейчас, когда общий объем вырезанного трафика крутится около 1% — всё несколько вяленько, но уже есть оглядывающиеся владельцы сайтов, недополучающие до 30% денег с рекламы. Рекламные сети начинают общаться между собой, обмениваться спецификациями, есть уже какой-то израильский стартап на эту тему — думаю, соблазнительно с минимальными усилиями увеличить доход сразу и на проценты. В российском сегменте всё пока обходится увещевательными объявлениями вида «Вы отключили рекламу — это мешает нам развиваться» или простым игнорированием факта существования таких пользователей. Надо сказать, пусть оно всё так и остается.

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

• хранения cookie рекламных систем на стороне пользователя
• передавать не меньшее количество информации о пользователя, чем браузер: User-Agent, IP
• требовать минимальной настройки большинства стандартных рекламных тэгов
• быть легко подключаемым и изменяемым для случаев, когда кто-то не поленился и всё-таки добавил кастомное правило, попавшее в мейнстрим

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

Доброго дня, хабровцы.
По результатам прошлой статьи я понял, что тема интересна общественности, поэтому подготовил еще один материал, чуть сложнее.
По прежнему нет скриптов, только HTML/CSS.

Смотрите видео и под кат.

Привет, читатель!

В этой публикации я расскажу тебе о «Книжной полке фронтендера».

Предыстория

К сожалению, в рунете очень мало по-настоящему качественных ресурсов для изучения фронтенда. Эти ресурсы можно буквально пересчитать по пальцам одной руки — это Frontender Magazine, HTML Academy, «Современный учебник JavaScript». Я благодарю авторов этих ресурсов за их неоценимый вклад в развитие и популяризацию фронтенда в рунете.

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

Сегодня речь пойдет о том, как создать игру не используя js и прочих скриптов. Только HTML / CSS, только хейткор.

Аккордеон добавляет визуальное оформление и соответствующее поведение типа «горизонтальный аккордеон» произвольному (в рамках использованного шаблона и стилей) блоку разметки HTML.

Блок разметки должен иметь два обязательных элемента — общий контейнер и вкладки:

<ul ngc-accordion>
    <li ngc-accordion-tab="наименование1" template="template.html">... </li>
    <li ngc-accordion-tab="наименование2" template="template.html">... </li>
</ul>
    

Или так:

<div ngc-accordion>
    <div ngc-accordion-tab="наименование1" template="template.html">... </div>
    <div ngc-accordion-tab="наименование2" template="template.html">... </div>
</div>
    

Выглядит так:

Недавно столкнулся с интересной задачей: в шапку сайта установить видео в качестве фона. Шапка всегда занимает первый экран и установлена по принципу background-position: 50% 0. Суть в том, что на планшете мы видим видео полностью, а на телефоне оно обрезается по краям и снизу остается только центральная часть.

Прогрессбар — элемент вроде и редко встречающийся на сайтах (в отличии от селектов, чекбоксов, инпутов и прочего), но все равно без него не обойдется ни один ui-kit.

На данный момент HTML5 предоставляет нам нативный элемент progress, базовый функционал которого поддерживается практически всеми современными браузерами (caniuse.com/#feat=progress).

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

Недавно Роскомнадзор предпринял попытку блокировки доступа с территории РФ к Википедии. Попытка провалилась, и самое время перейти в контрнаступление. В статье под катом я покажу, что, если пользователь Х зашёл на сайт А, то сайт А может определить, заблокирован ли для пользователя другой сайт Б. А дальше, по намечающейся традиции, изложение пойдёт в вопросно-ответной форме.

Для чего это вообще нужно?

При обсуждении блокировки Википедии сообщество заметило два обстоятельства, которые весьма выгодны цензуре. Во-первых, Википедия использует HTTPS и, более того, HSTS. Это означает, что заблокирована энциклопедия может быть только целиком (с точностью до домена), но при этом перенаправить на пресловутую страницу с сообщением о блокировке нельзя. Вместо этого высвечивается сообщение об ошибке установления соединения. Это выглядит как внутренняя проблема Википедии и смягчает недовольство пользователя действиями Роскомнадзора; в то же время для развития правового государства необходима обратная связь. Во-вторых, даже если пользователи узнают о блокировке, многие из них просто не будут знать, что делать. Вешать перманентную плашку «Если заблокировали Википедию — качайте Tor Browser!» на неравнодушных сайтах как минимум странно; в то же время, оповещение пользователей о блокировке Википедии и способах её обхода необходимо. Решение поставленной проблемы и пытается дать настоящая статья.

В международный день грамотности (International Literacy Day) Хабрахабр ввел некоторые изменения и присвоил каждому пользователю по «собачке». Теперь рядом с логином под своей публикацией Вы можете наблюдать такое «безобидное создание», как знак @.

Многие из Вас наверное пользовались замечательным сервисом от Google: PageSpeed Insights? Хотите получить заветные 100 из 100?


Картинка для привлечения внимания

А дело-то за маленьким.

Привет, Хабр!

Сегодня небольшим, но полезным туториалом с нами поделится Дмитрий Кабаков, Senior фронтенд-разработчик DataArt.

В современном «гугломире» все большую важность набирает социальная составляющая сайта. Но обычные социальные виджеты/коды не всегда почти никогда не вписываются в оформление сайта.

Что же делать? Нужно оформлять!

Для туториала вам понадобится:

• jQuery-плагин sharrre;
• иконки FontAwesome;
• знания HTML/CSS3;
• минут 10 вашего времени

Привет!

Отгремели фанфары, прошел звон в ушах от истязаний «евангелистов», модников в сфере фронтенд разработки. Кто-то ушел на sprockets, кто-то пустился во все тяжкие и стал писать свои велосипеды или расширять функционал gulp или grunt. Но статей по поводу популярных инструментов автоматизации процесса сборки – стало существенно меньше и это факт! Пора бы заполнить освободившееся пространство чем-то существенно иным.

Уверен многие слышали о webpack. Кто-то подумал «он слишком много на себя берет» и не стал дочитывать даже вводную статью на оффициальном сайте проекта. Некоторые решили попробовать, но столкнувшись с небольшим количеством примеров настройки — отверг инструмент решив подождать пару лет. Но в целом, разговоров «вокруг» ходит масса. В этой статье — хочу развенчать некоторые сомнения. Может быть, кто-то заинтересуется и перейдет на «светлую сторону». Вообщем желающие под кат.

Интро

Цель — создать велосипед скрипт, который пробежится по сайту и проверит каждую страницу сайта на валидность html.
Я слышал, что если нападает перфекционизм, то надо полежать, отдохнуть и это пройдет.
Подумаешь, в валидаторе ошибка…
Но если все же не проходит, то