Перевод не претендует на 100%-ную точность, но я постарался максимально точно передать мысли и слог автора. Комментарии приветствуются.

Начиная с Интернет Эксплорера 4 в 1998-ом, а затем с марта 2008-ого и до марта 2010-ого, один за другим, вся «большая пятерка» десктопных браузеров — Сафари, Файрфокс, Опера и Хром — выкатили сравнительно похожие реализации правила @font-face для привязки шрифтов.  Вместе с тем, неотъемлимая часть веб-издательского паззла, часть, которой не хватает с начала Веба, встала на место и теперь настоящая, веб-ориентированая типографика начинает принимать форму.

Для начала, обзор последних событий:

1. 18-ого марта 2010 года была учреждена группа  Web Fonts Working Group в W3C. Её первая задача была утвердить  спецификацию WOFF как стандарт доставки sfnt (OTF и TTF) шрифтов в веб в «сжатом» виде.
2. Была представлена отрисовка шрифтов в IE9 с помощью Windows’s DirectWrite в  IE9 Platform Preview.
3. Появились первые инструменты для подготовки веб шрифтов, такие как Font Squirrel’s @Font-Face Generator и EOTFAST.
4. Пошла новая волна «шрифтохранилищ»  в виде Typekit, Typotheque и бесплатного,  опенсорсного Kernest.
5. Появились первые “трастовые/кредитные” лицензии на веб-шрифты от дизайнеров коммерческих шрифтов.
6. CSS3 Fonts Module включил в себя некоторые продвинутые свойства OpenType.
7. Adobe Flash, когда-то надежная, кросс-платформенная среда замены текста (sIFR), сейчас выглядит абсолютно убогой.
8. Google запустил бесплатный сервис шрифтов с растущей библиотекой.  Все шрифты в библиотеке доступны и для частного хранения/использования.

Теперь пройдемся по пунктам…

WOFF

WOFF был официально добавлен в W3C Fonts Working Group 8-ого апреля, 2010 года. Microsoft неожиданно спонсировала его внесение вместе с Opera и Mozilla. Поддержка WOFF заявлена в тестовых билдах IE9 для разработчиков. WOFF будет стандартом “транспорта” для шрифтов. Поддержка WOFF уже реализована в Firefox 3.6+, и разработчики Chrome анонсировали поддержку WOFF в ближайшем будущем.

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

Как и его старший брат, EOT (Embedded Open Type), WOFF  файл является по сути архивированым файлом шрифта. Он не является шрифтовым форматом, сам по себе. Это файл шрифта, который «собрали в дорогу». Как PNG и JPEG для BMP и TIFF, так и WOFF для TTF и OTF. (В отличии от сжатого изображения, оригинальный шрифт может и должен быть распакован из сжатия.) На практике, WOFF и EOT очень похожи и  соотношения сжатия для них более-менее одинаковы.

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

IE9 и DirectWrite

IE9 использует Windows DirectWrite API для отрисовки шрифтов. Если вы еще не скачали предпросмотровую версию IE9  я рекомендую вам попробовать, это может вас приободрить. Проведя некоторое время с IE9 preview, вы не захотите возвращаться к IE8 и XP. (Mac-юзеры, не ржать.) Отрисовка шрифтов в IE9 это нечто гораздо большее, чем мы ожидали. Несомненно на уровне с Маком, а в некоторых случаях даже лучше. Каково бы не было ваше мнение, разница сократилась значительно. Одним из отличных побочных эффектов фокуса на веб-шрифтах стало заострение внимания на том, как  желание отрисовки шрифтов в браузерах под Windows  сравнивается с отрисовкой в браузерах на OS X. Обратите внимание на то, что DirectWrite является Windows API, а не специфично для  IE, и другие браузеры, такие как Firefox тоже реализуют его.

IE9 и @Font-Face с помощью CSS3

Удивительно, но то что делает @font-face годным кросс-браузерным решением сегодня, это то что IE поддерживает @font-face уже более десяти лет. Тем не менее, IE9 будет первой реализацией @font-face так как описано в спецификации CSS3.

Вот основные изменения:

Форматы шрифтов

