Нестандартные атрибуты HTML-тегов. Хорошая вещь? Плохо? Твои мысли?

HTML (или, может быть, просто XHTML?) Относительно строг, когда дело касается нестандартных атрибутов тегов. Если они не входят в спецификацию, ваш код считается несовместимым.

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

<a href="#null" class="popup" title="See the Popup!" 
   popup_title="Title for My Popup">click me</a>

Кроме того, вы можете сохранить заголовок всплывающего окна в скрытом элементе, например в диапазоне:

<style>
    .popup .title { display: none; }
</style>
<a href="#null" title="See the Popup!" class="popup">
    click me
    <span class="title">Title for My Popup</span>
</a>

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

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

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

Настраиваемые атрибуты предоставляют удобный способ передачи дополнительных данных на сторону клиента. Dojo Toolkit делает это регулярно, и было указано ( Разоблачение мифов о Dojo Toolkit ), что:

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

Другой вариант - определить что-то вроде этого в Javascript:

<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>

Затем вы можете использовать это позже в своем коде Javascript, если ваша ссылка имеет идентификатор, соответствующий идентификатору в этой хеш-таблице.

У него нет недостатков двух других методов: нет нестандартных атрибутов и уродливого скрытого диапазона.

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

Кроме того, данные хранятся отдельно от форматирования, что способствует удобству обслуживания.

У вас даже может быть что-то вроде этого (чего нельзя сделать другими методами):

var poi_types = {1: "City", 2: "Restaurant"};
var poi = {1: {lat: X, lng: Y, name: "Beijing", type: 1}, 2: {lat: A, lng: B, name: "Hatsune", type: 2}};

...

<a id="poi-2" href="/poi/2/">Hatsune</a>

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

В этом случае оптимальным решением будет

<a href="#" alt="" title="Title of My Pop-up">click</a>

и используя атрибут title.

Иногда я нарушаю спецификацию, если мне это действительно нужно. Но редко и не зря.

РЕДАКТИРОВАТЬ: Не уверен, почему -1, но я указывал, что иногда вы думаете, что вам нужно нарушить спецификацию, когда вы этого не делаете.

Почему бы не объявить атрибут popup_title в настраиваемом DTD? Это решает проблему с проверкой. Я делаю это со всеми нестандартными элементами, атрибутами и значениями и благодарю, что эта проверка показывает мне только реальные проблемы с моим кодом. Это также снижает вероятность ошибок браузера с таким HTML.

Вы можете вложить скрытые элементы ввода ВНУТРИ элемента привязки

<a id="anchor_id">
  <input type="hidden" class="articleid" value="5">
  Link text here
</a>

Затем вы можете легко извлечь данные,

$('#anchor_id .articleid').val()

В конце концов, я решил скрыть дополнительные данные в теге id, разделенные каким-то разделителем (одно подчеркивание - это пробел, два - конец этого аргумента), второй аргумент - это идентификатор:

<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>

Уродливо, и предполагается, что вы еще не используете тег id для чего-то еще, но он совместим во всех браузерах.

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

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

<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>

Здесь код очень удобочитаем благодаря нотации пары ключ / значение JSON. Вы можете сказать, что это метаданные, принадлежащие ссылке, просто взглянув на нее. Единственный недостаток, который я вижу помимо взлома атрибута "rel", заключается в том, что это приведет к беспорядку для сложных объектов. Мне очень нравится упомянутая выше идея атрибутов с префиксом "data-". Поддерживают ли это существующие браузеры?

Вот о чем еще нужно подумать. Насколько сильно несовместимый код влияет на SEO?