Атрибут itemscope в HTML

Содержание

Универсальный атрибут itemscope

Описание

Атрибут itemscope задаёт область действия словаря в структуре данных. Как правило, работает совместно с атрибутом itemtype и задаёт пределы, где itemtype будет активен.

Синтаксис

Значения

У этого атрибута нет значений.

Значение по умолчанию

Пример

Спецификация ?

Спецификация Статус
HTML Microdata W3C Working Group Note

Спецификация

Каждая спецификация проходит несколько стадий одобрения.

  • Recommendation ( Рекомендация ) — спецификация одобрена W3C и рекомендована как стандарт.
  • Cand >Возможная рекомендация ) — группа, отвечающая за стандарт, удовлетворена, как он соответствует своим целям, но требуется помощь сообщества разработчиков по реализации стандарта.
  • Proposed Recommendation ( Предлагаемая рекомендация ) — на этом этапе документ представлен на рассмотрение Консультативного совета W3C для окончательного утверждения.
  • Working Draft ( Рабочий проект ) — более зрелая версия черновика после обсуждения и внесения поправок для рассмотрения сообществом.
  • Editor’s draft ( Редакторский черновик ) — черновая версия стандарта после внесения правок редакторами проекта.
  • Draft ( Черновик спецификации ) — первая черновая версия стандарта.

Особняком стоит живой стандарт HTML ( Living ) — он не придерживается традиционной нумерации версий, поскольку находится в постоянной разработке и обновляется регулярно.

Семантическая разметка и микроформаты

Веб-программирование — HTML5 — Семантическая разметка и микроформаты

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

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

Идея семантически осмысленной разметки не является новой. В действительности, давным-давно, когда HTML5 существовал только в задумках Яна Хиксона (Ian Hickson), редактора группы WHATWG, многие веб-разработчики настойчиво искали методы для создания более осмысленной разметки. Не всегда их требования — совпадали: одни хотели улучшить доступность своих веб-страниц, другие — возможность для интеллектуального анализа данных, а третьим просто хотелось повысить фактор впечатляемости своего резюме. Но никто из них не смог найти то, что им требовалось в стандартном языке HTML, вследствие чего было создано несколько новых стандартов, чтобы заполнить этот пробел.

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

Стандарт Accessible Rich Internet Applications

Развивающийся стандарт Accessible Rich Internet Applications (ARIA, доступные активные веб-приложения) позволяет предоставлять дополнительную информацию для программ чтения экрана (скрин-ридеров) с помощью атрибутов любого элемента HTML. Среди прочих, в нем вводится атрибут role, который указывает назначения данного элемента.

Например, назначение представляющего верхний колонтитул элемента:

можно довести до сведения программ чтения экрана, присвоив атрибуту role значение banner:

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