Дополнительно к TrueType (TTF) шрифтам, IE9 будет поддерживать PostScript-приправленные OTF CFF шрифты, так же как и  “большая пятерка” браузеров. Удаление этой преграды для совместимости само по себе очень хорошо, но с предупреждением: только если в интересах обратной совместимости для IE 6–8, это произойдет за несколько лет до того как веб-шрифты перестанут быть TrueType. IE 6–8 будут поддерживать только TrueType шрифты, запакованные как EOT. Кроме этого есть и другие проблемы отрисовки в браузерах под Windows, о которых надо помнить.

Остается надеяться что дизайнеры шрифтов помогут в этом, создавая свои шрифты доступными в TrueType с адекватным TrueType хинтингом. Либо, как вполне серьезно предложил мне один дизайнер шрифтов, все должны воздержаться от использования веб-шрифтов, пока IE8 не уйдет со сцены. Ха! Слишком поздно.

Синтаксис

Внутри @font-face “декларации” в CSS3, вы, как веб автор, должны делать то, что операционные системы делают для вас с «безопасными» шрифтами. Вы должны группировать шрифты в семейства, декларируя их под одним именем семейства. Вы должны разделять членов этого семейства, декларируя для каждого из них быть различной комбинацией font-style (normal, italic) и font-weight (normal, bold).

Обратите внимание на то, что селекторы font-weight и font-style имеют различные значения внутри @font-face правила от тех же селекторов вне правила в основной таблице стилей. Внутри декларации, font-weight: bold означает, “это жирный участик этого семейства шрифтов;” вне декларации  font-weight: bold означает, “применить жирность к этому тексту,с помощью участника этого семейства шрифтов, который декларирован как жирный.”

В IE6–8 @font-face работает тем же способом. Однако для того, чтобы EOT-файлы работали правильно, некоторые наименования и описательная информация внутри TTF-файла из которого создан EOT, должны совпадать с CSS декларацией. В большинстве случаев это не проблема. Но иногда, некоторые поля внутри таблиц данных шрифта должны быть изменены. В случае необходимости, все проблемы изучены и легко могут быть исправлены. (Подробности в документации для EOTFAST.)

Инструментарий для Веб-шрифтов

Необходимый инструментарий, которым должны обладать веб авторы:

Font Squirrel Генератор

Генератор это набор онлайн-инструментов, предлагающий конвертацию, очистку, генерирующий CSS стили и так далее. На данный момент, это лучшее что есть в сети и в руках дизайнера шрифтов и веб-разработчика Ethan Dunham только продолжает улучшаться.

Кроме того, возможно вы захотите ознакомиться с некоторыми бесплатными утилитами, которые используются за кулисами в таких местах как Font Squirrel, Kernest и Google:

• FontForge полновесный редактор шрифтов со всевозможными конфигурируемыми вкусностями на стороне сервера. Открытый исходный код.
• sfnt2woff это набор утилит с открытым исходным кодом для упаковки TTF и OTF CFF шрифтов в WOFF-файлы.
• ttf2eot это предшественник EOTFAST. Он создает несжатые «легкие» EOT-файлы.
• TTX это средство конвертации OpenType и TrueType шрифтов  в и из XML.
• Fontue это движок с открытым исходным кодом для вывода веб-шрифтов и скриптов для обработки шрифтов. Приветствуются вклады в Github.
• WebFont Loader это JavaScript-библиотека, которая позволяет лучше контролировать загрузку шрифтов, чем позволяет Google Font API. Создана в сотрудничестве между Google и TypeKit.

EOTFAST

Разработан мной и Филлипом Тейлором из Кембриджа,  EOTFAST является бесплатной и простой для использования альтернативой Майкрософтовскому конвертору, WEFT. Используйте EOTFAST для создания оригинально сжатых EOT файлов, совместимых с IE 6–8 и более быстрой загрузкой страницы. Обратите внимание на то, что EOT формат не был признан нерекомендованным и будет продолжать работать во всех режимах рендеринга в IE9, создавая тем самым легкий путь работы со всеми версиями IE, не прибегая к условным комментариям.

Доверительные лицензии

Доверительные лицензии—шрифты по оптовой цене, которые предоставляются в виде устанавливаемых TTF или OTF файлах для упрощения разработки, на равне с публикацией на веб-серверах — доступны в Font Spring. Этот сайт предоставляет, как каждый подобный сайт должен был бы, образцы шрифтов, так что вы в действительности видите то товар, перед тем как покупаете его. Надеюсь, остальные подобные сервисы примут эту простую модель лицензирования за основу.

Шрифтохранилища и «маскирующие» сервисы (FHOS)

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

Заботы создателей коммерческих шрифтов гораздо глубже, чем сценарий ситуации когда посетитель сайта видит понравившийся ему шрифт, роется в CSS и скачивает его. Позвольте мне предложить объяснение, чтобы вы могли лучше понять почему существуют сервисы шрифтов, использующие «маскировку», а в некоторых случаях и запутанные,  и тупые лицензионные соглашения.

Производители шрифтов видели что произошло с индустрией музыки, книг, газет, журналов и банков изображений и они бояться что то же самое произойдет с ними. Это называется iTunes Effect, and it’s about price.

Дизайнеры шрифтов все еще очень сфокусированы на принте. В общем, основные деньги находятся в обслуживании профессиональных клиентов в индустрии печати: книги, журналы, художественное оформление и так далее. Цены обычно варьируются в зависимости от количества пользователей продукта. Основной их страх в том, что как только шрифты появятся в сети, они станут продуктом широкого потребления, существующая бизнес-модель рухнет и произойдет обесценивание шрифтов. Дизайнеры шрифтов боятся того, что не смогут запросить с клиента, скажем, 420$ за четыре семейства шрифтов для 6-10 пользователей, в мире где шрифты предоставляются на сайтах для «условно» неограниченного количества посетителей, которые вобще ничего не должны платить за это. Что если интернет снижает цены в секторе печати и сам по себе фактически не генерирует дохода?

Предостережение покупателям

В ответ на «интернет угрозу», некоторые коммерческие дизайнеры шрифтов выбрали шрифтохранилища и «маскирующие» сервисы. По существу, эти сервисы используют модель Amazon Kindle, но вместо книг вы получаете то, из чего сделаны книги — шрифты. Они раздаются отмереным, контролируемым путем так, что создатели шрифтов занют куда каждый из шрифтов идет и кем используется. Маскировка фокусируется на предотвращении обычного скачивания и возможности создания устанавливаемого в операционную систему шрифта, и поэтому шрифт становится недоступным для работы в таких програмах как InDesign. Основная задача подобных сервисов — удержать семейства шрифтов в своих руках.

Увеличение дискуссий между предтавителями производителей шрифтов, такими как Microsoft, Adobe, Monotype Imaging и другими, в следствии появления Typekit’а в прошлом году, в последние месяцы привело к созданию таких маскирующих сервисов какMicrosoft’s font distribution proxy, Ascender Corp, Extensis (специалисты в програмном обеспечении для управления и лицензирования шрифтов), Monotype Imaging, и коллектив, включающий Font Bureau от David Berlow.

Я могу сказать вам  что ребята из Extensis, Ascender и Monotype счастливы и полны энтузиазма предоставлять шрифты для веба. Но они уж точно не будут спешить рассказывать вам, что система распространения этих шрифтов создана в ограничениях умной, но «грязной» DRM-подобной структуры. Это понятно. Но попытки идентифицировать и предотвратить случаи нелицензированого распространения через код доказали свою нецелесообразность фактически для всех и в перспективе, все попытки маскировки шрифтов выглядят тщетными и нецелесообразными.

Дизайнер шрифтов Ray Larabie выразил это лучше всех:

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

Покупатель, будь благодарен

Как обычно, есть и обратная сторона. Можно рассматривать FHOS как фазу. Сервисы все время обновляются. Например WebINK сервис от Extensis бесплатный устанавливаемый «мастер предпросмотра» шрифтов Type Drawer, который позволяет, среди прочего, мнгновенно менять определенные шрифты на странице, просто перетаскивая их. Это позволяет сэкономить кучу времени и это то, что нужно дизайнерам в работе. На данный момент это проприетарная разработка WebINK, но она формирует направление развития сервисов.

Проверочный список сервисов шрифтов

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

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

