Статьи

Атрибут данных HTML5: подача содержимого в сценарии

В этом посте мы рассмотрим варианты использования атрибута данных HTML5 и расскажем о спецификации.  

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

 

что и почему?

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

источник:
спецификация w3

 

Это то, что спецификация говорит об атрибуте data. По сути, это атрибут (пара метка / значение), который содержит данные, которые не принадлежат html как текстовый узел. Эти данные не предназначены для пользователей, они помогают сценариям в их задачах. После префикса «data-» следует строка, которую можно свободно выбирать (в пределах обычных ограничений xml), что позволяет размещать несколько атрибутов данных с разными суффиксами в одном элементе html.

До того, как атрибут data был введен в спецификацию, мы должны были проявлять креативность, когда в нашем HTML-коде требовались данные только для скрипта. Мы злоупотребляли скрытыми полями ввода, мы скрывали html-элементы из представления с помощью css, мы даже использовали атрибуты title для заполнения наших данных сценария, и действительно мы с большим энтузиазмом просто создали свои собственные атрибуты, расширив dtd, если проверка была требованием. Ни один из этих методов не был идеальным, некоторые были просто взломаны или не работали при любых обстоятельствах. Требовалась стандартная альтернатива, и так появился атрибут data.

Случаи использования

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

1. данные для расчетов в скриптах

< .. data-quantitystep="100" .. > 

Добавление продуктов в вашу корзину может быть несколько сложным в зависимости от того, что вы пытаетесь продать. Если вы являетесь интернет-магазином, все должно быть довольно просто, но если вы продаете продукты, которые продаются в разных единицах измерения (например, 6 упаковок кокса против 500 г сыра), то есть больше вещей, на которые следует обратить внимание. Если вы используете пользовательский +/- элемент управления для изменения количества, он будет вести себя по-разному для разных продуктов. Для 6 упаковок кока-колы вы можете просто увеличить количество на 1, но для сыра вы можете увеличить количество порциями по 100 г за раз.

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

2. данные для измененного состояния

< .. data-replace="close extra information" .. > 

Иногда вы сталкиваетесь с данными на странице, которые меняются в зависимости от состояния определенного компонента. Типичный компонент раскрытия / свертывания часто будет содержать обработчик элемента управления с текстовой индикацией открытия / закрытия. Этот текст открытия / закрытия зависит от состояния компонента развернуть / свернуть, поэтому размещение их обоих в HTML как текстовых узлов на самом деле не лучший способ. Если вы отключите CSS, оба текстовых узла будут отображаться, что, по меньшей мере, сбивает с толку. Другой вариант — добавить измененный текст состояния в javascript, но если ваш сайт многоязычен, это делает ваш файл javascript беспорядочным. И учитывая все обстоятельства, javascript просто не место для управления вашим контентом.

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

3. помогите своему бэкэнд-разработчику

< .. data-productid="025652156" .. > 

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

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

внутренний против внешнего

Если вы проверите спецификацию еще раз, вы также заметите, что атрибут data предназначен только для данных, которые должны использоваться внутренними сценариями, то есть сценариями, которые вы специально разработали для работы на создаваемом веб-сайте. Странное ограничение, которое требовало дальнейших объяснений, но ни одно не было дано в самой спецификации. Мое первое предположение состояло в том, что они включили это, чтобы предотвратить злоупотребление атрибутом данных (SEO-заполнение ключевых слов, которое будет подхвачено поисковыми системами), но это было большой ценой, чтобы заплатить за то, что не может быть остановлено в любом случае.

Поэтому я пошел к Whatwg (irc ftw! — проверьте логи ) и спросил более подробную информацию. Оказывается, это не проблема насилия, а возможного конфликта. Поскольку управляющего объекта нет, и каждый может свободно выбирать имя атрибута, могут возникнуть коллизии. Google может использовать contentid для данных с одной стороны, в то время как Amazon может использовать тот же атрибут для чего-то другого.

Справедливо, но это не решает нашу проблему, когда нам нужно предоставить дополнительные данные для внешних скриптов. Я нажал на whatwg для альтернатив, и хотя их первые варианты были менее чем удовлетворительными (используя микроформаты — что означает, что вам все еще нужно добавлять данные в виде текстовых узлов — или используя свойство itemid — что означает, что вы ограничены только одним свойством), Есть один способ обойти ограничения области видимости атрибута data:

<div itemtype="..."> <meta itemprop="productid" content="025652156" /> </div> 

Очевидно, есть крайний случай, когда мета-элементы могут использоваться за пределами заголовка HTML-документа. В сочетании с атрибутом itemprop они служат той же цели, что и атрибуты данных, но для данных, предназначенных для внешних сценариев. Это был первый раз, когда я услышал об этом, но в целом это достойное решение, которое подходит для всей реализации микроданных, разработанной в html5.

Конечно, единственная проблема заключается в том, что это намного сложнее, чем вводить тот или иной атрибут данных для хранения ваших данных, поскольку вам нужна внешняя документация для вашей семантики и структуры микроданных. Выяснить это как фронт-разработчик достаточно сложно, а привлечь его к разработке — совсем другая задача. Я боюсь, что стоимость микроданных слишком высока, чтобы сделать это очень работоспособным решением, особенно когда ничто не мешает вам просто использовать атрибут данных. И если вы правильно выберете имя своего атрибута (какова вероятность того, что data-amazonproductid когда-либо появится на каком-то сайте, не предназначенном для amazon?), Проблем быть не должно.

заключение

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

Что касается альтернативы микроданных (внешние скрипты), я все еще не слишком уверен. Я был бы склонен игнорировать это в настоящее время, надеясь, что мы снова столкнемся с ситуацией «проложить путь коровы» в будущих выпусках спецификации HTML.