Так что, если пользовательские атрибуты HTML не являются допустимыми XHTML?

Question

Я знаю, что по этой причине некоторые люди не одобряют их, но действительно ли это имеет значение? Я думаю, что сила, которую они предоставляют, взаимодействуя с JavaScript и храня и отправляя информацию с и на сервер, перевешивает проблему проверки. Я что-то пропустил? Каковы последствия "недействительного" HTML? И разве пользовательское DTD все равно не разрешит их?

Answer 1

Следствием этого является то, что w3c приходит через 2, 5, 10 лет и создает атрибут с тем же именем. Теперь ваша страница не работает.

HTML5 предоставит тип атрибута данных для допустимых пользовательских атрибутов (например, data-myattr = "foo"), поэтому, возможно, вы могли бы начать использовать его сейчас и быть достаточно безопасным от будущих конфликтов имен.

Наконец, вы можете упустить из виду, что пользовательская логика является рациональным атрибутом класса. Хотя его обычно считают атрибутом стиля, на самом деле это законный способ установки пользовательских мета-свойств для элемента. К сожалению, вы в основном ограничены булевыми свойствами, поэтому HTML5 добавляет префикс данных.

Кстати, под "в основном логическим" я имею в виду в принципе. В действительности ничто не мешает вам использовать разделитель в имени класса для определения пользовательских значений, а также атрибутов.

class="document docId.56 permissions.RW"

Answer 2

Да, вы можете легально добавлять пользовательские атрибуты, используя «данные».

Например:

<div id="testDiv" data-myData="just testing"></div>

После этого просто используйте последнюю версию jquery, чтобы сделать что-то вроде:

alert($('#testDiv').data('myData'))

или установить атрибут данных:

$('#testDiv').data('myData', 'new custom data')

А поскольку jQuery работает практически во всех браузерах, проблем не должно быть;)

обновление

• data-myData может быть преобразована в data-mydata в некоторых браузерах, что касается механизма javascript. Лучше всего держать его строчными.

Answer 3

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

Добавление пользовательских атрибутов не повлияет ни на одну из этих проблем сейчас и вряд ли сделает это в будущем, но поскольку они не проверяются, это означает, что когда вы приходите оценивать результаты проверки вашей страницы, вы нужно будет тщательно выбирать между вопросами валидации, которые имеют значение, и теми, которые не имеют. Каждый раз, когда вы изменяете свою страницу и проходите повторную проверку, вам необходимо повторить эту операцию. Если ваша страница полностью проверена, вы получите приятное зеленое сообщение PASS и сможете перейти к следующему этапу тестирования или к следующему изменению, которое необходимо внести.

Answer 4

Я видел, как люди, одержимые проверкой, делают гораздо худшие / странные вещи, чем использование простого пользовательского атрибута:

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

По моему мнению, пользовательские атрибуты действительно не имеют значения. Как говорят другие, может быть полезно следить за будущими добавлениями атрибутов в стандарты. Но теперь у нас есть атрибуты data- * в HTML5, поэтому мы сохранены.

Что действительно важно, так это то, что вы правильно вложили теги и правильно указали значения атрибутов.

Я даже использую собственные имена тегов (введенные в HTML5, такие как header, footer и т. Д.), Но в IE есть проблемы.

Кстати, я часто иронично вижу, как все эти фанатики проверки склоняются перед хитрыми хитростями Google, такими как загрузка iframe.

Answer 5

Вместо использования пользовательских атрибутов вы можете связать свои HTML-элементы с атрибутами, используя JSON:

var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };

А что касается последствий, см. Ответ SpliFF .

Answer 6

Хранение нескольких значений в атрибуте класса - это не правильная инкапсуляция кода, а просто извилистый способ взлома. Возьмите пользовательский ротатор рекламы, например, который использует jquery. На странице намного чище сделать

<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />

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

Возвращение к проекту через год или переход к новому, когда предыдущий разработчик разделился и отправился на остров где-то в Тихом океане, может быть адом, пытаясь выяснить намерения, когда код написан в нечетком зашифрованном виде, например:

<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes"  />

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

Answer 7

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

Мне, например, НУЖНО, чтобы мой контент был действительным XHTML, потому что очень часто он преобразуется в XML для различных заданий и затем конвертируется обратно без потери данных или неожиданных результатов рендеринга.

Answer 8

Старая дискуссия, но тем не менее; По моему мнению, поскольку HTML является языком разметки, а не языком программирования, его всегда следует с осторожностью интерпретировать как «ошибки» разметки. Браузер вполне может это сделать. Я не думаю, что это будет и должно измениться когда-либо. Поэтому единственным важным практическим критерием является то, что ваш html будет отображаться корректно большинством браузеров и будет продолжать это делать, скажем, несколько лет. По истечении этого времени ваш html, вероятно, будет в любом случае переработан.

Answer 9

Что касается проверки, то СЕГОДНЯ это может не иметь значения, но вы не можете знать, будет ли это иметь значение завтра (а по закону Мерфи это будет иметь значение завтра).

Просто лучше выбрать перспективную альтернативу. Если они не существуют ( они существуют в данном конкретном случае ), то путь состоит в том, чтобы изобрести альтернативу, которая будет проверена на будущее.

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

Answer 10

Ну, это зависит от вашего клиента / босса / и т.д .. они требуют, чтобы он проверял XHTML?

Некоторые люди говорят, что есть много обходных путей - и в зависимости от сценария они могут отлично работать. Это включает в себя добавление классов, использование атрибута rel и кого-то, кто даже написал собственный парсер для извлечения JSON из комментариев HTML.

HTML5 предоставляет стандартный способ сделать это, добавив к вашим пользовательским атрибутам «data-». В любом случае, я бы рекомендовал сделать это сейчас, так как есть вероятность, что вы можете использовать атрибут, который будет использоваться в дальнейшем в стандартном XHTML.