Микроформаты

Недавно открылся сайт microformats.org, на котором собраны и будут разиваваться заслужено набирающие ныне моду микроформаты. Их придумал дядька по имени Тантек Селик, который, кстати, в свое время сделал движок макинтошного IE, самый инновационный для своего времени. Микроформаты - идея гениальная, хочу написать о них подробно.

Ограничения семантики XHTML

Начну, как обычно, издалека. XHTML (или HTML, что пока неважно) - язык интересный. Одна из интересностей заключается в том, что этот язык, придуманный для описания структуры документов на вебе, обладает еще и семантикой.

Говоря по-русски, семантика в этом случае - это официально определенный смысл конкретного элемента. Например, элемент <em> означает усиление части текста, элемент <strong> - еще большее усиление, <code> - код компьютерной программы. То есть все эти элементы обладают определенной семантикой. Есть также элементы, которые никакой семантикой не обладают. Например элементы <i> или <b>. В отличие от <em> и <strong> они не означают какого-то усиления значимости текста, а только показывают, что эти элементы должны быть отображены курсивом и жирным шрифтом.

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

<code> int i = 0; </code>

то он поймет, что это код. А если

<font face="Courier New" color=#0000FF><b> int i = 0; </b></font>

то не поймет.

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

Опять пример. Возьмем те самые ресторанные рейтинги. Если вам нужно найти ресторан, вы можете отправиться в поисковик, найти там парочку (десятков) сайтов по словам "ресторанный рейтинг" и просмотреть несколько понравившихся вам. Причем, на каждом сайте будет свой дизайн, своя навигация, информация там будет повторяться и противоречить друг другу. Сам недавно этим занимался, и замечу, что процесс довольно муторный :-). А теперь представьте, как бы было хорошо, если бы ресторанные рейтинги оформлялись с помощью определенных и известных элементов, специально предназначенных для описания нужных полей: название заведения, местоположение, рейтинг по пятибальной шкале, автор обзора, дата обзора... Тогда поисковик мог бы сам индексировать все это и представлять в едином сводном виде, вычислять средний бал с разных обзоров и предоставлять еще какой-нибудь сервис.

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

Преимущества микроформатов

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

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

Однако, изюминка заключается в том, как именно они расширили язык. Ведь просто так новых тегов или новых атрибутов добавить не получится: это будет уже не (X)HTML, и его перестанут нормально обрабатывать существующие клиенты: браузеры и тулзы всякие. Однако, на счастье у (X)HTML'а оказалась пара мест, которые самим стандартом допускают расширения. Это атрибуты rel и class.

Атрибут rel есть у ссылок, причем как у обычных <a>, так и у менее известных <link>. Предназначен он для того, чтобы показывать "тип" этой самой ссылки. Например, чтобы показать, что для вашего документа есть таблица стилей, вы включаете в него <link rel="stylesheet" ...>, или, например, если у него есть альтернативное представление в формате Atom, то <link rel="alternate" type="application/atom+xml"...>. Или если даете ключевую ссылку на статью блога, то чтобы показать, что она постоянная, пишете <a href="..." rel="bookmark">.

Атрибут class предназначен для вольных пометок элементов для каких угодно целей. Конечно, чаще всего он используется для того, чтобы к нескольким элементам на странице применить какие-то общие стили. Но может использоваться еще и, скажем, для скриптования. Например, можно скриптом пробежаться по элементам списка, а те, у которых стоит опреденный класс, добавить кнопку сворачивания.

Так вот, авторы микроформатов по сути всего-навсего устанавливают совершенно конкретные значения для class'ов и rel'ов, приписывая им конкретный смысл, который можно использовать при машинной обработке

Пара примеров микроформатов

Вот собрались, например, люди и сказали, что отныне, если у ссылки в атрибуте rel присутствует значение friend, значит это ссылка на личную страничку вашего друга (или, точнее, на страничку, которая, как вы считаете, хорошо его описывает). А если там стоит met, значит вы встречались с этим человеком лично. И много других веселых значений. Теперь весь этот ими придуманный набор называется XFN. И теперь на rubhub можно централизовано узнать об отношениях друг с другом всяких известных и не очень людей.

Другой пример. Для обзоров и рейтингов придумали микроформат hReview. Теперь, если вы пишете описание того, как вы сходили с друзьями в Макдональдс, и как вам это понравилось:

<h3>Сходили в Макдональдс</h3>
<p>Сходили вчера вечером впервые в жизни в Макдональдс, 
все было классно!</p>.
...
<p>Автор: Вася Пупкин</p>

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

<div class="hreview">
  <h3>Сходили в <span class="item fn">Макдональдс</span></h3>
  <p class="description">Сходили <abbr class="dtreview" title="20050625T2000+0400">вчера вечером</abbr> впервые 
  в жизни в Макдональдс, все было <abbr class="rating" title="5">классно</abbr>!
  </p>.
  ...
  <p>Автор: <span class="reviewer fn">Вася Пупкин</span></p>
</div>

Причем, с точки зрения графического браузера не изменилось практически ничего! Не знаю, как вас, а меня просто восхищает красота решения. Особенно в мелких деталях, когда человеческому "вчера вечером" с помощью родного XHTML'ного элемента <abbr> дается машиночитаемое значение времени в жестком формате ISO.

Об "официальности"

Теперь вопрос. А почему, собственно, все должны пользоваться именно этими значениями? И почему любой другой человек не может придумать свои? Всего только потому, что у создателей XFN'а и других микроформатов хватило известности, связей и здравого смысла сделать эту вещь удобной известной и используемой. Например, тот же XFN уже поддержан в системе ссылок блог-системы WordPress и в HTML-редакторе Nvu.

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

Некоторые смежные проблемы

Одна из проблем (на мой взгляд) микроформатов заключается в том, что авторы решили определить их только для XHTML, но не для HTML. Причем, это очень обосновано, потому что весь смысл XHTML'а, как переформулирования HTML'а в XML'ном синтаксисе, был как раз в том, чтобы облегчить его машинную обработку. Однако, на практике это означает, что не любую существующую страничку можно легко заточить под какой-нибудь микроформат, сначала надо добиться того, чтобы она была, по крайней мере, well-formed XML'ом.

Другая проблема - общая для всех усилий внедрить на вебе семантику. Авторам, привыкшим, что веб-страница - это то, что показывает их любимый браузер, очень трудно порой объяснить, что существует выгода от того, что они будут использовать семантические элементы там, где это необходимо. Причем, трудность не в том, что авторы "плохие", а в том, что это требует гораздо больше усилий, а выгода проявляется не сразу. Больше того - даже еще не известно, проявиться ли она по-настоящему. Ведь пока авторы не делают много семантически верных страниц, создатели потенциальных тулзов и сервисов, которые могли бы использовать семантику, не будут их создавать, потому что работать просто не с чем. То есть, классическая проблема "яйца и курицы". Однако, есть надежда, что усилиями крупных энтузиастов в лице microformats.org и Google, поезд все таки разойдется. По крайней мере, я надеюсь застать это интересное время :-). А пока, пойду, сверстаю страничку "Об авторе" для этого сайта, используя микроформат hCard...