1. Какие точно препятствия созданы в попытке предотвратить скачивание и установку шрифтов в операционной системе? На сколько вырастает число запросов к серверу в результате?
2. Отключено ли кеширование? Будут ли пользователи видеть  сначала «необстиленые» шрифты, которые потом будут сменяться нужными? (Flash Of Unstyled Text)
3. Если разделение файла шрифта на части является техникой маскировки, то как это может повлиять на шаг и кернинг? И является ли разбивка файла шрифта на части дополнительным фактором риска в некоторых браузерах?
4. Действительно ли сервис соответствует стандартам и позволяет вам использовать стандарт CSS3 во всей ширине, как это позволяют сейчас современные браузеры, поддерживающие @font-face?
5. Понятны ли  Пользовательское соглашение или Условия использования? Согласны ли вы или ваш клиент с обязывающими положениями контракта? Если вы прекратите пользоваться сервисом и будете хранить свои шрифты у себя, надете ли вы компромисс в соглашении?
6. Какова политика конфиденциальности? Будет ли сервис мониторить и сохранять логи активности на вашем сайте, и если будет то как? Что будет происходить с этой информацией?
7. Будут ли условия контаркта определять права посетителей вашего сайта? Имеют ли право посетители вашего сайта использовать шрифт не только для отображения на экране, но и распечатывать его и создавать PDF? Будут ли подвергаться риску те пользователи, которые попытаются скачать файлы шрифтов индивидуально? (Давайте признаем, все мы смотрим как люди делают свои сайты, это интернет.)
8. Когда поддержка WOFF (и EOT) станет повсеместной,будет ли какой-то путь для хранения шрифтов у себя, или вы будете привязаны к сервису навсегда?

Комментарии приветствуются.

Расширеные функции OpenType

С того момента, как John Daggett из Mozilla возглавляет CSS3 Fonts Module, впечатляющая команда приглашенных экспертов в дизайне типографики обдумывает проблемы передовой типографики в W3C.Уже в ближайшее время это может иметь большое влияние на отображение математических символов и не-латинских языков.

Будущее Flash Text Replacement

Уже прошло несколько лет с момента выхода iPhone, а флэш на нем все еще не разрешен. Как и на iPad.  Недавнее высказывание Стива Джобса привлекло много внимания и сложно представить себе что Apple пойдет на попятную в этом вопросе. Плюс, iPhone и iPad поддерживают гораздо более простую и элегантную альтернативу для отрисовки шрифтов с использованием SVG — @font-face. Любому разработчику, планирующему новый проект, тяжело предтавить себе использование в нем технологии sIFR. @font-face более прост в освоении и ему не нужно иметь будущее, он уже будущее.

Библиотека шрифтов Google

Благодаря неожиданной разработке, которая произросла из неформальных разговоров с ребятами из Typekit, Google стал провайдером свободно лицензированых шрифтов через Google Ajax API. Это опенсорсный проект в котором можно найти документацию, примеры и информацию о том, как можно способствовать его развитию в GitHub репозитории.В отличии от многих опенсорсных проектов, у этого есть постоянный куратор Raph Levien.

Заставим это работать сегодня

А теперь давайте окончательно запутаемся: для IE 6–8 вы можете использовать только TTF шрифты,  обернутые как EOT или EOT “Lite” (несжатый). Для Firefox, Opera, Chrome, и Safari, вы можете использовать TTF или OTF файлы, как “сырые” или в некоторых случаях обернутые в WOFF файлы или как data URI внутри файла стилей. SVG будет основным форматом шрифтов, идущим вперед, но его основная добродетель сегодня заключается в поддержке в мобильном Safari для iPhone и iPad.

Да, это путает. Сначала. Всегда есть большие изменения. Но я ожидаю от веб-авторов сделать то, что они всегда делают. Найти путь заставить это все работать. Сырые материалы  здесь и здесь. Инструменты здесь и здесь. Решения здесь и здесь. Так сложите вместе несколько страниц примеров и темплейтов, и приготовьтесь к распутью. Время пришло.

Translated with the permission of A List Apart Magazine and the author[s].

Стартовал единственный в своем роде технологический конкурс вебсайтов Рунета WebHiTech 2010. Заявки на участие принимаются до конца октября. Заявить на конкурс можно не только свой сайт, но и любой понравившийся вам сайт в соответствии с правилами и номинациями.

