Почему Вы не используете возможность данных jQuery?
Ваш пример будет (я не знаю условия выбрать надлежащий td):
$("tr td").data("isDirty", true);
смотрят на документация
Технически необходимо использовать атрибут класса для этого. Теги могут иметь больше чем один класс, таким образом, он ни на что не должен влиять
<td class="isDirty otherclass">
HTML 5 поддерживает пользовательские атрибуты, снабженные префиксом "данные -". Так, я использовал бы это, чтобы быть прямо совместимым.
Что касается более ранних версий, я не думаю, что это проверит, но я не волновался бы об этом. Я услышал, что некоторые браузеры могут проигнорировать эти теги, все же. Так, убедиться протестировать все это вокруг.
Это будет препятствовать тому, чтобы Ваша страница проверила, я думаю, так как Вы добавляете пользовательские атрибуты, о которых не будут знать блоки проверки допустимости.
Вы могли бы быть в состоянии сделать это со своим собственным DTD или схемой, но это - больше работы.
Вашим вторым примером является правильный способ сделать это, я думаю. Правильное направление так или иначе.
Придерживание стандартов ради придерживания стандартов является плохой причиной придерживаться стандартов.
Ваша страница определяет DTD, Ваш сервер определяет mimetype. Пока Вы не отправляете реальный xhtml нет никакой причины не, используют атрибуты expando таким образом. Это может быть очень полезно.
хорошо, таким образом, Ваша страница не 'проверит', если необходимо заботиться о том, тогда не делают этого.
Просто не обольщены методом IEs 'conveniant' elem.isDirty доступа к таким значениям. Всегда используйте elem.getAttribute ('isDirty') для доступа к значению.
Я настоятельно рекомендую придерживаться стандартов. Сеть уже испорчена;)
Я полагаю, что нет "Да", или "Нет" отвечают на Ваш вопрос. Используя пользовательские атрибуты поможет Вам иметь более чистый и более короткий код при многих обстоятельствах. Ваш пример тривиален, и я полагаю, что он не может продемонстрировать питание и гибкость этой техники. Конкретно Вы имеете дело с булевым атрибутом, который, скорее всего, имеет отношение к появлению. Подобные вещи лучше обрабатываются с классом. Однако с пользовательскими атрибутами Вы могли добавить контекст к своим узлам. Вы могли использовать этот контекст, чтобы сделать некоторые вычисления. Например, добавьте, что цена или вес приписывают узлам списка. Вы тогда более позднее использование эти поля для вычисления суммы или среднего числа. Я уверен, что существуют многие лучше, чем это примеры там.
, С другой стороны, пользовательские атрибуты будут препятствовать тому, чтобы HTML передал тестирование проверки. Это - важная проблема, и это может стать еще более важным в будущем.
Используя пользовательский атрибут полезно с нескольких точек зрения, но убеждаться избежать конфликта пространства имен при помощи префикса:
<td custom:isDirty="true">
Иначе это могло бы столкнуться с будущими внедрениями.
Как заметка на полях, DOM-элемент может иметь пользовательские свойства как любой другой js-объект, означая, что при создании узлов динамично можно все еще добавить пользовательские данные любого типа к элементу, не влияя на проверку.
var element = document.createElement('div'); element.myCustomObject = { foo: "bar", someFunction: function () { alert('foobar'); }}; document.body.appendChild(element);
, Конечно, вышеупомянутое не имеет смысла людям что никогда делавшиеся клиентские сценарии без платформ как jQuery, прототип и т.д....:)
isDirty является идеальным примером того, как класс нужно назвать. Имена классов должны быть семантическими, и я не могу думать о лучшем способе присвоить класс для описания то, что это о том элементе (кроме использовать заголовок, если Вы хотите поделиться той информацией с конечным пользователем)?
Вы не должны устанавливать свои собственные атрибуты, если Вы не готовы поддержать свой собственный DTD.
Добавление произвольных атрибутов будет означать, что Ваш HTML больше не действителен.
, Если Вы используете XHTML, однако, я думаю, что можно добавить атрибуты, которые имеют различное пространство имен XML, которое не вызовет проблемы проверки.
я не знаю много об этом, но думал, что упомяну его, как никто больше не имеет. Возможно, кто-то еще мог подробно остановиться или опровергнуть, это, если у них есть лучшее понимание?