Не-(X)HTML Атрибуты имеют какие-либо недостатки?

Обычно я пытался придерживаться атрибутов только для DOM при написании Javascript. Теперь, когда я перешел с Prototype на jQuery, я могу получить серьезные преимущества, добавляя свои собственные атрибуты к различным элементам DOM, в основном в области возможности установить очень удобочитаемое соглашение о кодировании для обработки запросов AJAX.

В качестве короткого примера это означает, что я делаю такие вещи, как

<div type="book" app_id="13">
    <a href="#" action="delete">delete</a>
</div>

Затем я могу настроить код для поиска всех тегов <a> с атрибутом action, найти родителя с type и app_id, а затем выполнить операции CRUD... и все это без необходимости писать дополнительный код.

Есть ли какие-либо подводные камни (кроме строгой жалобы на XHTML), которых я должен остерегаться, и/или какие-то хорошие привычки, которым я должен подражать? Как насчет стандартного способа настройки моего собственного пространства имен атрибутов?


xml html jquery namespaces xhtml
person Don Werve    schedule 22.04.2009    source источник

Ответы (4)


arrow_upward
4
arrow_downward

Могу ли я хранить пользовательские атрибуты в HTML DOM, такие как запись базы данных?

Возможно, вам нужны новые атрибуты данных HTML 5.

http://ejohn.org/blog/html-5-data-attributes/< /а>

http://dev.w3.org/html5/spec/Overview.html#custom

Я знаю, что это не "XHTML", но, по крайней мере, это часть какого-то стандарта;)

person Chad Grant    schedule 23.04.2009

arrow_upward
6
arrow_downward

Согласно этому вопросу использование пространств имен XML в XHTML 1.0 недопустимо. Добавление ваших собственных атрибутов в одно и то же пространство имен кажется мне хуже, поскольку они, безусловно, недействительны, даже в том, что касается XML.

Если бы я делал это, я бы извлек выгоду из атрибутов class и rel. Например:

<div class="book" id="book_13">
   <a href="http://example.com/url/to/delete/non/ajaxily" class="delete">delete</a>
</div>
person Steve Pomeroy    schedule 22.04.2009
comment
К сожалению, если вы хотите затем использовать разные классы для обеспечения визуальной обратной связи (скажем, разные фоны для проверенной и невыданной книги), вам либо нужен другой элемент-оболочка, либо нужно использовать настраиваемый атрибут маршрут. - person Don Werve; 23.04.2009
comment
@ Дон - Нет, ты не знаешь. Вы можете использовать несколько классов для любого элемента, просто разделяя их пробелами. например, проверенная книга, подлежащая завтрашнему дню, совершенно действительна - person Mark Hurd; 23.04.2009
comment
@Mark - Вы правы, но то, как вы говорите, требует разбора, что нежелательно. Я бы выбрал (и фактически выбрал) путь к пользовательскому атрибуту. - person BYK; 23.04.2009
comment
Точно -- @BYK попал в самую точку. Моя цель — свести к минимуму объем кода, который мне приходится писать и поддерживать, и дополнительный шаг для анализа идентификатора не является частью этого. Это также ломается, если я хочу использовать идентификатор в качестве селектора по какой-либо другой причине. - person Don Werve; 23.04.2009

arrow_upward
0
arrow_downward

Не вижу ничего плохого в таком подходе. На самом деле я видел много примеров этого и сам использовал этот подход во многих приложениях и не сталкивался с какими-либо препятствиями, кроме проблемы проверки. Так что я думаю, что вы свободны =)

person BYK    schedule 22.04.2009
comment
Вам определенно придется следить за случайным использованием имени элемента, с которым будет работать один или несколько браузеров. Большинство браузеров принимают определенные атрибуты, даже если они не обязательно действительны (особенно IE). - person Travis; 23.04.2009

arrow_upward
0
arrow_downward

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

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

person KyleFarris    schedule 22.04.2009