Уже второй год я состою в жюри конкурса, что не дает мне права участия. Ну а вы, дерзайте.

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

Проблема в том, что стандарт еще не доработан, большинство “вкусностей” еще впереди, хочется верить. Ну и как обычно, Internet Explorer не поддерживает фактически ничего из этого стандарта. Да что там фактически, ничего. Даже отрисовку элементов из HTML5 приходится задавать через Javascript.

До недавнего времени было довольно сложно валидировать документы на HTML5, так как валидаторы плевались на DOCTYPE без ссылки на DTD.

DOCTYPE HTML5:

<!DOCTYPE html>

Существовал только один HTML5 валидатор, да и тот в разработке.

На данный момент этот валидатор все еще находится в разработке, но работает уже довольно корректно. Помимо этого, валидатор всех валидаторов от отцов из W3C уже поддерживает валидацию HTML5, не без помощи Mozilla Foundation. Появилось расширение для Firefox.

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

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

Количество посетителей сайтов с разрешением 800х600 не только не уменьшится, а увеличится. Связано это напрямую с развитием субноутбуков, кпк, мобильников и прочих переносимых девайсов. Добрая половина субноутбуков уже сейчас имеет разрешение 1024х600, но сайт, оптимизированый под 1024х768, открытый на таком экране, в большинстве случаев будет неудобоваримым так как займет всё окно браузера. А в дизайне, как известно, важны пустоты.

Поэтому я предлагаю перестать игнорировать 800х600 и начать смотреть на этот вопрос под другим углом. Мне кажется разумным:

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

Таким образом, мы убиваем одним выстрелом двух зайцев. У сайта появляется полноценная мобильная версия, и мы заботимся о посетителях с маленьким… разрешением.

Добавление файла стилей для мобильных устройств делается так:

<link rel="stylesheet" type="text/css" media="handheld" href="mobile.css" />

Про корректное оформление мобильной версии сайта можно почитать на старом добром ресурсе A List Apart.

Переключать стили можно с помощью JQuery вот так или так.

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

Часть первая.

Второй день конференции начался с жестокого похмелья доклада Nate Koechley под названием “Professional Front-End Engeneering”. Как Нэйт и обещал, он толкнул зажигательную речь о Front-End’е и его значении в веб-разработке. Особый упор был сделан на том, что Front-End веб-разработка по сути своей ни чем не отличается от архитектуры и поэтому отношение к ней, со стороны разработчика и его начальства не должно быть другим. Архитектор, проектируя здание, не позволяет себе махнуть рукой на то, что будет с домом через 5—10 лет, проект наполняется чертежами, схемами, документацией и тд. Так почему разработка сайтов должна отличаться?

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

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

Понравилась фраза Нэйта — We are responsible for the “View source”!

Вслед за Нэйтом на сцену поднялся Jonathan Snook, известный канадский веб-разработчик — фрилансер. Его доклад, “Building on the Shoulders of Giants”, основывался на том, что многие веб-разработчики любят каждый раз изобретать велосипед. Само по себе это не так уж и плохо, особенно в начале профессионального пути, так как помогает понять основы и приобрести свои наработки. Но подобный подход в конкурентной среде является серьезным минусом, так как обладая какой-либо идеей и затрачивая огромное время на ее разработку с нуля, вы рискуете прийти на рынок далеко не первым; всем известно что одинаковые идеи приходят различным людям в голову одновременно и побеждает тот, кто реализует задуманное быстрее остальных.

Джонатан призвал использовать опыт гигантов отрасли для своих нужд и реализовывать идеи быстро, с минимальными затратами ресурсов и времени. Основная мысль в том, чтобы используя открытые наработки, API, библиотеки и базы знаний реализовать первичную версию своего проекта, “застолбить территорию” и после этого спокойно продолжать разработку, заодно получая бесплатный bug-track от бета-тестеров и фокус-групп. В докладе Джонатан привел пример реализации простого приложения, основанного на API Twitter и Jquery, в котором твиты располагались на странице в виде временной шкалы. По его словам, это приложение он написал за несколько часов, вечером перед конференцией. Дополнителый пример, уже пользующийся успехом в Северной Америке, приведенный на конференции, MyMileMarker. Кстати любители римейков могут попробовать реализовать подобный сервис в Рунете ;)