Этот пример иллюстрирует два важных факта. Первый: стандарт ARIA требует использования одного из коротких списков рекомендованных названий ролей. Второй: некоторые части стандарта ARIA перекрывают семантические элементы HTML5, что вполне логично, т.к. ARIA появился раньше HTML5. Но это не совсем полное перекрытие. Например, некоторые названия ролей дублируют элементы HTML5 (скажем, banner и article в то время как другие являются более продвинутыми (например, toolbar и search).

Стандарт ARIA также вводит два атрибута для работы с HTML-формами. Атрибут aria-required в текстовом поле указывает, что пользователю нужно ввести значение. А атрибут aria-invalid указывает на недействительность текущего значения в текстовом поле. Польза от этих атрибутов в том, что программы чтения экрана могут пропустить визуальные подсказки, которыми руководствуются пользователи с нормальным зрением при заполнении форм, например, звездочку рядом с заполненным полем или красный мигающий восклицательный знак рядом с полем с неправильным введенным значением.

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

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

Стандарт Resource Description Framework

Стандарт Resource Description Framework (RDFa — инфраструктура для описания ресурсов — в атрибутах) определяет правила для интегрирования подробных метаданных в веб-документы посредством атрибутов. У стандарта RDFa есть значительное преимущество перед другими подходами: это стабильный, установившийся стандарт.

Но у него также два значительных недостатка. Первый — это сложный стандарт. Разметка со вставленными в нее метаданными RDFa получается намного объемистей и существенно неуклюжей, чем обычная HTML-разметка. Второй — стандарт этот разработан для применения с XHTML, а не с HTML5. В настоящее время несколько сверхинтеллектуальных веб-гуру занимается разработкой лучших способов адаптирования RDFa для работы с HTML5. Но, возможно, что RDFa просто не приживется в мире HTML5, т.к. ему больше подходят строгий синтаксис и железные правила XML.

Здесь стандарт RDFa не рассматривается. Но если вы хотите узнать больше о нем, солидный обзор можно получить на странице en.wikipedia.org/wiki/RDFa. А на веб-сайте Google Rich Snippets можно ознакомиться с версиями RDFa для всех примеров расширенных фрагментов Google.

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

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

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

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

Прежде чем помечать данные микроформатом, нужно выбрать, какой именно микроформат использовать для этого. Широко применяется всего лишь пара десятков микроформатов, большинство из которых продолжает совершенствоваться и обновляться. Информацию о доступных микроформатах и подробное описание каждого из них можно найти на веб-сайте Microformats. Наибольшей популярностью среди всех этих микроформатов пользуются два — hCard и hCalender, которые мы и рассмотрим.

Обозначение контактной информации с помощью микроформата hCard

Микроформат hCard предоставляет универсальный способ обозначения контактной информации для физического лица, компании или места. По результатам последнего подсчета Интернет содержит свыше 2 млрд hCard, что делает этот микроформат безоговорочно самым популярным.

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

Для создания hCard требуется корневой элемент, который присваивает атрибуту class значение vcard. Внутри этого элемента необходимо посредством другого элемента предоставить, по крайней мере, отформатированное имя. Атрибуту class этого внутреннего элемента нужно присвоить значение fn. Вот приводится пример такого определения:

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

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

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

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

Одним из таких расширений является Oomph для Internet Explorer, которое можно загрузить с веб-сайта oomph.codeplex.com. Этот модуль автоматически исследует каждую посещаемую веб-страницу на предмет наличия в ней трех форматов: hCard (для контактной информации), hCalendar (для календарей событий) и hMedia (для изображений, аудио и видео). В случае обнаружения в странице данных, помеченных одним из этих форматов, в левом верхнем углу окна браузера выводится значок Oomp. Щелчок по этому значку выводит в браузере всю обнаруженную информацию, а также элементы управления для обработки.

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

Теперь все посетители вашей страницы получат возможность доступа к помеченным микроформатами данным страницы, независимо от используемого ими браузера:

Обозначение событий с помощью микроформата hCalendar

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

Если вы разобрались в том, как помечать информацию микроформатом hCard, у вас не будет никаких трудностей и с микроформатом hCalendar. Сначала событие нужно поместить в элемент с названием класса vevent. Внутри этого элемента нужно поместить, по крайней мере, две единицы информации: дату начала (которая помечается классом dtstart) и описание события (которое помечается классом summary).

Микроданные

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

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

Чтобы создать блок микроданных, нужно добавить атрибуты itemscope и itemtype в любой элемент (хотя логичнее будет создать элемент

Тип данных обозначается предопределенной, однозначной текстовой строкой, называющейся пространством имен XML. В данном примере пространством имен XML является формат для кодирования рейтинга http://data-vocabulary.org/Review-aggregate.

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

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

По существу, самая большая разница между микроданными и микроформатами состоит в использовании в первых для маркировки данных атрибута itemprop, а не атрибута class, как в последних.

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

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

Микроданные

Спецификация микроданных (Microdata) — самая молодая из описываемых здесь. Она создавалась с учетом опыта использования своих предшественников, и именно она стала частью HTML5. Основное ее отличие состоит в том, что смысловая нагрузка к любому HTML-элементу придается добавлением к нему специального набора атрибутов. Прилагается также специальный DOM API для работы с микроданными из сценариев веб-страницы.

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

Более известный как

Подробнее обо мне:

Г. Эгвекинот, Чукотский АО

3-я улица Строителей, дом 25, квартира 12

В Nord Software

+7 (952) 345 67 89 parovozoff@yandex. ru

Мои контакты в соцсетях:

Разберем, что значат все эти item*, на конкретном примере. Создадим разметку анонса исторического события — выступления в Санкт-Петербурге прославленного блюзмена Джо Банамассы (Http://en. wikipedia. org/wiki/Joe_Bonamassa), которое состоится 14 марта в ДК Горького. (Книга наверняка выйдет после концерта, так что кусайте локти.)

Сначала создадим обычную разметку:

JOE BONAMASSA. Новый король блюза. Впервые в Санкт-Петербурге!

14 марта 2012 г

Сан: //www. gorkogo. spb. ru/т-Петербург (ДК им. Горького) пл. Стачек, д. 4.

Начало концерта: 19.00

Что может получить из этого привычного текста, например, поисковый робот? Примерно то, что изображено на рис. 26, — прямо скажем, не очень много. Попытаемся исправить положение с помощью механизмов Microdata. Прежде всего добавим пару новых атрибутов обрамляющему тегу

Рис. 26. Словарь Events

Первый, itemscope, задает границы действия словаря (в данном случае — тег

Вспомним, что микроданные представляют собой пары ключ/значение. Но берутся эти ключи не с потолка, а из особого словаря, который, впрочем, теоретически может завести любой программист, задающий пространство имен (строго говоря, его даже не обязательно публиковать, если, конечно, вы не хотите, чтобы с ним работали и другие разработчики). Здесь мы воспользуемся уже существующим словарем (и это в общем случае правильно!). Он совершенно равноправен с тем, что мы могли написать сами, но обладает несомненным достоинством — формат его данных понимает Google и другие поисковые системы. Наш словарь расположен по адресу Http://www. data-vocabulary. org/Event / и представляет собой следующую таблицу (рис. 27). Как видите, это настоящий словарь в прямом значении этого слова, и вот какие термины нам сразу понадобятся:

— summary (Required) — название мероприятия;

— Location — место проведения мероприятия;

— startDate (dtstart) (Required) — дата и время начала мероприятия;

— eventType (category) — тип мероприятия — концерт, лекция, демонстрация и т. д.;

— photo — фотография или картинка, связанная с мероприятием.

Рис. 27. Событие в поисковой выдаче, проиндексированное до разметки метаданными

Впрочем, про summary, startDate и Location можно было не говорить. Они помечены как обязательные (Required), и если мы хотим пользоваться этим словарем, то должны их задать. Это вполне логично, так что примемся за дело:

JOE BONAMASSA. Новый король блюза. Впервые в Санкт-Петербурге!

14 марта 2012 г Начало концерта: 19.00

Санкт-Петербург (ДК им. Горького) пл. Стачек, д. 4.

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

В общем случае этим значением будет текстовое содержимое тега (то есть для content будет верна пара — foo’=>’content-).

— элемент — значение атрибута content;

— элемент — значение атрибута data.

И наконец, все еще спорный на момент написания статьи элемент (HTML5) — значение атрибута datetime.

Таким образом, любой парсер, обрабатывающий наш анонс, прочтет следующий ассоциативный массив:

”summary”=>”JOE BONAMASSA. Новый король

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

Это уже хорошо, но есть что улучшить. Значением ключа location у нас является Петербургский ДК имени Горького, который, хоть и отлично знаком питерским меломанам, для поисковых роботов является просто строчкой текста. Исправим это положение вещей, вставив микроданные из другого словаря — Organization, причем сделаем это внутри родительского элемента, обозначенного зоной действия словаря Event:

Рис. 28. Событие в поисковой выдаче, проиндексированное после разметки метаданными

Впрочем, для представления адреса также есть словарь, который нам никто не запрещает применить:

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

А теперь вернемся к словарю Organization. В него входит очень интересный ключ:

Geo — Specifies the geographical coordinates of the location. Includes two elements: latitude and longitude.

Да, это возможность обозначить геолокационные данные организации.

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

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

Стандартным выходом из такого положения будет следующая разметка:

Тег span просто использует текстовое содержание дочернего элемента.

Еще один аспект заключается в обработке одинаковых элементов. Но тут все просто. Может ли, например, у одного человека (словарь Person) быть несколько фото (itemprop=»photo»)? А почему бы, собственно, и нет?

Впрочем, здесь следует остановиться, идеи разметки, я думаю, совершенно понятны. Но это еще не все.

Микродата

Материал из AOW

Содержание

Введение

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

Микроклассинг/микроклассирование – разбивка текстовых данным на подблоки микродаты;

Перевод пояснительной статьи с http://schema.org/

Размещение текста с помощью микродаты

Как разметить текст с помощью микродаты?

Зачем нам микродата?

Веб-страница всегда имеет скрытый смысл, который пользователь понимает при чтении. Но поисковые системы понимают не все то, о чем написано на странице. С помощью дополнительных тегов в HTML-код страницы — тегов, которые говорят поисковикам «Эй, поисковик, тут написано об определенном фильме, или месте, или персоне, или видеоролике! «— можно помочь поисковикам и другим приложениям лучше понять содержимое и сделать его показ в поисковой выдаче более правильным и нужным. Микродата – это набор тегов, появившихся в HTML5, которые могут в этом помочь.

itemscope и itemtype

Начнем с конкретного примера. Представьте, что у нас есть страница о фильме «Аватар» — страница со ссылкой на трейлер фильма, информацией о режиссёре и т.д. Наш HTML-код может выглядеть примерно так:

Для начала определим блок с информацией о фильме на странице. Для этого добавим тег itemscope в HTML-код который включает нужную информацию внутрь себя, вот так:

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

Так мы определили, что содержимое div’а на самом деле о фильме, как типе из иерархии schema.org (Movie). Типы объектов определяются с помощью ссылки, в данном случае http://schema.org/Movie.

itemprop

Что еще мы можем рассказать поисковикам о фильме «Аватар»? У фильмов (Movie) есть разные интересные подробности, например: актеры, режиссер, рейтинги. Чтобы обозначить свойство объекта используется атрибут itemprop. Например, чтобы определить режиссера фильма добавим itemprop=»director» к тегу, включающему в себя имя режиссера. (Полный список свойств, заполняемых для фильма (Movie), можно найти на http://schema.org/Movie.)

Мы добавили дополнительный . , чтобы прикрепить атрибут itemprop к определенной части текста на странице. не влияет на отображение страницы браузером, поэтому он и удобен для использования с itemprop. Поисковики теперь смогут понять не только то, что www.avatarmovie.com – это ссылка, но и то, что эта ссылка на трейлер научно-фантастического фильма «Аватар», снятого Джеймсом Кэмероном.

Вложенные объекты

Иногда значение свойства объекта может само по себе быть объектом со своим набором свойств. Например, мы можем определить режиссера фильма как объект типа «Person», а у этого типа есть свойства name и birthDate. Чтобы определить то, что значение какого-то свойства является объектом, мы должны начать новый itemscope сразу же после соответствующего itemprop.

Использование словаря schema.org

Типы и свойства schema.org

Но все страницы только про фильмы и людей — дополнительно к типам Movie и Person, описанных в разделе 1, на schema.org описаны еще типы, у каждого из которых есть свой список свойств, которые можно использовать для описания объектов. Самый общий тип — Thing (Что-то), у которого есть свойства: name, description, url и image. Более точные типа наследуют свойства общих типов. Например, Place (Место) – более точный тип чем Thing, а LocalBusiness (МестныйБизнес) – более точный тип, чем Place. (На самом деле, LocalBusiness – более точный тип, чем Place и более точный тип, чем Organization, поэтому он наследует свойства обоих родительских типов.)

Набор часто используемых типов объектов:

  • Creative works (Творчество): CreativeWork(ТворческаяРабота), Book(Книга), Movie(Фильм), MusicRecording(МузыкальнаяЗапись), Recipe(Рецепт), TVSeries(ТВСериал) .
  • Вложенные нетекстовые объекты: AudioObject, ImageObject, VideoObject
  • Event (Событие)
  • Organization (Организация)
  • Person (Персона)
  • Place(Место), LocalBusiness(МестныйБизнес), Restaurant(Ресторан) .
  • Product(Продукт), Offer(Предложение), AggregateOffer
  • Review(Обзор), AggregateRating(ОбщийРейтинг)

Ожидаемые типы, тексты и ссылки

Несколько уточнений, на которые нужно помнить при форматировании страницы с помощью schema.org.

  • Больше – лучше, кроме скрытого текста. В общем – чем больше вы отформатируете контента, тем лучше. Однако главное правило – форматировать только тот контент на странице, который увидит пользователь, а не контент в скрытыхdivах ими каких-то других скрытых элементах.
  • Ожидаемые типа против текста. Просматривая типы schema.org, вы наверняка заметите, что многие свойства имеют «ожидаемый тип «. Это значит, что значение этого свойства может само быть вложенным объектом (секция 1d: Вложенные объекты). Но это не требование — абсолютно нормально включать обычный текст и ссылки. Также, если указан ожидаемый тип, то можно «вкладывать» объект более точного типа, чем ожидаемый. Например, если ожидаемый тип Place, то можно «вкладывать» тип LocalBusiness.
  • Использование свойста «url»(ссылка). На некоторых страницах находится информация про определенный объект. Например, у вас может быть страница про кого-то определенного, которую вы можете отформатировать с помощью типа Person. На других страницах есть наборы форматированных объектов. Например, на сайт вашей компании есть страница со списком всех сотрудников со ссылками на страницу профиля каждого сотрудника. Для таких страниц (с набором объектов) следует форматировать каждый объект по раздельности (в нашем случае – набор Person) и добавить свойство «url» к ссылке на соответствующую объекту страницу вот так:

Проверка форматирования

Точно так же, как браузер необходим для тестирования изменений на страницах сайта и компилятор — для тестирования нового кода – необходимо тестировать форматирование с помощью schema.org, чтобы быть уверенным в правильности его применения. Google предоставляет инструмент для тестирования «Rich snippets», с помощью которого можно проверить разметку и найти ошибки.

Дополнительно: Форматирование информации для более точного распознавания

Многие страницы можно описать используя только атрибуты itemscope, itemtype, и itemprop (описаны в разделе 1) вместе с типами и свойствами, определенными на schema.org (описаны в разделе 2).

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

  • Даты, время и длительность: использование тега time с datetime;
  • Перечисления и обычные ссылки: использование тега link с href;
  • Потерянная/неявная информация: использование тега meta с content.

Даты, время и длительность: использование тега time с datetime

Для машины бывает тяжело распознать даты и время. Например дата «04/01/11». Это – 11 января 2004? 4 января 2011? Или 1 апреля 2011? Чтобы сделать даты более понятными можно использовать тег time с атрибутом datetime. Значение атрибута datetime – это формат даты, использующий образец YYYY-MM-DD. Далее дата определяется точно, как 1 апреля 2011.

Также можно уточнять время с помощью формата hh:mm или hh:mm:ss. Времени предшествует префикс T, что позволяет использовать его вместе с датой, например вот так:

Посмотрим в контексте. У нас есть HTML описывающий концерт, который пройдет 8 мая 2011. Разметка «Event»(Событие) включает в себя название события, его описание, дату и время проведения.

Таким же образом можно уточнять длительность с помощью атрибута datetime тега time. Длительность обозначается с помощью префикса P (обозначает «период»). Вот как можно обозначить время готовки в 1,5 часа в рецепте:

Префикс H используется для обозначения количества часов, а префикс M — для количества минут. Стандарты обозначения времени, дат и длительностей определены в стандарте даты/времени ISO 8601.

Перечисления и обычные ссылки: использование тега link с href

Перечисления

Некоторый свойства могут иметь определенный список возможных значений. Программисты часто называют такие списки «перечисления». Например, для онлайн-магазина, продающего какой-то товар, можно использовать тип объекта Offer(Предложение), чтобы определить все детали сделки. Свойство availability может принимать значение из вполне определенного списка: In stock(на складе), Out of stock(нет на складе), Pre-order(предзаказ) и т.д. Как и типы объектов, определяемые с помощью ссылки, возможные значения перечисления также могут быть определены ссылкой на schema.org. Здесь приведен товар, размеченный с помощью свойств типа Offer(Предложение):

А здесь тот же самый товар, но описанный с помощью link и href, чтобы точно определить доступность товара, как одно из разрешенных значений:

Обычно, когда для свойства есть строго определенное количество значений – существует соответствующее перечисление, определенное в schema.org. В этом случае, возможные значения для availability определены в ItemAvailability.

Обычные ссылки

Обычно, ссылки определяются с использованием элемента . Например, вот HTML-ссылки на страницу в Wikipedia для книги «Catcher in the Rye»(«Над пропастью во ржи»).

Как видно itemprop=»url» можно использовать для уточнения ссылки на страницу на другом сайте (тут — Wikipedia), на котором обсуждается то же самое. Ссылки на сайты третьих сторон могут помочь поисковикам лучше понять, о каком объекте вы говорите на своей странице. Однако, вам может понадобиться добавить видимую ссылку на страницу. В этом случае вы можете использовать элемент link, примерно так:

Неявная информация: использование meta с content

Иногда на странице есть информация, которая представляет ценность для поисковиков, но не может быть отформатирована из-за специфики ее отображения на странице. Информация может быть «спрятана» в картинку (например: картинка показывающая рейтинг 4 из 5) или в Flash-объект (например: длительность видеоклипа), или информация может подразумеваться, но явно не показываться на странице (например: валюта цены). В таком случае используется тег meta с атрибутом content для определения информации. Обратите внимание на этот пример — картинка, показывающая рейтинг 4 из 5:

Вот пример с размеченной информацией о рейтинге:

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

HTML5, что является атрибутом itemscope и что он делает в неспециалистов?

November 2020

73.2k раз

Я просто хотел бы знать, что это HTML5 itemscope атрибут используется для в основном?

2 ответы

Поисковые системы , включая Bing, Google и Yahoo! В настоящее время с помощью itemscope и друзей , чтобы определить семантические данные в веб — страницах. На сайте schema.org , у них есть объяснение того , как использовать itemscope с предопределенными схемами для улучшения данных, которая предоставляется для поисковых систем.

[itemscope] Атрибут представляет собой логический атрибут , чтобы определить объем метаданных , содержащихся в элементе.

Это определено в HTML5 микроданных API:

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

Элемент с itemscope атрибутом указанного создает новый элемент , группу пар имя-значение.

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

Это используется Schema.org API для связывания данных для поисковых систем и социальных сетей. Google+ использует схему как способ обеспечить названия, эскизы и описание для страниц общих пользователей.

Следует также отметить , что [itemscope] и [itemprop] совместимы с Facebook, Open Graph протокола при предоставлении метаданных для веб — страницы. Же метаданные могут быть перечислены для поисковых систем, Facbook и Google+ в одном наборе элементов , вместо того , чтобы перечислить ту же информацию несколько раз:

Обратите внимание , что в данном примере, [itemscope] был добавлен к элементу. Это означает , что любые [itemprop] атрибуты в и являются частью WebPage пункта.

Немного о Microdata

Доброго времени суток! В этой статье я бы хотел рассказать о микроданных и о словаре schema.org. Об этой замечательной технологии уже рассказывали на хабре два раза, но в них не было освещено несколько важных моментов.

Microdata

В HTML5 кроме всего прочего имеется стандарт призванный привнести немного семантики в Интернет. Конечно уже существуют такие стандарты как RDF и microformats но microdata был разработан с учётом их ошибок и даёт немало плюшек web-мастерам. Так, RDF подразумевает дублирование существующих данных, что, с учётом объёмов данных, может быть накладно. Микроформаты, в свою очередь позволяют разметить уже существующие документы, но отбирают такие полезные атрибуты как class .

Синтаксис

Для того чтобы сделать html элемент узлом микроданных, достаточно добавить ему атрибут itemscope . Неплохо было бы дать ему имя — для этого используется атрибут itemtype=»name_of_class» , а для точной характеристики используются вложенные элементы с атрибутом itemprop=»name_of_property» . Но в некоторых случаях пары ключ -> значение не хватает, и тогда в силу вступают вложенные узлы. Для их обозначения после атрибута itemprop нужно добавить атрибуты itemscope и itemtype .

Вот пример разметки (эта статья):

У некоторых свойств есть несколько возможных свойств, и использование, к примеру, русского языка может обернуться проблемой. Но, такие свойства можно обозначить тегом link :

В некоторых случаях контент виден пользователям, но не доступен поисковикам, к примеру — картинка. Тогда в ход идёт тег meta :

Словари

В примерах вы заметили, что я использую в качестве имён классов URI. Это поволяет их стандартизировать, ведь неплохо если о ваших классах знает кто-то ещё. На данный момент мне известно три словаря — microformats.org, data-vocabulary.org и shema.org. Предпочтительнее последний, так как его поддерживают крупнейшие поисковики (Google, Yahoo! Yandex и Bing) и он собирает в себе многие другие стандарты, например c тот же data-vocabulary.org. Каждый класс может иметь наследника и все свойства родителя передаются наследнику. Список всех классов можно найти тут.

Microdata DOM API

Это API упрощает работу с узлами микроданных, на данный момент имеет метод document.getItems([]) . При вызове без параметра вернёт все элементы которые являются не вложенными узлами микроданных, можно получить узлы определённого типа указав его в качестве параметра. domElement.properties вернёт объект типа PropertyNodeList а domElement.itemValue позволит получить или изменить значение элемента имеющего атрибут itemprop. Но, к сожалению, Microdata DOM API поддерживается только в Opera, ещё и устаревшую версию.
UPD: termi рассказал о JS библиотеке реализующей Microdata DOM API. Однако, она требует отдельную библиотеку реализующей DOMSettableTokenList, например эту.

Нужно ли это?

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

Спасибо, и надеюсь что эта статья была вам полезна!

Это нормально использовать `itemscope =«ложь»ItemType =«ложь»` для обозначения страницы без структурированных данных?

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

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

Я не нашел изящный способ только вставить itemscope атрибут в моем HTML документа ситуационно.

редактировать — @martinhepp предлагает передавая строку атрибутов Джейд и вставить его внутри тега. Я хотел бы сделать это , но я не знаю , как. Вот моя попытка и выход.

Так что было бы предпочтительнее. Но если это не работает, или никто не знает, как это сделать, на страницах, где я не хочу, чтобы назначить конкретную схему, достаточно ли установить itemscope ложь?

Вот что я делаю сейчас.

Будет ли это запутать поисковые системы или они признают , что я отключив itemscope и itemtype атрибуты моего элемента здесь?

Я работаю на Яндексе (yandex.ru/.com — самый популярный русский Search Engine) и могу сказать, как мы имеем дело с ним. Могу поспорить, хотя этот процесс довольно одинаковый для всех SE.

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

Элемент с атрибутом itemscope указанного создает новый элемент, группу пар имя-значение.

То есть , если вы поставите itemscope атрибут в HTML — элемента, оно рассматривается в качестве элемента. Даже в вашем случае (на самом деле «= ложь» игнорируется). Если вы не хотите , чтобы определить новый элемент , который вы просто не должны использовать itemscope атрибут вообще.

2.Every Search Engine , который использует разметку имеет собственный инструмент валидатор — инструмент, где вы можете проверить обработку разметки специально для этого SE. Для Яндекса это здесь , для Google является здесь . Bing имеет один тоже , но это требует подписи В в своих веб — мастеров первой. Используйте его для каждого вопроса , который вы должны об обработке разметки для partucular SE и вы получите довольно подробный ответ.

Таким образом, вы не предоставили пример разметки, но давайте рассмотрим этот простой.

Так валидатор Яндекса говорит следующее:

Как вы видите, itemscope = «ложь» был проигнорирован и тип элемента был установлен в положение «ложно» (из-за ItemType = «ложь»). То есть Яндекс нашел объект, но не знает, что делать с ним (подробнее об этом в третьей точке).

Как насчет Google?

Почти то же самое, за исключением того, что лечение лица, как и без вида на всех.

Микроразметка Schema.org

Schema.org — это стандарт семантической разметки данных в интернете, который используют большинство поисковых систем.

Schema представляет собой HTML теги. Они необходимы для структурирования данных в интернете, а также, чтобы упростить процедуру обработки информации поисковыми системами.

Например, как поисковая система сможет отличить телефон от факса? Или как отличить кулинарный рецепт от статьи на тему приготовления пищи?

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

Schema имеет более 100 разновидностей микроразметки, с её помощью можно выделить такие объекты как:

  • Медиа
  • Фотографии
  • Люди
  • Организации
  • Комментарии
  • Продукты и услуги

Это лишь меньшая их часть, полный список можно посмотреть здесь — http://schema.org/docs/schemas.html.

Как сделать микроразметку на сайте

Для внедрения микроразметки нужно найти участок кода, в котором осуществляется вывод контента.

Для понимания рассмотрим пример разметки контактной информации для организации.

Микроразметка контактов

Изначально контактная информация представлена в таком виде:

После разметки с помощью schema.org исходный код будет выглядеть так:

Разберем пример подробнее.

С помощью атрибутов itemscope, itemtype и itemprop мы указали: название организации, индекс, город, улицу и дом, телефон, факс, электронную почту.

Атрибут itemscope написанный в теге

Вместо Organization мы могли выбрать любой другой тип (например: товар, статью, рецепт).

Атрибут itemprop указывается в теге и имеет свои значения, при разметке контактной информации это:

  • «name» — атрибут, в котором указывается название организации
  • «postalCode» — индекс
  • «addressLocality» — город
  • «streetAddress» — адрес
  • «telephone» — номер телефона
  • «faxNumber» — факс
  • «email» — электронная почта

Микроразметка Schema.org для статьи

Для начала рассмотрим исходный HTML код:

Микроразметка для статьи

Подзаголовок

Всю статью необходимо поместить в контейнер:

Здесь вся статья

Внутрь этого контейнера добавляем заголовок:

Микроразметка для статьи

Указываем время публикации:

Для разметки изображения статьи используем:

Далее указываем подзаголовок статьи:

Подзаголовок

Краткое описание статьи:

В итоге мы получаем размеченную с помощью schema.org статью:

Микроразметка для статьи

Подзаголовок

Основные атрибуты, которые используются при разметке статьи:

  • headline — название статьи;
  • datePublished — дата публикации документа;
  • image — изображение;
  • articleBody — тело статьи;
  • author — автор;
  • publisher — название сайта, который публикует статью.

Также желательно указывать дополнительные параметры:

  • dateModified — дата изменения статьи;
  • mainEntityOfPage – ссылка на статью.

В publisher можно использовать такие параметры:

  • logo — логотип;
  • name — название организации;
  • telephone – номер телефона;
  • address — адрес.

Микроразметка для коммерческого сайта

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

Микроразметка для услуг и товаров

Product — один из типов Schema, он применяется для разметки продуктов, которые можно продать/купить. Также этот тип включает услуги. Например, продажа билетов, аренда и т.п..

На первом этапе разметки необходимо поместить продукт в контейнер:

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

Цена Описание товара

Внутри главного блока могут находиться вложенные, которые соответствуют определенной сущности. Например, http://schema.org/Offer или предложение товара, в котором будет указана цена, валюта или продавец.

Микроразметка карточки товара

Рассмотрим на примере конкретного товара:

Футболка с топорами

Микроразметка категории товаров

  • offerCount – общее количество продуктов в разделе;
  • lowPrice – самая низкая стоимость в разделе;
  • highPrice – самая высокая цена в разделе;

Микроразметка хлебных крошек

Словарь schema.org можно использовать для разметки хлебных крошек.

Возьмем такую последовательность:

Главная – Каталог – Мужские футболки

На сайте futbolka.ru код хлебных крошек будет представлен в таком виде:

С применением правил Schema.org получим:

В первой строке указывается, что мы используем Schema.org. Здесь:

  • Itemscope – атрибут, указывающий, что в блоке задается элемент;
  • Itemtype – это тип элемента, в данном случае навигационный;
  • BreadcrumbList – это разделы в хлебных крошках.
  • Параметр itemprop со значением “itemListElement” обозначает пункт списка элементов.

Микроразметка отзывов

Review используется для разметки отзывов и комментариев. Нужно указать какой тип микроразметки мы будем использовать:

В блоке Review можно указать такие параметры:

  • name — заголовок;
  • author — автор;
  • datePublished — дата публикации;
  • reviewBody — текст комментария;
  • reviewRating – оценка.

Пример микроразметки

Посмотрим, как выглядит отзыв на примере:

Здесь внутри применен блок Rating со следующими видами оценок:

  • worstRating – минимальная оценка;
  • ratingValue – оценка, которую поставил автор;
  • bestRating – максимальная оценка.

Как проверить микроразметку на сайте

В этом разделе рассмотрим сервисы для проверки правильности размещения микроразметки Schema.org.

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

Рассмотрим 2 онлайн сервиса от Яндекс и Google:

Structured Data Testing Tool — проверка микроразметки в Google

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

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

Ниже представлен пример того, как инструмент указывает на ошибки в разметке:

Валидатор микроразметки в Яндекс

Как и в прошлом сервисе здесь есть 2 варианта: проверить всю страницу или фрагмент исходного кода.
После Проверки парсер выдает результаты:

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

Инструменты для разметки данных

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

Генераторы микроразметки Schema.org

Микроразметка Schema.org для WordPress

Если вы используете WordPress, то для разметки контента можно использовать плагины:

Это одни из популярных плагинов для WordPress. Они просты в установке и использовании. С ними Вам не нужно копаться в коде и изучать программирование для внедрения разметки в шаблон сайта.

Микроразметка Schema.org для Bitrix (Битрикс)

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

Один из бесплатных плагинов – Микроразметка Schema.org. В настоящий момент плагин содержит большинство необходимых типов разметки. Здесь представлена вся документация, детальная инструкция по установке и внедрению Schema.org на сайт.

Микроразметка Schema.org для Joomla

В этой CMS разметить данные можно двумя способами:

  1. Вручную внедрять разметку в html код;
  2. Использовать Маркер Гугла.

Ручная разметка

Для разметки вручную, необходимо знать html и уметь работать с шаблонами Joomla. Кроме этого нужно изучить документацию Schema.org. У новичков этот метод может вызвать затруднения.

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

Разметка через Маркер Гугла

Этот вариант значительно проще. Нужно просто указать url страницы и мышкой внедрить разметку в необходимые элементы.

У этого способа есть значительный недостаток, эти данные передаются только в Google.

Вот краткое пособие по работе с этим инструментом:

  1. Зайти в сервис и выбрать свой сайт.
  2. Указать URL документа, который будем размечать и выбрать тип микроразметки.
  3. Разметка осуществляется путем выделения мышкой элемента: наименование, картинка, стоимость и т.д.
  4. Посмотреть подобные документы, которые предложит Google.
  5. Опубликовать данные в Google и дождаться индексации.

Заключение

Нужно использовать Schema.org на своем сайте, постарайтесь изучить микроразметку и внедрить её. Использовать её нужно как на коммерческих, так и на информационных сайтах. Для некоторых CMS разработаны плагины, с помощью которых можно быстро разметить сайт используя Schema.org. Желательно, если позволяет CMS, внедрять разметку в шаблон, таким образом не придется размечать каждый документ одного типа.

Очень важно, чтобы в разметке не было ошибок, поэтому не забывайте проверять её через специальные инструменты.

HTML Microdata

W3C Working Draft 26 April 2020

Abstract

This [ html-extensions ] specification defines new HTML attributes to embed simple machine-readable data in HTML documents. It is similar to, but generally less expressive than RDFa, and does not support the same level of internationalization. It is simple to learn and process, but authors who need good internationalization support, or want to include structured content in their data should consider using RDFa. (or another format such as JSON-LD) instead.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document is an editor’s draft for the Web Platform Working Group, proposed as an update to the 10 October 2020 W3C Working Draft. The editors believe the specification is complete and ready to become a Candidate Recommendation. Review is particularly sought on the algorithm for conversion to RDFa.

If you wish to make comments regarding this document please submit them as github issues. All feedback is welcome, but please note the contribution guidelines require agreement to the terms of the W3C Patent Policy for substantive contributions.

This document was published by the Web Platform Working Group as a Working Draft. This document is intended to become a W3C Recommendation.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

1. Dependencies

This specification is an extension to HTML. All normative content in the HTML specification not specifically overridden by this specification is intended to be normative for this specification. This specification depends on the HTML specification and its extensions for definitions of individual HTML elements and attributes. [ HTML52 ][ html-extensions ]

2. Terminology

For the purposes of this specification, the terms «URL» and «URI» are equivalent. The URL specification, and RFC 3986 which uses the term URI, define a , , and . [ RFC3986 ][ URL ]

RFC 3986 defines the term [ RFC3986 ].

DOM 4.1 defines for attributes, and for elements or nodes, as well as the term . [ DOM41 ]

This specification relies on the HTML specification to define the following terms: [ HTML52 ]

3. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words «must», «must not», «should», «should not», and «may» in the normative parts of this document are to be interpreted as described in RFC2119. [ RFC2119 ]

Requirements phrased in the imperative as part of algorithms (such as «strip any leading space characters» or «return false and abort these steps») are to be interpreted with the meaning of the key word («must», «should», «may», etc) used in introducing the algorithm.

For example, were the spec to say:

. it would be equivalent to the following:

Here the key word is «must».

The former (imperative) style is generally preferred in this specification for stylistic reasons.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

4. Introduction

4.1 Overview

This section is non-normative.

Sometimes, it is desirable to annotate content with specific machine-readable labels. For example, search engines can better identify page content using schema.org annotations, and content management systems can find and use information from documents, if it is marked up in a known way.

Microdata provides a simple mechanism to label content in a document, so it can be processed as a set of items described by name-value pairs.

Each name-value pair identifies a property of the item, and a value of that property.

Figure 1 A common way to represent items, properties and values graphically An Item

The value of a property may be an item.

4.2 The basic syntax

This section is non-normative.

Items and properties are generally represented by regular elements.

The itemscope attribute creates an item.

The itemprop attribute on a descendent element of an item identifies a property of that item. Typically, the text content of that element is the value of that property.

Here there are two items, each of which has the property «name»:

Figure 2 The example represented graphically: two items, each with a value for the property name .

Markup other than Microdata attributes has no effect on Microdata.

These two examples are exactly equivalent, at a Microdata level, as the previous two examples respectively:

Note that this means any information recorded in markup for purposes such as internationalization or accessibility will be lost in the conversion to data. Authors who wish to preserve markup in machine-readable formats should consider using RDFa’s ability to use the XMLLiteral datatype.

Properties generally have values that are strings.

Here the item has three properties:

If the text that would normally be the value of a property, such as the element content, is unsuitable for recording the property value, it can be expressed using the content attribute of the element.

Here, the visible content may be added by a script. A Microdata processor can extract the content from the content attribute without running scripts. The value of the product-id property for this item is 9678AOU879

When a string value is in some machine-readable format unsuitable to present as the content of an element, it can be expressed using the value attribute of the data element, as long as there is no content attribute.

Here, there is an item with a property whose value is a product identifier. The identifier is not human-friendly, so instead it is encoded for Microdata using the value attribute of the data element, and the product’s name is used as the text content of the element that is rendered on the page.

Figure 3 The example represented graphically as microdata: an items, whose property product-id has the value 9678AOU879

This will not work if there is a content attribute as well. In the following example, the value of the product-id property is taken from the content attribute, so it will be This one rocks! :

When an itemprop is used on an element that can have a src or href attribute, such as links and media elements, that does not have a content attribute, the value of the name-value pair is an absolute URL based on the src or href attribute (or the empty string if they are missing or there is an error).

In this example, the item has one property, logo , whose value is a URL based on the location of the page, and ending with our-logo.png :

Note that accessibility information, such as the alt attribute in the previous example, is ignored. To provide that as a value, repeat it in a content attribute. In the following example, the value of the name property is The Company :

For numeric data, the meter element and its value attribute can be used instead, as long as there is no content attribute.

Here a rating of 3.5 is given using a meter element.

Similarly, for date- and time-related data, the time element and its datetime attribute can be used to specify a specifically formatted date or time, as long as there is no content attribute.

In this example, the item has one property, «birthday», whose value is a date:

Properties can also themselves be groups of name-value pairs, by putting the itemscope attribute on the element that declares the property.

Items that are not part of others are called top-level Microdata items.

In this example, the outer item represents a person, and the inner one represents a band:

The outer item here has two properties, «name» and «band». The «name» is «Amanda», and the «band» is an item in its own right, with two properties, «name» and «size». The «name» of the band is «Jazz Band», and the «size» is «12».

The outer item in this example is a top-level Microdata item.

Properties that are not descendants of the element with the itemscope attribute can be associated with the item using the itemref attribute. This attribute takes a list of IDs of elements to crawl in addition to crawling the children of the element with the itemscope attribute.

This example is the same as the previous one, but all the properties are separated from their items:

This gives the same result as the previous example. The first item has two properties, «name», set to «Amanda», and «band», set to another item. That second item has two further properties, «name», set to «Jazz Band», and «size», set to «12».

An item can have multiple properties with the same name and different values.

This example describes an ice cream, with two flavors:

This thus results in an item with two properties, both «flavor», having the values «Lemon sorbet» and «Apricot sorbet».

An element introducing a property can also introduce multiple properties at once, to avoid duplication when some of the properties have the same value.

Here we see an item with two properties, «favorite-color» and «favorite-fruit», both set to the value «orange»:

It’s important to note that there is no relationship between the Microdata and the content of the document where the Microdata is marked up.

The following two examples are exactly the same Microdata, because they produce exactly the same information when processed:

Both have a figure with a caption, and both, completely unrelated to the figure, have an item with a name-value pair with the name «name» and the value «The Castle». In neither case is the image in any way associated with the item.

4.3 Typed items

This section is non-normative.

The examples in the previous section show how information could be marked up on a page that doesn’t expect its Microdata to be re-used. Microdata is most useful, though, when it is used in contexts where other authors and readers are able to cooperate to make new uses of the markup.

For this purpose, it is necessary to give each item a type, such as «http://example.com/person», or «http://example.org/cat», or «http://band.example.net/». Types are identified as URLs.

The type for an item is given as the value of an itemtype attribute on the same element as the itemscope attribute. The value is a URL, which determines the vocabulary identifier for properties

Assuming a page at http://example.net/some/dataexample contains the following code:

The item’s type is «http://example.org/animals#cat»

In this example the «http://example.org/animals#cat» item has three properties:

http://example.org/animals#name «Hedral» http://example.org/animals#desc Hedral is a male american domestic shorthair, with a fluffy black fur with white paws and belly. http://example.org/animals#img hedral.jpeg

The type gives the context for the properties, thus selecting a vocabulary: a property named «class» given for an item with the type «http://census.example/person» might refer to the economic class of an individual, while a property named «class» given for an item with the type «http://example.com/school/teacher» might refer to the classroom a teacher has been assigned. A vocabulary may define several types. For example, the types » http://example.org/people/teacher » and » http://example.org/people/engineer » could be defined in the same vocabulary. Some properties might not be especially useful in both cases: the » classroom » property might not be meaningful with the » http://example.org/people/engineer » type. Multiple types from the same vocabulary can be given for a single item by listing the URLs, separated by spaces, in the attribute’s value. An item cannot be given two types if they do not use the same vocabulary, however.

4.4 Global identifiers for items

This section is non-normative.

Sometimes, an item gives information about a topic that has a global identifier. For example, books can be identified by their ISBN number, or concepts can be identified by a URL as in [ rdf-primer ].

The itemid attribute associates an item with a global identifier in the form of a URL.

Here, an item is talking about a particular book:

4.5 Selecting names when defining vocabularies

This section is non-normative.

Using Microdata means using a vocabulary. For some purposes an ad-hoc vocabulary is adequate, but authors are encouraged to re-use existing vocabularies to make content re-use easier.

When designing new vocabularies, identifiers can be created either using URLs, or, for properties, as plain words (with no dots or colons). For URLs, conflicts with other vocabularies can be avoided by only using identifiers that correspond to pages that the author has control over.

For instance, if Jon and Adam both write content at example.com , at http://example.com/

jon/. and http://example.com/

adam/. respectively, then they could select identifiers of the form «http://example.com/

jon/name» and «http://example.com/

Properties whose names are just plain words can only be used within the context of the types for which they are intended; properties named using URLs can be reused in items of any type. If an item has no type, and is not part of another item, then if its properties have names that are just plain words, they are not intended to be globally unique, and are instead only intended for limited use. Generally speaking, authors are encouraged to use either properties with globally unique names (URLs) or ensure that their items are typed.

Here, an item in the page http://example.net/some/dataexample is an «http://myvocab.example.org/animals/cat», and most of the properties have names defined in the context of that type. There are also a few additional properties whose names come from other vocabularies.

This example has one item with the type «http://myvocab.example.org/animals/cat» and the following properties:

http://myvocab.example.org/animals/name Hedral http://example.com/fn Hedral http://myvocab.example.org/animals/desc Hedral is a male american domestic shorthair, with a fluffy black fur with white paws and belly. http://example.com/color black http://example.com/color white http://myvocab.example.org/animals/img http://example.net/some/hedral.jpeg

5. Encoding Microdata

5.1 The Microdata model

The Microdata model consists of groups of name-value pairs known as items.

Each group is known as an item. Each item can have zero or more item types, global identifier(s), and associated name-value pairs. Each name in the name-value pair is known as a property, and each property has one or more values. Each value is either a string or itself a group of name-value pairs (an item). Properties and their values are unordered, and authors must not rely on a particular ordering being preserved.

5.2 Items: itemscope , itemtype , and itemid

Every HTML element may have an attribute specified. The itemscope attribute is a boolean attribute.

An element with the itemscope attribute specified creates a new , a group of name-value pairs that describe properties, and their values, of the thing represented by that element.

Elements with an itemscope attribute may have an attribute specified, to give the item types of the item.

The itemtype attribute, if specified, must have a value that is an unordered set of unique space-separated tokens that are case-sensitive , each of which is a valid absolute URL, and all of which are in the same vocabulary. The attribute’s value must have at least one token.

The of an item are the tokens obtained by splitting the element’s itemtype attribute’s value on spaces. If the itemtype attribute is missing or parsing it in this way finds no tokens, the item is said to have no item types.

The item types determine the . This is a URL that is prepended to property names, which identifies them as part of their vocabulary. The value of the vocabulary identifier for an item is determined as follows:

  • Let potential values be an empty array of URLs.
  • Let tokens be the value of the itemtype attribute, split on spaces.
  • For each value of tokens : If there is a NUMBER SIGN U+0023 («#») in the value Append the substring of the value from the beginning to the first NUMBER SIGN U+0023 («#») to potential values Otherwise, if there is a SOLIDUS U+002F («/») in the value Append the substring of the value from the beginning to the last SOLIDUS U+002F («/») to potential values Otherwise Append a SOLIDUS U+002F («/») to the value, and append the resulting string to potential values
  • If there is only one unique value in potential values return that value. Otherwise return the first item in potential values .

User agents must not automatically dereference unknown URLs given as item types and property names. These URLs are a priori opaque identifiers.

A specification could define that its item types can be derefenced to provide the user with help information. Vocabulary authors are encouraged to provide useful information at the given URL, either in prose or a formal language such as RDF.

The itemtype attribute must not be specified on elements that do not have an itemscope attribute specified.

An item is said to be a when either it has an item type, or it is the value of a property of a typed item. The for a typed item is the item’s item types, if it has any, or else is the relevant types of the item for which it is a property’s value.

Elements with an itemscope attribute may also have an attribute specified, to give a global identifier for the item, so that it can be related to other items elsewhere on the Web, or with concepts beyond the Web such as ISBN numbers for published books.

The itemid attribute, if specified, must have a value that is a valid URL potentially surrounded by space characters.

The of an item is the value of its element’s itemid attribute, if it has one, resolved relative to the element on which the attribute is specified. If the itemid attribute is missing or if resolving it fails, it is said to have no global identifier.

The itemid attribute must not be specified on elements that do not have an itemscope attribute.

This example shows Microdata used to describe model railway products. manufacturer. The vocabulary identifier is https://md.example.com/ . The example uses five property names:

product-code A number that identifies the product in the manufacturer’s catalog. name A brief description of the product. scale One of «HO», «1», or «Z» (potentially with leading or trailing whitespace), indicating the scale of the product. digital If present, one of «Digital», «Delta», or «Systems» (potentially with leading or trailing whitespace) indicating that the product has a digital decoder of the given type. track-type For track-specific products, one of «K», «M», «C» (potentially with leading or trailing whitespace) indicating the type of track for which the product is intended.

It identifies four item types:

https://md.example.com/loco Rolling stock with an engine https://md.example.com/passengers Passenger rolling stock https://md.example.com/track Track pieces https://md.example.com/lighting Equipment with lighting

Each item that uses this vocabulary can be given one or more of these types, depending on what the product is.

Thus, a locomotive might be marked up as:

A turnout lantern retrofit kit might be marked up as:

A passenger car with no lighting might be marked up as:

5.3 Properties: the and itemref attributes

The itemprop attribute, when added to any HTML element that is part of an item, identifies a of that item. The attribute must be an unordered set of unique space-separated tokens, representing the case-sensitive names of the properties that it adds. The attribute must contain at least one token.

Each token must be either a valid absolute URL or a a string that contains no «.» (U+002E) characters and no «:» (U+003A) characters.

Vocabulary specifications must not define property names for Microdata that contain «.» (U+002E) characters, «:» (U+003A) characters, nor space characters (defined in [ HTML52 ] as U+0020, U+0009, U+000A, U+000C, and U+000D).

The of an element are determined as follows:

  • Let tokens be the values of the itemprop attribute, Split on spaces.
  • Let properties be an empty array of strings.
  • For each value of token , in order: If the value is a repeated occurrence of an earlier value discard it and process the next value If the value is an absolute URL append it to properties , then process the next value Otherwise, if the the element is a typed item: Append the value to the vocabulary identifier for the item. If the the resulting value does not match any value in properties , then append it to properties , and process the next value. Otherwise append the value to properties and process the next value.
  • If properties is not empty, return properties .

Within an item, the properties are unordered with respect to each other and authors must not rely on order in markup being preserved.

In the following example, the orer of the «a» and «b» properties is not important, as it is not guaranteed to be preserved in the resulting microdata:

Is equivalent to:

Elements with an itemscope attribute may have an attribute specified, to give a list of additional elements to crawl to find the name-value pairs of the item.

The itemref attribute, if specified, must have a value that is an unordered set of unique space-separated tokens that are case-sensitive , consisting of IDs of elements in the same document.

The itemref attribute must not be specified on elements that do not have an itemscope attribute specified.

The preceding example:

Could also be written as follows:

When an element with an itemprop attribute adds a property to multiple items, the requirement above regarding the tokens applies for each item individually.

For the following code:

The author should be certain that z is a valid property name for both the http://example.com/a and http://example.com/b vocabularies.

5.4 : the attribute, element-specific attributes and element content

The for a name-value pair is given by applying the first matching case in the following list:

If the element also has an itemscope attribute

The value is the item created by the element.

If the element has a content attribute

The value is the textContent of the element’s content attribute.

HTML only allows the content attribute on the meta element. This specification changes the content model to allow it on any element, as a global attribute.

If the element has a src attribute, let proposed value be the result of resolving that attribute’s textContent . If proposed value is a valid absolute URL: The value is proposed value .
otherwise The value is the empty string.

If the element is an a , area , or link element

If the element has an href attribute, let proposed value be the result of resolving that attribute’s textContent . If proposed value is a valid absolute URL: The value is proposed value .
otherwise The value is the empty string.

If the element is an object element

If the element has a data attribute, let proposed value be the result of resolving that attribute’s textContent . If proposed value is a valid absolute URL: The value is proposed value .
otherwise The value is the empty string.

If the element is a data or meter element

If the element has a value attribute, the value is that attribute’s textContent .

If the element is a time element

If the element has a datetime attribute, the value is that attribute’s textContent .

The value is the element’s textContent .

The are the a , area , audio , embed , iframe , img , link , object , source , track , and video elements.

If a property’s value, as defined by the property’s definition, is an absolute URL, the property must be specified using a URL property element.

These requirements do not apply just because a property value happens to match the syntax for a URL. They only apply if the property is explicitly defined as taking such a value.

For example, a book about the first moon landing, on the 20th of July 1967 could be called «mission:moon». A «title» property from a vocabulary that defines a title as a string would not expect the title to be given in an a element, even though it is a valid URL. On the other hand, if there was a vocabulary for «books whose titles look like URLs», whose «title» property whose content was defined as a URL, the property would expect the title to be given in an a element (or one of the other URL property elements), because of the requirement above.

5.5 Associating names with items

To find defined by the element root , the user agent must run the following steps. These steps are also used to flag Microdata Errors.

Let results , memory , and pending be empty lists of elements.

Add the element root to memory .

Add the child elements of root , if any, to pending .

If root has an itemref attribute, split the value of that itemref attribute on spaces. For each resulting token ID , if there is an element in the document whose ID is ID , then add the first such element to pending .

Loop: If pending is empty, jump to the step labeled end of loop.

Remove an element from pending and let current be that element.

If current is already in memory , there is a Microdata Error; return to the step labeled loop.

Add current to memory .

If current does not have an itemscope attribute, then: add all the child elements of current to pending .

If current has an itemprop attribute specified and has one or more property names, then add current to results .

Return to the step labeled loop.

End of loop: Sort results in tree order.

A document must not contain any items for which the to find the properties of an item finds any .

An item is a if its element does not have an itemprop attribute.

All itemref attributes in a Document must be such that there are no cycles in the graph formed from representing each item in the Document as a node in the graph and each property of an item whose value is another item as an edge in the graph connecting those two items.

A document must not contain an itemprop attribute that would not be a property of any item in that document were the properties all to be determined.

In this example, a single license statement is applied to two works, using itemref from the items representing the works:

The above results in two items with the type » http://n.whatwg.org/work «, one with:

work images/house.jpeg title The house I found. license http://www.opensource.org/licenses/mit-license.php

work images/mailbox.jpeg title The mailbox. license http://www.opensource.org/licenses/mit-license.php

6. Converting Microdata to other formats

6.1 JSON

The section presents an obsolete but conforming feature.

Microdata information can readily be expressed in a JSON form, including the JSON-LD format for RDF. This specification does not seek to limit such conversions, but other than defining a minimal conversion to RDFa which can be used to generate JSON-LD since they are both formally syntaces to express RDF, defines a «reference format». No current implemetation use of this format is known, but it is presented here for historical information.

Given a list of nodes nodes in a Document , a user agent must run the following expressed as application/microdata+json :

Let result be an empty object.

Let items be an empty array.

For each node in nodes , check if the element is a top-level Microdata item, and if it is then get the object for that element and add it to items .

Add an entry to result called » items » whose value is the array items .

Return the result of serializing result to JSON in the shortest possible way (meaning no whitespace between tokens, no unnecessary zero digits in numbers, and only using Unicode escapes in strings for characters that do not have a dedicated escape sequence), and with a lowercase » e » used, when appropriate, in the representation of any numbers. [ JSON ]

This algorithm returns an object with a single property that is an array, instead of just returning an array, so that it is possible to extend the algorithm in the future if necessary.

When the user agent is to for an item item , potentially together with a list of elements memory , it must run the following substeps:

Let result be an empty object.

If no memory was passed to the algorithm, let memory be an empty list.

Add item to memory .

If the item has any item types, add an entry to result called » type » whose value is an array listing the item types of item , in the order they were specified on the itemtype attribute.

If the item has a global identifier, add an entry to result called » id » whose value is the global identifier of item .

Let properties be an empty object.

For each element element that has one or more property names and is one of the properties of the item item , in the order those elements are given by the algorithm that returns the properties of an item, run the following substeps:

Let value be the property value of element .

If value is an item, then: If value is in memory , then let value be the string » ERROR «. Otherwise, get the object for value , passing a copy of memory , and then replace value with the object returned from those steps.

For each name name in element ‘s property names, run the following substeps:

If there is no entry named name in properties , then add an entry named name to properties whose value is an empty array.

Append value to the entry named name in properties .

Add an entry to result called » properties » whose value is the object properties .

For example, take this markup:

It would be turned into the following JSON by the algorithm above (supposing that the page’s URL was http://blog.example.com/progress-report ):

6.2 RDFa

Almost all typed items can be easily converted to RDFa. This is useful for example to support better internationalization, or to include markup in the resulting data, beyond the capabilities of microdata. This specification defines a minimal conversion to the RDFa-Lite dialect of RDFa. which uses a subset of the RDFa functionality. A richer conversion that leverages synergies from using microdata in HTML is described in Microdata to RDF. [ microdata-rdf ]

To the result must include the triples produced by applying the following algorithm:

  1. For each element having an itemscope attribute:
    1. Replace the itemscope attribute with a vocab attribute, whose value is the vocabulary identifier for the item.
    2. Replace any itemtype attribute with a typeof attribute, whose value is taken from the values of itemtype where each type is made relative to the vocabulary identifier, ensuring that the element has a typeof attribute with at least an empty value.
    3. Replace any itemid attribute with a resource attribute having the same value.
    4. Otherwise, ensure that element has a typeof attribute with at least an empty value.
  2. For each object element having both an itemprop and a data attribute, change the data attribute to a resource attribute with the same value
  3. Change each itemprop attribute to a property attribute with the same value
  4. For each element having an itemref attribute:
    1. Set item vocab to the first value of the vocab attribute taken from the element and its ansestors.
    2. For each value reference that is a result of splitting the value on spaces follow the following substeps:
      1. Add an element as the immediate parent of the element with id reference , with a vocab attribute whose value is item vocab , and a typeof attribute with rel=»rdfa:Pattern» attribute.

        The choice of element is left to the author, to provide sufficient flexibility to avoid unwanted changes in the rendering of the content.

        And then remove the itemref attribute.

        There is significant scope for optimising this algorithm, which may result in redundant vocab declarations in particular.

        The example data for a model locomotive given above would be converted to the folling RDFa:

        An example using itemref shows scope for optimisation:

        It could be rewritten as:

        7. Changes to HTML

        7.1 New attributes

        This specification adds the following global attributes and associated validity constraints to HTML:

        itemscope This is a boolean attribute. When present on an element, it identifies that element as the container for an item itemtype This is a list of absolute URLs that identify an item within a particular vocabulary. The itemtype attribute must not be specified on elements that do not have an itemscope attribute.

        This attribute performs a function similar to the combination of vocab and typeof attributes in [ rdfa-core ].

        itemprop When present on an element, it identifies that the element provides the property value of the item in which it appears, and the attribute’s value defines the property name.

        This attribute is equivalent to the property attribute in [ rdfa-core ].

        itemid This is an absolute URL that provides a global identifier for an item. The itemid attribute must not be specified on elements that do not have an itemscope attribute specified.

        This is approximately equivalent to declaring that an item is owl:sameAs the value of the attribute. [ owl-ref ]

        itemref This is a space seperated list of IDs of elements which are not descendants of the element on which it appears. It identifies each element whose ID it includes as defining a property of the item on which it is present. The itemref attribute must not be specified on elements that do not have an itemscope attribute.

        7.2 Content models

        This section changes the content models defined by HTML in the following ways:

        The content attribute redefined by this specification as a global attribute that may be present on that element.

        This is consistent with [ HTML-RDFA ], which uses the attribute for the same purpose.

        If the itemprop attribute is present on a link or meta element, that element is flow content and phrasing content, and may be used where phrasing content is expected.

        If a link element has an itemprop attribute, the rel attribute may be omitted.

        If a meta element has an itemprop attribute, the name , http-equiv , and charset attributes must be omitted, and the content attribute must be present.

        If the itemprop attribute is specified on an a or area element, then the href attribute must also be specified.

        If the itemprop attribute is specified on an audio , embed , iframe , img , source , track , or video element, then the src attribute must also be specified.

        If the itemprop attribute is specified on an object element, then the data attribute must also be specified.

        8. Microdata and RDF

        This section is not normative

        Microdata has limited expressivity. There are only two types of data — text strings, and URLs, and microdata does not have a mechanism to describe further datatypes such as numbers or fragments of markup in an interoperable way, or include information such as language, unlike RDF formats including RDFa. To support retaining markup structure, internationalization information, or for more expressivity, authors should consider using [ JSON-LD ] or [ rdfa-core ] instead of, or as well as, microdata.

        Information expressed as Microdata can be converted to RDFa as described in Section 6. [ rdfa-core ], A richer process to convert Microdata to RDF, that extends the minimal one required by this specification, is described in Microdata to RDF. [ microdata-rdf ]

        9. Accessibility and Microdata

        This section is not normative

        Microdata can be used to provide machine-parseable information about content that is processed by tools to improve accessibility.

        When editing content that contains Microdata, authors should consider the possibility that this is the case. Authoring and content management tools should implement the Authoring Tool Accessibility Guidelines, and in this context note Guideline B1.1.2 — Ensure Accessibility Information is Preserved, if applicable drawing attention to the fact that changes in content may mean the encoded metadata is not accurate. [ ATAG20 ]

        Authors should be aware that a great deal of accessibility information is ignored in extracting Microdata, including attributes such as alt and ARIA information. Authors should consider whether to encode accessibility information explicitly, or to use a more expressive approach such as RDFa. [ rdfa-core ]

        10. Internationalisation and localisation

        This section is not normative

        Microdata does not preserve internationalization-related information in the source document, except if it is specifically encoded as Microdata. In that case it is important to pay attention when editing the source document, as with accessibility, to avoid introducing errors that are only reflected in the microdata. This approach also has the disadvantage that the representation of such information is not based on an established standard, so it may not be understood by downstream processors and users of the information.

        Machine-readable data may be presented to users, for example by search engines. Internationalization information is often important for this use case. Authors may prefer to convert their data to RDFa to take advantage of its better support for Internationalization.

        Vocabulary design is difficult. Different languages and cultures present view ambiguity differently: two terms with different meanings in one situation may be most naturally translated by a single term that has both meanings, or a single term may have two natural translations. When developing for localisation, it is important to provide sufficient contextual information about terms in a vocabulary to enable accurate translation.

        11. Privacy Considerations

        This section is not normative

        Microdata does not introduce new mechanisms to transmit privacy-sensitive information. However it more clearly identifies information, in a way that facilitates finding data and merging it with data from other sources.

        Authors and processors should take care to ensure that their use of Microdata is in line with privacy policies and any applicable regulation.

        12. Security Considerations

        This section is not normative

        Microdata does not generally interact with browsers, being a static document format that lacks any DOM interface.

        Microdata makes information machine-readable, but does not automatically include provenance information for the statements it encodes.

        Processors of Microdata should consider the trustworthiness of sources they use, including the possibility that data is no longer accurate, and the possibility that data gathered over an insecure connection has been altered by a «man-in-the-middle» attack.

        13. IANA considerations

        This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

        Type name: application Subtype name: microdata+json Required parameters: Same as for application/json [ JSON ] Optional parameters: Same as for application/json [ JSON ] Encoding considerations: 8bit (always UTF-8) Security considerations: Same as for application/json [ JSON ] Interoperability considerations: Same as for application/json [ JSON ] Published specification: Labeling a resource with the application/microdata+json type asserts that the resource is a JSON text that consists of an object with a single entry called » items » consisting of an array of entries, each of which consists of an object with an entry called » id » whose value is a string, an entry called » type » whose value is another string, and an entry called » properties » whose value is an object whose entries each have a value consisting of an array of either objects or strings, the objects being of the same form as the objects in the aforementioned » items » entry. Thus, the relevant specifications are the JSON specification and this specification. [ JSON ] Applications that use this media type:

        Applications that transfer data intended for use with Microdata, especially in the context of drag-and-drop, are the primary application class for this type.

        Additional information: Magic number(s): Same as for application/json [ JSON ] File extension(s): Same as for application/json [ JSON ] Macintosh file type code(s): Same as for application/json [ JSON ] For further information: https://github.com/w3c/microdata/ Intended usage: Common Restrictions on usage: No restrictions apply. Author: W3C Change controller: W3C

        Fragment identifiers used with application/microdata+json resources have the same semantics as when used with application/json (namely, at the time of writing, no semantics at all). [ JSON ]

        14. Changes

        An exact history of changes to the text is available in the Github commit log. The following information is provided as an overview of the substantive changes made to the specification between each publication.

        Changes made between the current draft and the third Working Draft:

        • Specify that properties and their values are unordered.
        • Remove the Microdata to JSON-LD conversion.
        • Mark Microdata to JSON conversion as an obsolete but conforming feature.
        • Add a section describing how to convert microdata to RDFa.
        • Add a section describing how to convert microdata to JSON-LD (now removed).
        • itemid may be specified on an element with an itemscope attribute, not just a typed item
        • Allow itemid in general, rather than expecting vocabularies to explain what it means.
        • Add a mechanism to determine the URL that is a vocabulary identifier, and use it as the start of the property name for any typed item.
        • Remove section «Microdata and other namespaces» which implied that Microdata would not work in other namespaces. Because it does.
        • Allow the content attribute on any element where an itemprop attribute is present, to provide a readable value for a property.
        • Adjust the algorithm for determining the value of a name-value pair, to match implementation:
          • data , meter , and time elements’ textContent is used if they do not have an attribute that supplies the value.
          • If there is a content attribute present, it provides the value.
        • Added non-normative sections for Accessibility and Microdata, Internationalisation and localisation, Privacy, and Security Considerations.
        • Remove drag and drop, as it is not implemented in current browsers.
        • Remove DOM API. This API has been removed from browsers that did implement it.
        • Remove unused references

        15. Acknowledgements

        The original specification for Microdata was developed by Ian Hickson. Without him this specification would not exist. Uptake has substantially been driven by its use for the schema.org vocabulary.

        The current editors would particularly like to thank Gregg Kellogg and Ivan Herman for invaluable help including providing implementation experience and testing during the development of this specification.

        In addition thanks are due to the following people whose direct contributions have helped improve this work:

        Addison Phillips, Bruce Lawson, Christine Runnegar, Jeni Tennison, Jens Oliver Meiert, Léonie Watson, Manu Sporny, Marcos Cáceres, Markus Lanthaler, Nick Doty, Nick Levinson, Philippe Le Hégaret, Ralph Swick, Richard Ishida, Rob Sanderson, Robin Berjon, Shane McCarron, Tab Atkins, Tavis Tucker, Tobie Langel, «Unor», Xiaoqian Wu, Yves Lafon.

        The editors apologise to people whose names have undeservedly been missed in this list.

        Особенности микроразметки microdata :: Хранитель заметок

        Особенности микроразметки microdata

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

        Группа свойств ключ-значение.

        Тип объекта. Фактически это ссылка на страницу с описанием в свободной форме всех названий ключей, которые применимы к описываемому объекту. Этот атрибут неприменим к элементам без атрибута itemscope .

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

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

        Несколько свойств у одного элемента

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

        Ссылка на свойства

        Иногда так получает, что данные, относящиеся к размечаемому объекту, находятся за пределами «корневого» элемента. Специально для этого случая предусмотрен атрибут itemref . Он применяется к элементу с itemscope и содержит id другого DOM-элемента, где находятся остальные свойства. Можно указать через пробел идентификаторы нескольких элементов.

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

        Тем не менее, в результате получилась отлично структурированная разметка. Автор статьи и комментарии примешались в основной поток свойств статьи так как, если бы они были фактически размещены там.

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

        Примешивать свойства с помощью itemref можно даже для элементов, которые не имеют содержимого. Например,

        Объект AggregateRating требует обязательного наличия свойства ratingValue, но его нельзя передать в атрибуте content . Зато можно указать ссылку на другой элемент с нужными атрибутами.

        На практике, пожалуй, этот случай лучше разметить с помощью обычных вложенных элементов с соответствующими атрибутами.

        Илон Маск рекомендует:  Что такое код msql_selectdb
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL