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

Очевидным вариантом было бы набросать основную разметку, определить doctype и оставить браузерам работу по стилизации. Но это очень ленивый метод, который дает результат, вызывающий недоумение у будущего посетителя такой страницы. Хочется хотя бы базовой стилизации заголовков и ссылок, какой-то простой структуры.

Так что следующим шагом стал просмотр готовых вариантов в сети.

Поиск

Шаблоны для CMS не подходят хотя бы потому, что CMS не будет. И такие шаблоны чаще всего рассчитаны на более сложные сайты. И они не будут радовать посетителей с мобильными устройствами.

Хотя, сейчас появились шаблоны с адаптирующейся разметкой (responsive design), которые и вызвали у меня интерес. К сожалению, большинство найденных решений оказались платными, что не удивительно, учитывая объем работы, который проделывают их авторы.

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

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


Адресация сообщения в документе

Заранее оговорюсь, что чистым CSS здесь, к сожалению, обойтись не получится: Firefox и IE8+ слишком точно (да-да, в данном случае это плохо) производят вычисления ширины блоков. Однако для этих браузеров дописывается нехитрый скриптик в пару строк, если таки надо достичь идеала, хоть это и портит всю прелесть.

Для тех, кому лень читать всё, ссылка на окончательный вариант: jsfiddle.net/XeFTr/11

В чем суть?

Суть в том, что иногда необходимо отобразить на странице резиновый блок с несколькими дочерними элементами, причем потомок должен быть либо виден целиком, либо не виден вообще. Самый простой пример — лента каких-нибудь картинок с прокруткой и стрелочками по бокам. Очень некрасиво смотрится выглядывающее из-под «overflow: hidden» изображение, обрезаннное сбоку. Выход — заставить ширину обёртки всегда быть кратной скольки-то пикселям.
Разумеется, если ширина потомков разнится от элемента к элементу, то этот способ не имеет смысла.

Как это работает?

Принцип работы заключается в том, что большинство браузеров вычисляют ширину потомка, если она задана в процентах, исходя из ширины родителя. Таким образом, если у элемента ширина 1000%, то при изменении ширины его родителя на пиксель сам элемент растянется или сожмётся на 10 пикселей. Собственно, всё.

Эту штуку описывал в лебедевском скринкасте Сергей Чикуёнок еще в 2008 году, в контексте исправления бага с «прыгающими» блоками в IE6. Однако я, к своему удивлению, так и не нашел описания этой презабавной технологии на Хабре.

Активисты движения за свободное ПО запустили новый проект: поисковую систему YaCy, которая в перспективе может составить конкуренцию Google, Yahoo/Bing, «Яндекс» и прочим закрытым коммерческим поисковикам. Версия YaCy 1.0 вышла после пяти лет разработки, и теперь присоединиться к сети наконец-то может любой желающий.

Несколько месяцев назад Майкл Хоули опубликовал на www.uxmatters.com статью, посвященную решению распространённых проблем, с которыми сталкиваются проектировщики интерфейсов, ожидающие получить от заказчика внятные комментарии на прототипы интерфейсов.
Эта статья может быть полезной:

* проектировщикам ui / ux;
* дизайнерам;
* руководителям проектов со стороны исполнителя.

Представляю вам её перевод:

“Рассмотрим такой сценарий:

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

Здравствуй, хабраюзер!

Сидя недавно и листая developer.mozilla.org наткнулся на описание -moz-calc();
Вкратце, данное свойство используется для расчёта выражений прямо в CSS.
Тут-то и родилась идея сделать калькулятор, который бы считал через это хитроумное свойство.
Что из этого вышло, можно судить по этому скриншоту:

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

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

Google Fusion Tables

Позволяет развернуть реляционную базу данных на серверах гугла с обращениями с помощью библиотеки Visualization или JSONP.
Статья на хабре: habrahabr.ru/blogs/webdev/116035
Ссылка: www.google.com/fusiontables/Home

Минусы: количество обращений в секунду равно пяти с одно IP адреса и столько же при обращении с аккаунта (используя авторизацию). То есть развернуть сайт с хорошей посещаемостью и работать с сервисом с помощью сервера не получится. Стоимость увеличения лимита — от 10 тысяч долларов в год (см. Maps API Premier). Кроме того, отсутствуют джойны, которые заменяются представлениями (view), создаваемыми через интерфейс.

Благодаря библиотеке jQuery примерно с 2006 года (то есть лет пять как) никому не надо объяснять, что такое method chaining: это та самая техника программирования, в которой методы объекта могут быть вызваны друг за другом по цепочке, как в jQuery.

Главнейшим достоинством этой техники является заметная экономия усилий программиста. С нею программисту не приходится заново, неоднократно записывать имя объекта вот в такой манере:

obj.шмяк();
obj.тыдыжжь();
obj.ынц();

Вместо этого программист может вызвать все методы цепóчкою — в одну строку:

obj.шмяк().тыдыжжь().ынц();

Если же ему покажется, что такой вид записи хуже читается человеком, чем предыдущий (особенно когда у методов появляются параметры, иногда довольно обширные), то тогда программист может записывать имена методов с новой строки (JavaScript это позволяет), но всё равно экономить на имени объекта:

obj
   .шмяк(параметр1, параметр2, …)
   .тыдыжжь(параметр1, параметр2, …)
   .ынц(параметр1, параметр2, …);

На практике возможность такой техники обеспечивается тем, что ни один метод объекта не возвращает значение undefined. Вместо этого, если метод является командою, а не запросом (то есть выполняет некоторое действие, а не возвращает некоторое значение), то в конце его автор библиотеки пишет «return this» — этим-то и обеспечивается возможность записи вызова нескольких команд подряд в форме цепочки.

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

Удобство цепного вызова вызывает привыкание. Ну правда же: достаточно пару-тройку-другую недель попрограммировать на jQuery — и обыкновенные API начинают раздражать, даже бесить, своею допотопною невозможностью цепного вызова. Также недостаёт возможности задания их свойств в виде объекта, передаваемого методу, подобному .css({color: 'red', 'line-height': 1}) в jQuery.

Вообразите себе, например, как необыкновенно было бы удобно, кабы по холсту (<canvas>) можно было рисовать цепными вызовами в такой манере:

ctx.beginPath()
   .prop({
      lineWidth: 2,
      strokeStyle: '#333'
   }).moveTo(0,0)
   .bezierCurveTo(50,50, 80,80, 100,100)
   .stroke().closePath();

И средство для именно таких цепных вызовов появилось — благодаря Lea Verou. Вот оно:

Долгое время использовал в своих проектах, различные готовые JavaScript-календари для ввода дат, в частности Dynarch jsCalendar, и они полностью устраивали. Но в ходе разработки одного проекта, связанного с автострахованием, возникла необходимость довольно частого ввода дат из прошлого (дни рождения, дата выдачи паспорта и водительских прав, пенсионного и т.п.). Оказалось, что использовать календари в таких случаях не так уж и удобно, так как приходится отматывать несколько десятков лет назад и для этого приходится делать много действий мышкой.

Привет всем. Сегодняшний пост будет коротким, но, думается мне, полезным.
Часто приходится слышать о том, как сделать «затухание» текста к низу, верху и т.д.
Есть варианты на js, есть варианты с картинкой и просто css-градиентом наложенными поверх текста.
Сегодня в голову пришел несколько другой подход к решению этой проблемы.
Его реализация проста как три копейки

Доброго времени суток всем желающим приобщиться к миру пользовательских скриптов (они же userscript, userJS, юзерскрипты).

В этой статье я хочу поведать о том, что такое юзерскрипты, c чем их едят и, главное, как их готовят!

Внимание: предполагается минимальное знание javascript.
На практике доказано: юзерскрипты может писать человек, не знакомый с программированием, но обладающий усидчивостью и желанием изучить javascript!
О том, что такое javascript и как с ним обращаться, можно узнать на javascript.ru.

У каждого дизайнера наступает момент, когда ему надоедает заново рисовать одинаковые элементы на сайтах. Например, иконки социальных сетей или стрелочки для галерей. Также, технологам надоедает каждый раз нарезать «гиф» или «пнг» одного и того же элемента.

Чтобы упростить себе эту работу мы сделали шрифт, в котором каждая буква — символ (как правило, часто используемый).

Ну и собственно почему-бы им не поделиться со всеми?

Web Symbols

Здравствуй Хабр!
Вот и настало время второй, и, надеюсь, долгожданной части. Настоятель рекомендую ознакомится с первой частью, ибо без этого будет тяжело понять, о чем я буду писать. В этой части я отойду от теории к практике, а именно покажу небольшое проект для комплексной оптимизации изображений.

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

При обращению к гуглу выдаёт много статей по загрузке файлов через iframe. Алгоритм в общем сводится к:
1) Создаём скрытый фрейм (обычно просто обнуляется ширина и высота через HTML и CSS свойства)
2) Устанавливаем action формы в имя фрейма.
3) Отправляем файл. Радуемся.

Для удобства использования отдельная кнопка «Начать загрузку» не создавалась, а был повешен обработчик onChange для файлового input'a.

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

Квадрат

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

Создатели проекта The Noun Project поставили целью собрать пиктограммы для всех объектов в мире. Коллекцию по мере сил пополняют десятки дизайнеров из разных стран. Все иконки публикуются в формате SVG, под лицензией Creative Commons Attribution 3.0 (CC BY) или Public Domain, разбиты на тематические категории, есть поиск на русском языке.

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

Вчера была опубликована хорошая статья «Веб-дизайн. Каждому устройству свое представление». Несмотря на неплохие размышления, к сожалению, вывод в ней довольно глупый. А именно:

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

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

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

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