Любопытный момент, о котором говорил Джонатан, заключается в том, что при использовании открытых API, разработчик выступает в роли посредника между сервисом и пользователями и в случае сбоев в работе сервиса/API, например Twitter’a, пользователи разработанного вами приложения будут винить именно вас, а не Twitter. Поэтому такие моменты нужно обдумывать заранее и стараться предотвращать.

Следующий доклад доклад был посвещен Javascript-библиотекам и вел его никто иной как John Resig, создатель и главный разработчик Jquery. Само название доклада “The Why and Which of JavaScript Libraries” уже создавало проблему так как Джон, как лицо лично заинтересованое, не мог дать объективное объяснение того, какая библиотека лучше и ее стоит использовать. Он конечно же сам это понимал и поэтому посторил доклад на сравнении библиотек по различным характеристикам.

Начал издалека, с общих сведений, прошелся по статистике использования (большинство разработчиков используют Jquery(32%) и Prototype(32%), остальное делят между собой YUI(20%), Dojo и иже с ними), пробежался по характеристикам. Доклад получился обзорным, почти без конкретики, но по моему мнению только из-за тотальной нехватки времени. В сухом остатке, Jquery и Prototype — лидеры, без сюрпризов.

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

После обеденного перерыва с докладом “WAI(Web Accessibility Initiative) – ARIA(Accessible Rich Internet Applications) – It’s Easy” выступил Steve Faulkner из Paciello Group, который является директором The Web Accessibility Tools Consortium (WAT-C). Речь шла о доступности веб-приложений и сервисов для людей с ограниченными визуальными возможностями. В роли подопытного кролика снова выступал многострадальный Twitter. На примере использования дополнительных атрибутов в разметке, Стив хотел показать относительную легкость создания документов, которые будут более корректно обрабатываться Screen Reader’ами и управление ими будет более доступным. Но все оказалось не таким простым.

Примеры, которые приводил Стив, работали только на синтетических тестах, код которых Стив не показал. Кроме того, документы в которых добавляются атрибуты от WAI-ARIA становятся невалидными, так как WAI-ARIA еще не стала рекомендацией W3C. Не обошлось и без курьеза. Во время одной из демонстраций, Screen Reader JAWS, подключеный к общим колонкам, решил выступить с самостоятельной речью со скоростью 120 слов в минуту. Разволновавшийся Стив довольно долго не мог его успокоить и зал довольно долго хихикал иногда переходя на сдавленое ржание :)

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

Заключительный доклад конференции, на который я пошел, был “Exploring the Server Side: Rails & Django”, который вели по очереди James Adam и Simon Willison. Цель доклада заключалась в представлении серверных технологий Front-End разработчикам для общего развития и для того чтобы заинтересовать потенциальных пользователей. Доклады получились легкими, полными примеров и “живого” написания кода во время доклада. В моем случае доклады достигли цели, так как я, незнающий ни Ruby ни Django, заинтересовался и буду пробовать :)

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

Собственно на этом доклады закончились и началась секция Вопросов и Ответов. На секции долго решали как же все таки правильнее называть Front-End Web Developer или Front-End Engeneer. В конце концов решили что не в названии дело, а в важности этой профессии в процессе веб-разработки. До моего вопроса про Javascript-библиотеки так и не дошли.

Общие впечатления:

Первый день конференции немного подкачал, но это субъективное мнение. Второй день исправил положение но чувствовалась нехватка конкретики и все время присутствовало ощущение типа “ну, вот-вот, сейчас будет, сейчас зажгут”, но как-то оно не очень оправдалось.

Очень порадовала возможность общения с другими веб-разработчиками, обмен мнениями и опытом, ощущение если не братства, то гильдии :)

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

29-30 Мая в Лондоне прошла четвертая конференция для веб-разработчиков @Media. Мне посчастливилось на ней побывать и я, как и обещал, публикую отчет о поездке. Для начала немного общих сведений о конференции:

@Media проводится уже в четвертый раз и обычно это происходит в Сан Франциско, Лондоне и Гонг Конге с промежутком в неделю, в течении месяца. В этом году конференция проводилась только в Лондоне, не смотря на то, что изначально была заявлена и в Сан Франциско. Причина отмены американской части конференции мне не известна.

