Нестандартні атрибути для тегів 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-префіксовані атрибути). Редагувати: Я б додав, що, мабуть, є кращі приклади використання користувацьких атрибутів. Наприклад, дані, які буде використовувати спеціальна програма, які не мають аналогів у стандартних атрибутах (наприклад, налаштування для обробників подій на основі чогось, що не обов'язково може бути виражено в імені класу або ідентифікаторі).

Спеціальні атрибути забезпечують зручний спосіб перенесення додаткових даних на сторону клієнта. 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.

Іноді я розбиваю специфікацію, якщо мені це дійсно потрібно. Але рідко, і лише з поважних причин.

EDIT: Не впевнений, чому -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 для чогось іншого, але він сумісний у кожному браузері.

У вашому прикладі я особисто відчуваю, що пролітний маршрут є більш відповідним, оскільки він відповідає стандартам специфікації XHTML. Однак я бачу аргумент для користувацьких атрибутів, але я думаю, що вони додають рівень плутанини, який не потрібен.

Я над цим також морочуся. Мені подобається читабельність нестандартних атрибутів, але мені не подобається, що це порушить стандарт. Приклад прихованого діапазону відповідає вимогам, але він не дуже читабельний. Як що до цього:

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

Тут код дуже читабельний через позначення пари ключ / значення JSON. Ви можете сказати, що це метадані, які належать за посиланням, просто подивившись на них. Єдиною вадою, яку я бачу поряд із викраденням атрибута "rel", є те, що це може стати брудним для складних об'єктів. Мені дуже подобається згадана вище ідея атрибутів з префіксом "data-". Чи підтримує це поточний браузер?

Тут є ще про що подумати. Наскільки вплив не відповідає сумісний код на SEO?