Подтвердить что ты не робот

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

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>

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

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

4b9b3361

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Недостатком является то, что он может немного перегружать вещи так же просто, как ваш пример. Но для более сложных сценариев, где у вас больше данных для передачи, это хороший выбор. Особенно учитывая, что данные передаются как 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

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

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

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

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

EDIT: Не знаю, почему -1, но я указывал, что иногда вы думаете, что вам нужно сломать спецификацию, когда вы этого не сделаете.

Ответ 5

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

Ответ 6

Вы можете вставлять скрытые входные элементы INSIDE в элемент привязки

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

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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