Ежегодно в конференции принимают участие многие мастистые и известные разработчики и дизайнеры из разных стран. Фактически каждый год конференцию почитают своим присутствием представители Google, Yahoo, W3C, Clear Left, 37 Signals и других известных компаний и веб-студий.

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

В общем конференция эта во многом знаковая и задающая тон сообществу веб-разработчиков. По крайней мере так было, и я надеюсь что будет. А теперь перейдем собственно к отчету и тому что было в этом году.
День первый.

Конференцию открыл Джеффри Вин из Google (до мая 2008). Джефф хороший докладчик и сразу создал благоприятную атмосферу, и свою открывающую речь продолжил докладом “Designing Our Way Through Data”. Основная мысль доклада состояла в том, чтобы предоставляя информацию посетителям сайта, не заставлять их думать. Все должно быть наглядным и не вызывать сомнений.

Все было бы чудесно, если бы в последствии я не узнал что в своем докладе Джефф использовал солидные куски из доклада на @Media 2006. Это конечно не сделало сам доклад хуже, но оставило небольшой осадок.

Следующий доклад вела Инди Янг из компании Adaptive Path. Сессия называлась “Mental Models: Sparking Creativity Through Empathy” и речь в ней велась в основном об организации рабочего процесса, создании атмосферы для производства креативных решений и подобным вещам. Говорились правильные вещи, но мне доклад не очень понравился, возможно из-за манеры речи.

Вслед за Инди, я был на сессии с интригующим названием “Getting Your Hands Dirty with HTML5″, которую вели Джеймс Грэхем и Лаклэн Хант. Ребята старались доказать преимущества HTML5 перед XHTML2, объясняя на пальцах общие моменты и мотивируя все обратной совместимостью.

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

“Живые” примеры в докладе не использовались, до этого развитие проекта еще не дошло. Очень спорным преимуществом оказался пример развития, выраженый в добавлении элемента video, который призван обрабатывать видеоматериалы на равне с элементом img, обрабатывающим изображения. Это заявление разработчиков меня озадачило, так как я сразу же подумал о том, как элемент video будет справляться с огромным количеством кодеков и форматов видео. Когда я спросил об этом одного из докладчиков, после лекции, то вразумительного ответа так и не получил.

После этого доклада был большой перерыв на обед. Кормили кстати на конференции неплохо и помимо обеда во время всех докладов действовали буфеты, в которых можно было заправиться кофе, чаем, соком и кондитерскими изделиями. Естественно все было бесплатным (еще бы, стоимость участия в конференции, составляющая более 500 фунтов за два дня покрывает такие “мелочи”).

Послеобеденную часть конференции открыл доклад Дрю Маклиллана о CMS’ках. У меня были определенные надежды на эту сессию, но к сожалению они разбились о суровую реальность. Доклад получился сухим, неинтересным и в конце концов свелся к ненавязчивой рекламе собственной разработки его студии. Стоит ли говорить о том, что ближе к концу доклада я стал клевать носом, как и многие другие?

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

К счастью, на выручку страждущим явился Дэн Рубин, который работает с сайтами известных СМИ и ведет начало своей деятельности из типографии. Дэн наглядно показал, что в течении 20 минут, с помощью гридов и работы с текстом в CSS можно превратить неудобоваримый сайт Fox News во что-то более пристойное и подобное хотя бы сайту CNN.

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

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

С горя дернув чуть ли не залпом литр пива я вышел покурить и… сразу же наткнулся на Nate Koechley, ведущего Фронт-енд Инженера Yahoo и Peter-Paul Koch’a, в народе известного как PPK и ведущего сайт http://www.quirksmode.org. Завязалась беседа, в ходе которой я понял что они тоже недовольны первым днем конференции и попытался выснить причины происходящего, а заодно спросил у Питера почему он не выступает с докладом в этот раз.

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

Нейт, в свою очередь, вселил в меня надежду, сказав что первый день отдан на растерзание дизайнерам, контентщикам и иже с ними, а уж завтра то он “воткнет флаг Фронт-Енда в эту сцену”.

