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

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

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

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

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

<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>

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

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

Ответы [ 9 ]

50 голосов
/ 16 октября 2008

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

28 голосов
/ 13 сентября 2009

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

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

9 голосов
/ 19 мая 2009

Другой вариант - определить что-то вроде этого в 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 и плюнуть в заголовочный раздел страницы).

4 голосов
/ 10 февраля 2011

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

4 голосов
/ 19 мая 2009

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

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

и с использованием атрибута title.

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

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

2 голосов
/ 30 ноября 2010

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

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

Тогда вы можете легко извлечь данные с помощью

$('#anchor_id .articleid').val()
0 голосов
/ 11 октября 2012

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

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

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

0 голосов
/ 13 августа 2009

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

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

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

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

0 голосов
/ 16 октября 2008

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

...