И вот с этими мыслями я пополз в гостиницу в ожидании второго дня конференции.

Продолжение следует.

Если у вас болит зуб, вы обращаетесь к стоматологу или бежите к соседу с просьбой “Вась, а Вась, вон зуб, третий слева, выбей долотом пожалуйста, а то болит очень”?

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

Почему любой пацаненок, посидевший пару дней за Dreamweaver’ом уже считает себя вебмастером? Почему дядя Вася из Мухосранска, который тачает ложки, наслушавшись подсказок сына, открывает свой “сайт”, а его сосед с третьего этажа, дядя Коля, идет в агенство и платит немалые деньги за разработку сайта со столярными услугами?

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

Фактически, это засорение Сети, в которой уже и так более 170 000 000 сайтов (а может и больше), из которых полезными является треть, если не четверть. Причин много, я не берусь лезть в глубокую аналитику, но часть из них на поверхности.

Частично вина лежит на самих веб-разработчиках. Ежедневно появляется какой-нибудь сервис, позволяющий “создать свой сайт за 5 минут”, расскажет “о всех секретах дизайна за 10 минут” или еще чего лучше позволит “взять” дизайн любого, понравившегося вам сайта, и сделать из него ваш сайт. Вы только пишите, пишите. И все будет хорошо. А кто эти сайты делает? … Правильно.

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

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

Ощущение вседозволенности и атмосфера игры. Почти все, попадающие в Сеть впервые, ощущают это. У некоторых это ощущение проходит, у некоторых остается. У вторых просто не возникают мысли типа “а надо ли это?” или “а может спросить знающего человека?”, потому что “это Интернет, здесь все можно”. Соответственно можно и странички клепать, можно муру писать, можно “нарисовать” сайт в онлайн-конструкторе за полчаса.

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

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

З.Ы. А вобще конечно, не так все плохо, как вам может показаться по прочтении этой писанины. Просто надо “уважать труд уборщицы” :)

“- А ведь это о чем то да говорит” – подумал я и начал прикидывать подсчеты в уме. Если меньше чем за полгода количество людей с маленьким ..ээ.. экраном уменьшилось на 10 процентов, то к концу года они вобще почти пропадут! (Экраны, не люди :) )
Да и сама по себе цифра 6-7 процентов уже является незначительной. Приблизительно столько же пользователей не используют Javascript.
Потом я решил взглянуть кто из общеизвестных сайтов поддерживает 800х600. Наблюдается такая картина (выбор абсолютно произвольный):

• yahoo.com – нет
• yandex.ru – нет
• mail.ru – да(!)
• microsoft.com – нет
• apple.com – нет
• youtube.com – нет
• rambler.ru – да(!)
• digg.com – нет

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

Удивили только Рамблер и Мэйл.Ру, от них ожидал меньше всего, а вот поди ж ты.

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

Уже сейчас аудитория с разрешением экрана выше чем 1024х768 как минимум в четыре раза больше чем аудитория с разрешением 800х600 и разрыв будет только увеличиваться. Так кого выгоднее и перспективнее поддерживать?

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

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

Можно определять разрешение экрана и подсовывать CSS в зависимости от него. Но это проблема. Не каждый дизайнер будет делать 2 или 3 макета, да и не всегда это будет целесообразным. Работа увеличивается вдвое, а отдача стремится к нулю. Причем с хорошим ускорением.

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

Будем исходить из того что нам нужен максимум посетителей. При разработке сайта надо делать макет для резолюции 1024х768, но важную информацию/блоки помещать в “кубике” с размерами 800х600 (760х430), начиная с левого верхнего угла окна.

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

Это конечно только частичное решение, но мне кажется что с каждым месяцем оно будет все актуальнее.

Единственная оговорка всего моего мини-анализа в том, что статистика по Рунету ограничена Спайлогом и Liveinternet по памяти.
Интересно послушать ваше мнение по этому вопросу, друзья.

Есть картинка, размером 1200х800 пикселей, на которой расчерчена каркасная решетка разметки квадратами со стороной 50 пикселей. Картинка вставляется как фоновое изображение в body и упрощает визуальное размещение блоков во время верстки.

Как говорится, “дешево и сердито”, но может оказаться полезным многим.

Забираем картинку здесь.